step-security / harden-runner Goto Github PK

Change it to Security agent for GitHub-hosted runner to monitor the build process

• Add links to more users
• Mention that one can add it using workflows and also fix token permissions
• Add insights link with each repo using it
• Add link to discussions
• Improve screen shots
• Add link to GitHub runner issue - since api.snapcraft.io comes up often
• Remove slack since discussions is being used more often
• Include info about private repos - preview
• Add testimonials?
• Add discussion on SLSA
• Add discussion on verifying tool checksums
• Yaml formatting

related issue: #130

• Decide on release method
• Set a version for first release

https://github.com/jauderho/dockerfiles/runs/4929417948?check_suite_focus=true#step:3:9

#61 (comment)

Recommend use of tag instead of branch

• should allow for wildcards

Linked issue: step-security/agent#50

As 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.

Even though block is the default value for egress-policy, it is better to have it be set to block explicitly. This makes it easier to change it to audit if traffic is blocked, and the workflow needs to be run in audit mode again.

https://github.com/Automattic/vip-go-mu-plugins/pull/2815/files#r786925704

Demo Harden Runner workflow for nuget/setup-nuget

name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
    
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      - uses: step-security/harden-runner@rc
        with:
          egress-policy: audit
      - name: nuget/setup-nuget
        uses: nuget/setup-nuget@v1
        with:
          nuget-version: '5.x'

Generated Workflow for nuget/setup-nuget

Output Step Security Console from harden-runner
https://app.stepsecurity.io/github/Devils-Knight/Knowledge-base/actions/runs/1693963110

https://github.com/MTRNord/matrix-art/actions/runs/1743376122

I am having to remove this from any of my actions that makes outbound UDP 443 (QUIC) connections. When this is enabled I get no connectivity. Related: microsoft/msquic#2534 and nibanks/msh3#28.

When copying the latest code block output from https://app.stepsecurity.io/github/jauderho/dockerfiles/actions/runs/1800983360 , I notice an issue. There seems to be a spurious > in the code block in the same line as allowed-endpoints:.

See below for example,

- 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
      artifactcache.actions.githubusercontent.com:443
      crates.io:443
      dl-cdn.alpinelinux.org:443
      ghcr.io:443
      github.com:443
      production.cloudflare.docker.com:443
      registry-1.docker.io:443
      sh.rustup.rs:443
      static.crates.io:443
      static.rust-lang.org:443

A job failed because of this error. Initial investigation seems to suggest it is coming from tool-cache

https://github.com/nvm-sh/nvm/runs/4919179993?check_suite_focus=true#step:2:5

• use of container
• longer run time

When user sets this mode, e.g.

- name: Harden Runner
        uses: step-security/harden-runner@rc
        with:
          egress-policy: block
          disable-telemetry: true
          allowed-endpoints: 
            github.com:443

agent should not make calls to agent.api.stepsecurity.io.
Other allowed-endpoints can still be called.

• Do not show link - clarify that insights will not be generated
• Add this attribute to the config

#61 (comment)

The allowed_endpoints block is, apparently, a blob of text. The recommendations output by the hardener look something like this:

- name: Harden Runner
  uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    egress-policy: block
    allowed-endpoints: 
      api.github.com:443
      artifactcache.actions.githubusercontent.com:443
      github.com:443
      kv4gacprodeus2file3.blob.core.windows.net:443

which my Visual Studio code editor then neatly reformats to:

  - name: Harden Runner
    uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
    with:
      egress-policy: block
      allowed-endpoints: api.github.com:443
        artifactcache.actions.githubusercontent.com:443
        github.com:443
        kv4gacprodeus2file3.blob.core.windows.net:443

note that the api.github.com:443 line has shifted up.

If the allowed-endpoints format were to be a list, the above would instead look like

- name: Harden Runner
  uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    egress-policy: block
    allowed-endpoints: 
      - api.github.com:443
      - artifactcache.actions.githubusercontent.com:443
      - github.com:443
      - kv4gacprodeus2file3.blob.core.windows.net:443

or if a block-style indicator for multi-line text was used, such as >:

