RX Patient Tools
Use these quick guides before reading the article, or return to them when you need help preparing questions for a doctor.
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.
Ratify 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. The project’s README.md has a quick start that uses Notary V2 solution for signing and verifying the image signatures.
Ratify only 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.
What is Ratify?
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:
- Coordinator: From the functionality angle, this framework is a coordinator that creates a workflow for verifying the different supply chain content for an image according to a set policy. In addition, it provides cross-cutting functionalities across different verifications like logging, caching, auditing, and break glass support.
- Extensible: This framework is designed from the beginning on an extensible model without any affinity towards a particular verifier or storage model. You can have your supply chain objects stored in OCI distribution or other private databases. The framework can be configured to query any kind of storage for the supply chain content. In a similar way, any verifier can be added to verify a given supply chain object. All the components follow a well-defined plugin model where the framework invokes them as part of the verification workflow. These plugins are regular binaries or executables at a given path configured with the framework. This model is similar to the plugin interface provided by the kubelet credential provider or the Container Network Interface (CNI).
- Policy: This policy component drives the workflow and the outcome of verifying different supply chain objects for an image. This component is also designed to follow the same extensible model to allow for simple configuration-based policies to advanced Open Policy Agent (OPA)-based policies.
- Open source: This project will be completely open source and we will soon engage the community by hosting regular meetings for it.
- Cloud vendor-neutral: We would like to contribute this project to the Cloud Native Computing Foundation (CNCF) eventually and thereby it will be cloud-native and cloud provider-neutral.
- Interfaces: The framework will be designed with different interface models to allow for its integration at different stages of the supply chain whether it is at Continuous Integration or Continuous Deployment (CI/CD), or runtime like Kubernetes. In addition, it will have an interface that will enable inner loop development to allow for pre-validations before using it in the supply chain.
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.
What next?
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.
