StepSecurity Harden-Runner GitHub Action installs a security agent on the GitHub-hosted runner to prevent exfiltration of credentials, detect compromised dependencies and build tools, and tampering of source code during the build.
You run the Harden-Runner GitHub Action in audit mode, and it shows you insights about the outbound network calls discovered during the workflow run. You can then use the block mode and restrict outbound traffic to these allowed endpoints.
One of the most asked features by users of Harden Runner was to auto-detect the GitHub Actions cache endpoint. GitHub Actions uses Azure Blob storage to store cache and these endpoints are different for different repositories. This caused problems in adding the cache endpoint to the allowed list, e.g., when the audit mode was run on a fork, the cache endpoint was different from when the workflow was run in the main repository. This caused the outbound calls to the cache endpoint to get blocked, which led to confusion and a bad developer experience.
It also caused problems when Harden Runner was run inside a GitHub Actions Reusable workflow, since the cache endpoint for a reusable workflow is different based on which repository the calling workflow belongs to. This made it hard to use the block mode to restrict endpoints in reusable workflows.
In the latest release v1.5.0 of Harden Runner, this problem has been fixed! Harden Runner now auto-detects the cache endpoint during the workflow run and automatically adds it to the allowed list. As a result, the cache endpoint does not need to be explicitly specified in the allowed endpoints list. This makes it easier to set allowed endpoints for a workflow.
Let us look at what changed using an example:
Before
In v1.4.5 and earlier versions, the insights for a workflow that used cache would look something like this. The highlighted section shows the endpoint for the cache used by the workflow.
The developer would need to add the cache endpoints to the allowed list in block mode, as shown below.
After
In the recently released v1.5.0, the insights for the workflow look like this. The cache endpoint is displayed in the insights for reference but does not need to be added in the allowed endpoints list.
The allowed endpoint list now looks like this:
As a result, developers do not need to add the cache endpoint in the allowed list.
When the workflow runs, the cache endpoint is detected and added to the allowed list. This is what the build log shows:
No change is needed for those who have already configured cache endpoints in the allowed list in their workflows. Harden Runner will work properly even if the cache endpoint is explicitly added to the allowed list.
What’s next?
The next exciting feature to be added to Harden Runner will be to enable running a job without sudo access to the underlying Ubuntu VM. GitHub Actions jobs run with sudo access by default, but not all jobs need sudo access. If one of the dependencies or build tools run as part of the job is compromised, it can be use sudo access to perform privileged operations on the VM. In a future release Harden Runner will show whether sudo was used in a job run as part of the security insights, and if not, will recommend setting sudo to false. Once this is done, for future workflow runs, Harden Runner will remove sudo access for the job.
In addition, we are working on adding notifications from the Harden Runner App. Once notifications are enabled, you will get an email or a Slack message when outbound traffic is blocked for your workflow. As of now, when outbound traffic is blocked, an error annotation is added in the workflow, but developers might miss this annotation. The notification will be a way to inform them to review the workflow to understand why outbound traffic was blocked.
To get updates, follow Step Security on LinkedIn and Twitter.
