Controller cannot be deployed in airgapped environments because --disable-tuf=true flag does not work for Github Root of Trust

[federico-falconieri-form3]

The sigstore policy controller can be launched with the flag --disable-tuf=true to avoid configuring the trust root online, see this related issue that lead to the flag being implemented: https://github.com/sigstore/policy-controller/issues/354). This is critical in airgapped environments.

When we deploy the github fork of the controller we can use that flag and it will work for the Sigstore Root of Trust, however the controller still tries to reach Github Root of Trust at https://tuf-repo.github.com//3.root.json... this should not be necessary as the trust root is provided through a CRD via the https://github.com/github/artifact-attestations-helm-charts/blob/main/charts/trust-policies/templates/trustroot-github.yaml

[federico-falconieri-form3]

Update: I noticed that the controller tries to reach the mirror url that is specified in the trust-policies TrustRoot github even if --tuf-disable is true. Then I had a look at the TrustRoot CRD and found

description: Spec is the definition for a trust root. This is either a TUF root and remote or local repository. You can also bring your own keys/certs here.

The github TrustRoot is of type remote. We most likely need one of type repository to work in airgapped environements... I found this article on setting up TUF that also shows how to get this repository: https://blog.sigstore.dev/sigstore-bring-your-own-stuf-with-tuf-40febfd2badd

I'll pick up from here tomorrow. In any case I'm curious how frequently updating will be necessary...

[codysoyland]

Thank you for reporting! That's right, the issue here is that the trust-policies Helm chart includes an online TUF reference, therefore the flag you mentioned doesn't have an effect here. This is "by design" but I agree that we should provide instructions for an offline-ready root of trust for GitHub's CA. I will plan to write up those instructions.

I'll pick up from here tomorrow. In any case I'm curious how frequently updating will be necessary...

For offline trust roots, we'd simply recommend updating it as often as possible, as the certificates may be rotated/updated as soon as 24 hours before entering production use. We currently plan on rotating certificates at least once per six months. Because of this, for air-gapped installations, I would script the update of the trust root as part of the process of updating all other components that may depend on it.

[codysoyland]

I added an issue and PR to the main policy-controller project to allow simple trusted-root support for air-gapped environments. When that is merged, I can pull it into this fork and add air-gapped support for pulling in the trusted root to our helm charts.