Support ignoring env vars in job signatures #3402
Open
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.
Description
In some cases, when using signed pipelines, the values of some environment variables can't necessarily be controlled by the user to the degree that steps will always pass verification -- for example, successive pipeline uploads can change build-level environment such that steps will fail to verify.
To allow users to still use pipeline signing in these situations, we've added a pair of flags to the agent
--signing-ignored-env-vars
and--verification-ignored-env-vars
. As their names imply, they remove environment variables from the step payloads that we sign and verify.This means that if we knew that environment variables called
MOUNTAIN
andRIVER
were going to change between signing and verification, we could start the signing agents with--signing-ignored-env-vars="MOUNTAIN,RIVER"
and the verifying agents with--verification-ignored-env-vars="MOUNTAIN,RIVER"
.Setting these flags reduces the integrity of the signature, and thus weakens the security guarantees that signed pipelines provides. As such, when in use, signing pipelines with ignored env vars will always emit a warning. The intent is that the use of these flags will be a stopgap until agent environments can be better controlled.
This PR relies on the associated one in go-pipeline.
Testing
go test ./...
). Buildkite employees may check this if the pipeline has run automatically.go fmt ./...
)