Ratify is designed with a few core principles: This aggregated result can be used to make decisions in the admission controllers. It aggregates the results of these independent verifiers using a 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. Ratify is a workflow engine that coordinates the verification of different supply chain objects for an image as per a given policy. Verification, however, needs to access and use a custom policy statement to evaluate the graph before it releases the deployment into the cluster. For more information about Notary V2 and its use of artifact graphs, see the release announcement blog.īuilding and storing the graph is great, and many tools are being built to do just this. In this case, the CNCF project ORAS and Notary v2 can be used to create a graph of supply chain content for container images. To use an OCI registry to create such a graph, we need something that can implement the ORAS artifact spec. A graph, for a simple example, might look like this: Fortunately, we have such a graph already available to Open Container Initiative (OCI) registries that implement the ORAS Artifact specification. We term this as The Graph of the Supply Chain Content. To store these different artifacts for an image, we’re going to need a directed graph of all objects required for complete verification. 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. These scan reports for an image are also signed. In addition, container scanning for vulnerabilities is also used to verify the security of images. 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. You may have heard a lot of discussions recently about SBoMs-possibly because of the United States’ Executive Order about software supply chain requirements. The project’s README.md has a quick start that uses Notary V2 solution for signing and verifying the image signatures. 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. ![]() Ratify can use and coordinate any number of custom verifiers for things like signatures, SBoMs, scan results, and so on. 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. 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. 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? That can mean a lot of tools processing and signing things, but it all works fine-or it’s getting there. 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. Securing the software supply chain and verifying that chain is hard for any software, and containers running in Kubernetes are no exception.
0 Comments
Leave a Reply. |