- name: Harden Runner
  uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    egress-policy: block
    allowed-endpoints: >
      api.github.com:443
      artifactcache.actions.githubusercontent.com:443
      github.com:443
      kv4gacprodeus2file3.blob.core.windows.net:443

Both formats are in canonical form and would not cause a reformat. I used the latter in my configurations.

  semgrep:
    permissions:
      contents: read # for actions/checkout to fetch code
    name: semgrep-scan
    runs-on: ubuntu-20.04
    container:
      image: returntocorp/semgrep
    if: (github.actor != 'dependabot[bot]')
    steps:
    - name: Harden Runner
      uses: step-security/harden-runner@9b0655f430fba8c7001d4e38f8d4306db5c6e0ab
      with:
        egress-policy: audit

    - uses: actions/checkout@3df53dd32d858478710a6127bcd8b9d8b7182e16
    - run: semgrep ci || true

This fails with the below error

/bin/sh: sudo: not found
Error: Command failed: sudo mkdir -p /home/agent
/bin/sh: sudo: not found

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

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

#61 (comment)

microsoft/msquic#2310 (comment)

It should not block traffic, but should warn if there are new endpoints.

This tool looks really great, keen to give it a try.

I'm thinking of using it in a private repo. It seems that if I do that then the generated URL will be public and it will follow the predictable pattern of {org}/{repo}/actions/runs/{runid}. Is that right?

I understand I can disable sending telemetry to the step security API which will ensure the details aren't made public - but in that case it seems there's no practical way of doing an initial workflow run to determine which endpoints etc. to whitelist (e.g. with egress-policy: audit)

• Is there any way to have the report that's hosted on app.stepsecurity.io generated as a static file and saved as a workflow artefact?
• Is there any way to have the report URL contain, say, a secret string? A random URL so it's not guessable, but is still publicly accessible?
• do you have other plans for handing this issue?

Where job fails if there is call to endpoints not in the allowed list.

#61 (comment)

https://app.stepsecurity.io/github/Automattic/vip-go-mu-plugins/actions/runs/1757921355

api.snapcraft.io is called by snapd and this call is made from most jobs. Showing this in the annotations when this traffic is blocked causes unnecessary confusion. Do not show this in annotation, even when it is actually being blocked.

Hi I wanted to switch over to using https://github.com/actions-runner-controller/actions-runner-controller/ for custom runners but it seems the default image of it doesn't set the "$USERS" variable.

This results in this error: https://github.com/MTRNord/matrix-art/runs/5368009721?check_suite_focus=true

Any ideas how I could fix this or what is expected?

Hi, very exciting project!

I took a look at https://github.com/step-security/harden-runner/blob/main/src/checksum.ts#L13 and saw that you are verifying a checksum before installing the agent. How can I verify this checksum? I made a local build of the agent with goreleaser and got a different checksum for the generated .tar.gz.

Being able to verify the integrity of the agent binary feels like a critical step in improving the supply chain integrity.

In one of my github actions i setup 9b0655f # v1 with audit egress policy. I was using https://github.com/wallies/action-netlify-deploy to setup my netlify previews. The issue was when it came to install my dependencies via npm ci or npm install it would just hang. I removed step-security/harden-runner step and everything worked. Im using node lts 16.14

• Decide on beta vs only prod
• Add prod api into main branch

• #26
• #32
• #30

It is hard to tell what is generating the annotation

e.g. https://github.com/ossf/scorecard/actions/runs/2018689479

I just testing and implementing harden-runner after starting with the scorecard action. Repo is here: https://github.com/jauderho/psfiles

So if the push is for actions to use commit hashes instead of version tags, the output page of the insights should utilize the commit hash instead.

For example, https://app.stepsecurity.io/github/jauderho/psfiles/actions/runs/1731266664

Recommendation is for

- uses: step-security/harden-runner@v1
  with:
    allowed-endpoints: 
      api.github.com:443
      github.com:443

Instead, it really should be (and changing as necessary as the action gets updated)

- uses: step-security/harden-runner@14dc64f30986eaa2ad2dddcec073f5aab18e5a24 # v1
  with:
    allowed-endpoints: 
      api.github.com:443
      github.com:443

Similarly, the README.md for this repo should indicate/recommend the use of hashes instead.