Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add attestation predicates for GitLab and GitHub #26

Merged
merged 2 commits into from
Oct 31, 2024

Conversation

simonbaird
Copy link
Collaborator

Use the CI_TYPE var to decide which one to use.

Filling in more useful content is still to do, but I want to merge this early to solidify the selection mechanism, and confirm things are working as expected.

Ref: EC-987

At this stage it has no effect in the GitHub container, since we
aren't running anything in that container, but I'll set it there
anyway to be consistent.

Note that the var is likely to be overridden/masked by the var set
by the CI config, but I figure there's no harm in setting it in the
Dockerfile anyhow, and I suspect it will make some testing/hacking
workflows easier.
Use the CI_TYPE var to decide which one to use.

Filling in more useful content is still todo, but I want to merge
early, and this should be enough to see if the choosing mechanism is
working as expected.

Ref: https://issues.redhat.com/browse/EC-987
@simonbaird
Copy link
Collaborator Author

I tested this locally, something like this:

# Run a local build pipeline with CI_TYPE set
export CI_TYPE=gitlab && source env.sh && ./build-pipeline.sh

# Copy/paste the image ref from the build pipeline output
IMG=quay.io/sbaird/bootstrap:gitlab-84a0979b61f46b77e315042052c0e73403063bda

# See if it looks right. Check the .predicate.buildDefinition.buildType in particular
cosign download attestation $IMG | jq '.payload|@base64d|fromjson'

@jduimovich
Copy link
Member

Both GitHub and GitLab seem to have support for generating actual tamper-proof attestations, should we use that instead?

https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds#generating-artifact-attestations-for-your-builds https://about.gitlab.com/blog/2022/11/30/achieve-slsa-level-2-compliance-with-gitlab/#how-to-generate-artifact-metadata-with-the-gitlab-runner

Yes, I think eventually we need to use these as they will be standard.
We may also need to add additional attestations (unknown)
We'd need to update the EC policy to be able to read and validate these.

@jduimovich jduimovich merged commit 211fc35 into redhat-appstudio:main Oct 31, 2024
@simonbaird
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants