Feature: Visualize registry image signatures
Atomic container image signing provides the ability to cryptographically ensure the docker image you pull is the same the author or builder created.
- A method for signing Docker images was developed by Docker using Notary. There are design and architecture concerns over that prevent adoption.
- OpenShift features an integrated registry. Support for image signature objects is being added. External tooling is being developed that integrates with these objects.
- There are two primary use cases that will be implemented in order.
- Stand-alone: OpenShift stores signatures for managed images. This allows "external" clients (atomic CLI, build pods, etc) to create, verify and manage signatures.
- Integrated: OpenShift actively manages signatures. It has capability to verify/trust and create (sign) signatures. This extends the stand-alone use case leveraging lessons learned from experience with a decoupled workflow.
User stories:
Sue is a software developer. Part of her job is to package and deliver software as docker images. During the early development cycles she builds docker images locally and pushes them to an internal registry. She doesn't place any value signing these images. Doesn't care. Now that she has a working application she must integrate with the build system. Corporate policy requires her to build on a corporate signed image, to sign each build and to verify these signatures during the test phase.
Sue uses the registry console to figure out if the base image she has been using during development has a signature. It does not. She uses the console to filter for images that have a signature. She finds what looks like a corporate standard image. She pulls down the image, uses command line tooling to validate the signature to comply with corporate policy to used signed images from trusted vendors. She then gets the application working on this image, signs it with her private key and pushes the new image to her development project namespace in the registry. This new image shows that it is signed by her. With this her colleagues could test validating the signature of this new image while the official release candidate image is submitted.
Next she submits her Dockerfile source to the build system, which has its own tooling and signing server.
Robert is a release engineer at the same company. Robert runs a set of services to build and release software. He has automation in place to validate and sign docker images. When Sue submitted her Dockerfile source to the build system, Robert's automation validated the signature of the base image Sue's Dockerfile references. After the image was built Robert's system signed the build with a non-production, internal signature. When Fred's QE test team validates the test image, Robert will sign the release candidate build with a production private key. This private key is protected as part of a tightly controlled signing server.
Fred manages a test group. Part of his group's testing is to cryptographically validate the Docker images that come out of the build system.
Sue:
- Pull image from vendor or internal "official" namespace
- Validate signature on workstation. During validation she is warned that she is trusing a new public key.
- Build new image
- Push and sign image with private key
- Sees this new image in the registry with information about the signer
Robert:
- Based on a pre-defined set of official images, he validates these images using a workstation.
- Independently verifies the identity of each signer with each vendor. See https://access.redhat.com/security/team/key for example.
- Using public keys trusted from step 1, pre-configures the public keys he trusts in his automated system.
- Automates image signatures validation during build process.
- He has opted in for notifications from vendors to receive alerts with any signing-related issues. For example, if a key is compromised he can revoke the trust from his automation and update the configuration.
- Initial API discussion for storing signature data: https://github.com/openshift/origin/pull/8371
- Limitations
- Automated signing involves storing private keys in the database. This use case is being deferred.
- Automated signature verification needs additional work.
- References
- Red Hat security page https://access.redhat.com/security/team/key
TBA
- Docker Notary https://github.com/docker/notary CLI only
- Notary
Please give feedback on the above! This is the place where those not working on the feature can provide insight, questions, limitations, notes etc.
-
What happens in the cases where this chain of trust breaks down? Is there a chance Sue to get tricked to build upon the wrong image? What are the risks involved? (Andreas)
-
What happens further down the line? How can the end user of the software Sue packaged be sure that it really comes from where it's said to come from? (Andreas)
-
Aaron Weitekamp aweiteka@redhat.com
-
Miloslav Trmač mitr@redhat.com