-
Notifications
You must be signed in to change notification settings - Fork 107
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
Sign and verify images made/used in all Makefiles and docker-compose files #2544
Comments
Just want to add that we should consider GSA-TTS/datagov-brokerpak-eks#13 when looking at this story. We'd prefer to use the same signature/verification scheme for container images in local development and production. |
I just stumbled across cosign which might be useful in a variety of workflows! |
Related: the umbrella sigstore project. |
|
Seems like maybe the existing Alpine image on which so much is based hasn't been signed for a while...? |
User Story
In order to have a verifiable supply chain for Docker-based workflows and operations, the team wants to use Docker Content Trust to verify pulled images haven't been tampered with before using them.
Acceptance Criteria
[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]
WHEN we run a
make
ordocker-compose
that pulls its images from that registryTHEN we see an error indicating that the image could not be verified.
Background
[Any helpful contextual notes or links to artifacts/evidence, if needed]
We mostly use Docker Official Images from hub.docker.com, where the images were based on Dockerfiles provided directly by the teams that create the software. These images are generated directly by Docker Hub, which uses Notary to sign the created images. However, we aren't checking those Notary signatures when we pull and use images. We should!
See section 10.8.4 in the data.gov SSP for additional context.
Security Considerations (required)
[Any security concerns that might be implicated in the change. "None" is OK, just be explicit here!]
This only tightens our security and makes it obvious whenever we do not rely on official images (because they will fail to run).
Sketch
[Notes or a checklist reflecting our understanding of the selected approach]
DOCKER_CONTENT_TRUST=1
.trusted-compose
instead ofdocker-compose
.The text was updated successfully, but these errors were encountered: