-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🛠️ Add Harden Runner to improve CI-security (2/2) (#956) #958
Conversation
with: | ||
egress-policy: audit | ||
disable-sudo: true | ||
egress-policy: block |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What the possible options? I could only see block
and audit
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are the only possible values:
https://github.com/step-security/harden-runner/blob/main/action.yml
If it's set to block you can choose to not report the results to their API.
github.com:443 | ||
objects.githubusercontent.com:443 | ||
raw.githubusercontent.com:443 | ||
repo.maven.apache.org:443 | ||
repo1.maven.org:443 | ||
sh.jbang.dev:443 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are you getting this list of endpoints?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the summary (accessible at the link printed in the harden-runner step) they list all endpoints that were accessed. I used the "Recommended" tab where they contained the recommended config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! So first you can audit to record the allowlist and then block it, right?
|
Yes precisely, that's why I split the PR into two as well. The workflow had to run to collect all endpoints. And the publish workflow is still only in audit state. My plan is to record endpoints and hard-code them when I do the next release, although I might keep it in audit mode since it can be quite difficult to fix if the workflow breaks/is blocked half way through. And it can still be useful to check which endpoints were connected to afterwards - It would not prevent a leak but then you can see that you need to rotate the tokens etc I am missing some option to make an allowlist for file writes as well. Harden-runner currently reports that there are for example 5 file write operations and list the files. But I want to have it report especially if those files changes. Now it's infeasible to check each workflow-run and compare which files were written to. |
But I must say that it was very easy to add to the project! And they have a community version which is free for public repos. It doesn't include all features but do the basic and blocks un-allowlisted connections. They can also create a "security pr" with best practises where they e.g. add depandabot, and setup some other recommended pre-commit hooks etc. I looked through it and dont think it applies to this project, but it could be an easy way to add good defaults. |
Although it seems some endpoints are not connected to all the time. For example the repo.maven.apache.org:443 was new for a secondary run (https://app.stepsecurity.io/github/chains-project/maven-lockfile/actions/runs/11600602474?jobid=32301416922&tab=recommendations). It would probably be a good idea to let it run a couple of times and connect endpoints, but I thought github actions would be deterministic 🤔 |
That is very strange 😮 |
Some action are only run when merged into the main branch. This appiles the recommended configuration of harden-runner from those actions.
Some actions will need to be more strictly configured later.