Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
allow-endpoints should accept wildcards or better handle Github artifact hosts
See original GitHub issueAs per the GitHub runner requirements, a GitHub runner that needs to handle caches and artefacts should be able to connect to *.blob.core.windows.net hosts.
E.g. my build workflow connected to kv4gacprodeus2file3.blob.core.windows.net:443, to download the yarn cache, and then optionally would upload it again in a post step (via action/setup-node action, which uses actions/cache).
The GH cache action uses an indirect API; an API call is made to artifactcache.actions.githubusercontent.com to get the blob location, which in my case was kv4gacprodeus2file3.blob.core.windows.net. However, there is no guarantee that a next run will use that same hostname!
My next run made a connection to gheus21ubt20eus26diag.blob.core.windows.net during the post-complete step, as the provisioner tried to upload some artefact. The harden-runner blocked this as the host was not whitelisted.
I fully realise that just whitelisting *.blob.core.windows.net is not a great idea either; there could be any number of malicious payloads lurking in Azure blob stores, so ideally there should be a way to whitelist just the known GitHub artefact and cache hosts. This may require petitioning GitHub to use dedicated hostnames for their cache / artefact hosts and / or the use of SSL certificates on those hosts that can be verified.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Thanks!
Our workflow doesn’t handle any sensitive info, and is never used to publish anything (it’s only for continuous integration/tests). I’d rather not have to worry about playing whack-a-mole in case the CDN decides to change a hostname on us. Thus, I think I’ll just stick with audit for now. The best fix, if we really wanted an allow list, would probably be to host the binaries we need at a well-known location. Adding wildcards to the hostnames is probably not the best solution.
In terms of feedback,
harden-runnerhas been really nice to use. It came recommended to me by a coworker and I was delighted with how quickly I could integrate it into our workflow.This issue is fixed in the latest release. Harden runner now auto detects the cache endpoint. More details in this blog post: https://blog.stepsecurity.io/harden-runner-github-action-now-auto-detects-cache-endpoints-1ad77fe2da0a
I will go ahead and close this issue. Please reopen if you think it is not working as expected. Thanks!