SLSA Compliance: Check provenance before accepting staged artifacts #2283
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a function to read statements from files Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
Add some provenance files to use during tests Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
This functions allow reading a provenance file and clone its predicate to a new statement. Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
This commit adds a new stage to anago/stage: CheckProvenance() This new step checks all staged artifacts during staging to ensure they match the in-toto attestation metadata produced and stored with them durin stage. Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
This commit adds a new function to the provenance statement object to verify the contents of its subject against a directory tree. Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
This code introduces a new object: ProvenanceChecker which will be used to concentrate the provenance functionality in the release process. In this first iteration it introduces one sole function: `CheckStageProvenance()` that verifies the staged artifacts in the release bucket. Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
This commit modifies the call to CheckProvenance() during release. For now, we will treat provenance errors as non-fatal and warn in the release process log. Once we finish testing and implementing SLSA1 support, this commit should be reverted to reenable failing the build when the provenance metadata does not match the staged artifacts. Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
k8s-ci-robot
added
release-note
k8s-ci-robot
added
area/release-eng
|
OK, here is a point to consider: To verify the provenance of the staged artifacts, we need to have them at hand. This means that before the release phase can proceed, the run in GCB will have to download everything from the staging bucket. Currently, this means rsyncing ~14 GB per released tag down to the GCB workspace. This is a considerable volume to move and will have an impact on the Release Manager's time needed to cut a release. I've been thinking of ways to avoid copying the release from the bucket, but I think there is no way around it. Any other ideas @kubernetes/release-engineering ? |
15 tasks
Verolop
approved these changes
Oct 7, 2021
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: puerco, Verolop The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR modifies the
anago/releaseto verify the provenance metadata describing the artifacts stored in the release bucket during staging. To do so, it introduces a newProvenanceCheckerobject which is used byanago.Releaseto validate all artifacts staged by the build against the in-toto attestation written during stage.Which issue(s) this PR fixes:
Part of: #2267
Special notes for your reviewer:
This PR includes commit d14061d which changes the provenance error to just a warning to avoid failing a release when metadata is incorrect. This commit is to be kept in place while SLSA compliance code is under development. Once the SLSA effort is done, it must be reverted. An example for this commit is that while I was writing this PR, I noticed that the current metadata generation has a flaw. Paths to the staged container image tarballs are wrong, so checking will fail so we need to only warn for now.
Another important consideration is that in order to verify the provenance metadata, (at least for now) we have to pull all artifacts from the bucket to the GCB workspace. Let's discuss here if there are other possible approaches to this problem.
Does this PR introduce a user-facing change?