Sign images using Sigstore #3707
Conversation
This allows to narrow down workflow permissions in GitHub settings See https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs and https://docs.github.com/en/actions/security-guides/automatic-token-authentication\#permissions-for-the-github_token Signed-off-by: Marco Franssen <[email protected]>
Signed-off-by: Marco Franssen <[email protected]>
marcofranssen
requested review from
evan2645,
amartinezfayo,
azdagron,
MarcosDY and
rturner3
as code owners
| env: | ||
| COSIGN_EXPERIMENTAL: 1 |
There was a problem hiding this comment.
is this to use keyless approach?
There was a problem hiding this comment.
yes, although experimental, haven't faced any issue in the last year I have been using it on various repos. I think they are close to making this feature GA, so with new release of cosign, this might not be required anymore.
There was a problem hiding this comment.
Sigstore is now GA so the env var here is no longer needed 🎉
There was a problem hiding this comment.
this is still required until we cut a cosign release v2
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| - name: Install cosign |
There was a problem hiding this comment.
so, we'll be signing only release and nightly builds, how about regular builds images? (the ones generated when running PRs)
I think signing regular PR images can be useful to verify sign still working, and we may benefits with that if we create an IT that verify our images are signed
There was a problem hiding this comment.
agree, you can sign the image that you generate in the main branch build
There was a problem hiding this comment.
For that there is already a nightly in place. On the main branch no images are released, so also nothing to sign there. Or is there a way to sign an image that hasn't been pushed to a registry? Basically offline signature? I'm not aware you can sign without pushing to a registry.
Signatures are stored in the registry. As well in the transparency log. IMHO doesn't make sense to do that. Those images are also not published meaning we are pushing signatures and and transparancy log records for images that do not exist in the registry. |
marcofranssen
force-pushed
the
container-signing
branch
from
34b0241 to
6499281
Compare
| env: | ||
| COSIGN_EXPERIMENTAL: 1 |
There was a problem hiding this comment.
this is still required until we cut a cosign release v2
| packages: write | ||
|
|
||
| env: | ||
| COSIGN_EXPERIMENTAL: 1 | ||
|
|
||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
a good practice is to use the git hash instead of the tag and have a comment to which release is pointing to. Dependabot when update the release can also update the comment :)
| uses: actions/checkout@v3 | |
| uses: actions/checkout@ac593985615ec2ede58e132d2e21d2b1cbd6127c # v3.3.0 |
same applies to the other actions
There was a problem hiding this comment.
There is another PR adressing this practice already. #3727
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| - name: Install cosign |
There was a problem hiding this comment.
agree, you can sign the image that you generate in the main branch build
|
🎉 |
* Limit workflow job permissions to bare minimum This allows to narrow down workflow permissions in GitHub settings See https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs and https://docs.github.com/en/actions/security-guides/automatic-token-authentication\#permissions-for-the-github_token Signed-off-by: Marco Franssen <[email protected]> * Add container signing using Sigstore keyless Signed-off-by: Marco Franssen <[email protected]> Signed-off-by: Marco Franssen <[email protected]> Co-authored-by: Marcos Yacob <[email protected]>
Pull Request check list
Affected functionality
Description of change
This allows consumers of the image to verify the signature. E.g. via a policy engine in k8s or via
cosign verifyin workflows etc.See https://registry-ui.chainguard.app/ to explore the signatures of an image.
and https://rekor.tlog.dev/ to explore the transparancy log (shows which workflow was used to sign the image) This information can be used in policies and attestations.
Which issue this PR fixes