5 things we learned from sponsoring a sampling of our open source dependencies
Microsoft is experimenting with and investing in sustainability of the open source…
Securing the software supply chain and verifying that chain is hard for any software, and containers running in Kubernetes are no exception. Operational best practices like image signing, scanning, provenance verification, and ensuring these operations have been properly completed with signed software bill of materials (SBoMs) are all required, and tons of tools are appearing in order to make it easier to do for everyone.
That can mean a lot of tools processing and signing things, but it all works fine—or it’s getting there. But how do you ensure that everything’s fine when you deploy? How do you verify and enforce that all artifacts comply with your own policy?
Today we are excited to introduce an open source project, Ratify, that enables Kubernetes clusters to verify artifact security metadata prior to deployment and admit for deployment only those that comply with an admission policy that you create.
Ratify is an extensible verification framework for container images and other artifacts that can examine and use custom policies that you create to approve deployments in Kubernetes. Ratify can use and coordinate any number of custom verifiers for things like signatures, SBoMs, scan results, and so on.
To see what’s possible with Ratify, you can get it set up and use some example images and policies that we’ve set up to demonstrate the project. The project’s README.md has a quick start that uses Notary V2 solution for signing and verifying the image signatures.
Absolutely not!
You may have heard a lot of discussions recently about SBoMs—possibly because of the United States’ Executive Order about software supply chain requirements. An SBoM describes a lot of things in a set of artifacts that make up a deployment—images, blobs, patches, and SBoM files themselves, and it is also signed. In addition, container scanning for vulnerabilities is also used to verify the security of images. These scan reports for an image are also signed. It could be that an image can have a collection of artifacts that are together required to satisfy any algorithm or policy for verifying safety.
To store these different artifacts for an image, we’re going to need a directed graph of all objects required for complete verification. We term this as The Graph of the Supply Chain Content. Fortunately, we have such a graph already available to Open Container Initiative (OCI) registries that implement the ORAS Artifact specification. A graph, for a simple example, might look like this:
To use an OCI registry to create such a graph, we need something that can implement the ORAS artifact spec. In this case, the CNCF project ORAS and Notary v2 can be used to create a graph of supply chain content for container images. For more information about Notary V2 and its use of artifact graphs, see the release announcement blog.
Building and storing the graph is great, and many tools are being built to do just this. Verification, however, needs to access and use a custom policy statement to evaluate the graph before it releases the deployment into the cluster. This is where Ratify helps.
Ratify is a workflow engine that coordinates the verification of different supply chain objects for an image as per a given policy. It is a framework that can use and coordinate any number of custom verifiers for things like signatures, SBoMs, scan results, and so on. It aggregates the results of these independent verifiers using a policy. This aggregated result can be used to make decisions in the admission controllers. Ratify is designed with a few core principles:
With these as the core design principles, we have put together an architecture that depicts different components of the framework, its interfaces, and the consumption ecosystem.
Apart from Kubernetes, Ratify can also be used in CI/CD pipelines. We are actively working to provide GitHub action that can validate the container supply chain using Ratify.
We appreciate all kinds of input from the community. Please share any feedback or thoughts about this framework via discussions or issues. This support will help shape the project in a way that the community really needs to ensure supply chain security for the container images and other artifacts.