Confirm Harden-Runner support for GitHub-hosted Linux ARM64 runners on the community tier

[jauderho]

Question

Is Harden-Runner expected to work on GitHub-hosted Linux ARM64 runners (ubuntu-24.04-arm / ubuntu-26.04-arm) in the community tier? The action currently reports that it is not, and I could not find anything in the docs that confirms or denies it either way, so I would like to check whether that message reflects a deliberate current limitation, a licensing boundary, or something on the roadmap.

What I observe

On v2.21.0 (05e31511f85b41b11d1cf0ef85d0992719546e2c), in a matrix where the same job runs on both architectures, the ARM job logs:

[harden-runner] pre-step
ARM runners are not supported in the Harden-Runner community tier.
[harden-runner] main-step
[harden-runner] post-step

and then completes without enforcing anything. The amd64 job in the same matrix, with the identical with: block, enforces egress-policy: block normally.

Reproducible example

Public repo, so this should be viewable directly:

• ARM job (ubuntu-26.04-arm), showing the message: https://github.com/jauderho/sandbox/actions/runs/33210555842/job/98982480483
• Full run, where the amd64 job in the same matrix enforces normally: https://github.com/jauderho/sandbox/actions/runs/33210555842
• Workflow at that commit: https://github.com/jauderho/sandbox/blob/8099522e42c66be00010bc514c4838c8ee5cfdca/.github/workflows/cryptolyzer.yml

Both jobs use:

- uses: step-security/harden-runner@05e31511f85b41b11d1cf0ef85d0992719546e2c # v2.21.0
  with:
    egress-policy: block
    disable-telemetry: true
    allowed-endpoints: >
      ...

Why this matters for us

We build multi-architecture container images. Now that GitHub offers hosted ARM64 runners, the recommended pattern is to drop QEMU emulation and build each platform on its native runner, then merge the per-platform digests into a manifest list. That is a large speed win, and it is why our matrix is linux/amd64 on ubuntu-26.04 and linux/arm64 on ubuntu-26.04-arm.

The practical consequence is that half of every build matrix is unprotected. For a repository that has deliberately moved everything to egress-policy: block, that is an awkward gap, and it grows as more projects migrate to native ARM builds.

There is a second, subtler problem: the asymmetry makes the policy harder to get right. Because only the amd64 job enforces, a too-narrow allowed-endpoints list fails just that job. We hit this repeatedly while tightening our lists — for example, apt and microdnf fetch over port 80, so an allowlist containing only archive.ubuntu.com:443 passes on ARM and fails on amd64. A green ARM job can look like validation when it is really a no-op.

What would help

1. Confirmation of the current status for Linux ARM64 on the community tier.
2. If it is a tier boundary rather than a technical one, saying so in the docs — the Harden-Runner docs do not mention ARM/arm64/aarch64 at all, so today the runtime log is the only signal.
3. If Linux ARM64 support is planned, any indication of timing, similar to how Upcoming: Windows and macOS runner support #636 tracked Windows and macOS.

[varunsh-coder]

This should be available in community tier. We are working on making the ARM support available, will share update here.