harden-runner: Bug: Output of harden-runner insight should use commit hash instead

One item that’s unclear to me is we should include the version number while using the digest for point to an image. See jauderho/dockerfiles#146

Yes, I think we should.

@varunsh-coder

A somewhat related question for you. One of the OpenSSF Scorecard recommendations is to switch from using Docker image tag to digests. Given that you have an Action to covert from versions to commit hashes for GHA, do you know of or have any plans to create a similar page to https://app.stepsecurity.io/ that will allow for a cut/paste conversion for Docker tags?

@jauderho I was thinking of the exact same thing. I will add it. Thanks for the idea!

@jauderho I have fixed the UI bug. Can you please verify? The editor should show harden-runner in same way as the landing page.

- name: Harden Runner
  uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    egress-policy: block
    allowed-endpoints: 
      95s5acprodeus1file6.blob.core.windows.net:443
      api.github.com:443
      archive.ubuntu.com:80

This appears to work. Just tested on one of my actions.

Thanks! I will go ahead and close this bug. I will enable discussions on this repo.

https://app.stepsecurity.io/github/jauderho/dockerfiles/actions/runs/1747044469

I had created a bug to investigate this earlier - https://github.com/step-security/harden-runner/issues/68.

@jauderho I have fixed the UI bug. Can you please verify? The editor should show harden-runner in same way as the landing page.

- name: Harden Runner
  uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    egress-policy: block
    allowed-endpoints: 
      95s5acprodeus1file6.blob.core.windows.net:443
      api.github.com:443
      archive.ubuntu.com:80

This appears to work. Just tested on one of my actions.

Where is this backend that you are referring to? I think that’s where I’m missing understanding of.

Backend is the API and data store that stores the correlated outbound traffic. e.g. when you visit https://app.stepsecurity.io/github/jauderho/dockerfiles/actions/runs/1742888941, it fetches the data for that workflow run and shows it from the backend API.

Now, the idea is that instead of adding the allowed-endpoints in the workflow YAML file, you can simply check the endpoints that should be allowed, and save the policy using the insights page using a save policy button. Then the policy will get saved along with the insights in the backend. Next time the same workflow runs, harden-runner will fetch the policy from the backend and then hard-fail/soft-fail based on that policy. This way, if there is a new endpoint, one does not need to change the workflow YAML file (so no need to do pull request and update the YAML file). Just go to the insights page, and approve the new endpoint.

The downside is that the allowed-endpoints are not visible in the YAML file.

@jauderho sorry, missed that. re-opening issue. will add it soon.

@jauderho I have fixed the commit hash issue that you reported. The readme and the insights page have been updated.

For all your other suggestions, I have created separate issues to track them. I have improved the copy-paste experience, but it will take me more time to have the full workflow show up there. I will get it done soon though.

Thanks again for the feedback! I have added a Slack channel link in the readme, in case you want to join. Would love to have more discussions.

I will go ahead and close this issue. Thanks!

It’s on my todo list to figure out how to implement cosign and SBOMs for containers. I just figured it out for Go binaries (see bl3auto repo) but have not had cycles to work on this yet. Hopefully in the next few weeks…

Might be nice to have them expire in a few days (and an option to retain if needed). I’m just wondering about the use case where a private repo might accidentally leak endpoints if this is integrated in the workflow.

Hi @jauderho harden-runner does not show insights for private repos as of now (I will add this to the readme). I think it would not be right for me to show the insights to public for a private repo. Other services like codecov show the test coverage to public for public repos, but require authentication and check repo access before showing results of private repos. I was thinking of doing the same. thoughts?

Yeah, not allowing for private repos without an explicit opt-in would be good. For example, I now have a GHA template repo which I plan to use to copy to new repos. Not allowing private repos will prevent inadvertent exposure.

Also, the way things are set up means that we have to take two passes, once to audit and once to block.

I’m trying to think of a safe way to do this in one pass. I suppose one could have an action that modifies things after the fact but that would mean that the action needs write access and self modifying code could have unexpected outcomes.

Yes, it would be ideal if one did not have to change the workflow while going from audit to block mode. In fact some users have asked for a warn-only mode for similar reason. In warn-only mode, one would select the allowed-endpoints in the insights website, and they will get saved in the backend (not in the workflow file). If a new endpoint is called, it will notify in annotations (as a warning). Then the developer can click on the insights link and add that to the allowed list if it should be allowed, or investigate why that outbound call was made. So, one option is for the block mode to also store allowed-endpoints in the backend. But some users have asked for it to be in the workflow yaml file, since it makes it clear what is allowed and what is not.

Although, I think your tool appears to be able to have some knowledge of various actions so maybe that can be included as part of the suggested block of yaml. For instance, the CodeQL action is almost always going to be talking to the same set of hosts for everyone so it would make sense to just return github.com etc. as part of the allow list.

Does that make sense?

That knowledge base is to give users some information about why a certain domain is called. But restricting based on that will not work for run commands.

Might be nice to have them expire in a few days (and an option to retain if needed). I’m just wondering about the use case where a private repo might accidentally leak endpoints if this is integrated in the workflow.

Hi @jauderho harden-runner does not show insights for private repos as of now (I will add this to the readme). I think it would not be right for me to show the insights to public for a private repo. Other services like codecov show the test coverage to public for public repos, but require authentication and check repo access before showing results of private repos. I was thinking of doing the same. thoughts?

I do have one nit but it’s mostly me being OCD.

If I check the Add step-security/harden-runner action on https://app.stepsecurity.io/, I’d like to see an additionally newline inserted before the next step. It’s a little easier to distinguish between the steps that way.

Also, do the insight links expire after a while? For example, https://app.stepsecurity.io/github/jauderho/psfiles/actions/runs/1731266664

@varunsh-coder while you are at it, if you can make the copy block on the insights page be the entire workflow (or at least make than an option), it will make it easier to do a complete copy and replace.

@jauderho Great idea! I will make it same experience as the home page https://app.stepsecurity.io, where there is an editor and one can just copy and paste it without having to fix indentation etc.

Do let me know if you have more ideas to improve user experience or any other feedback. Thanks a lot!

Thanks @jauderho for using harden-runner!

Good feedback. I will address it ASAP.

I observed you are setting the allowed-endpoints, but the egress-policy is set to audit. As a result the traffic is not restricted. The default value for egress-policy is block. So you can either remove egress-policy and just keep the allowed-endpoints or set egress-policy to block.

I will address this in the insights page as well and set egress-policy to block explicitly.

I will be happy to fix your workflows for you. Please let me know.