Project Lightning Talk: Protect your Kubernetes Clusters with Ratify and Attestations - Yi Zha

Project Lightning Talk: Protect your Kubernetes Clusters with Ratify and Attestations - Yi Zha

Speakers: Yi Zha

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=lNovu7Kclhk

Overview

In the rapidly evolving landscape of cloud-native development, securing the software supply chain has become a paramount concern. Yi Zha, a maintainer of the Notary Project and now Ratify, delivered a concise yet insightful talk at KubeCon EU, introducing Ratify—a critical sandbox project designed to safeguard the integrity and authenticity of artifacts deployed within Kubernetes clusters. This presentation highlighted Ratify's capabilities as a pluggable verification engine, emphasizing its role in enforcing security policies across the cloud-native supply chain by leveraging attestations.

The talk underscored a fundamental shift in supply chain security: traditional image signatures, while essential, are no longer sufficient to guarantee the trustworthiness of deployed software. Ratify addresses this gap by extending verification beyond mere signatures to include crucial supply chain artifacts like Software Bill of Materials (SBOMs) and vulnerability reports. By integrating with existing tools and frameworks like Gatekeeper and Open Policy Agent (OPA), Ratify empowers organizations to establish robust, policy-driven controls, ensuring that only trusted and compliant workloads run in their Kubernetes environments. This innovation is vital for any organization seeking to harden its cloud-native security posture against increasingly sophisticated supply chain attacks.

Background

▶ Watch: Introduction to Ratify: a pluggable verification engine (0:00)

The journey towards securing the software supply chain has seen significant advancements, particularly with the widespread adoption of containerization and Kubernetes. Initial efforts focused on verifying the integrity and authenticity of container images themselves, primarily through cryptographic signatures. Projects like the Notary Project and Cosign emerged as key players, enabling developers to sign images and consumers to verify these signatures, thus ensuring that an image had not been tampered with since it was signed by a trusted entity.

However, as the complexity of software components grew and the threat landscape evolved, it became clear that simply signing a container image was insufficient. A signed image guarantees its origin and integrity but provides no inherent assurances about its contents. For instance, a signed image could still contain critical vulnerabilities, use non-compliant open-source licenses, or even harbor malicious dependencies introduced earlier in the build process. The dynamic nature of vulnerabilities, which can be discovered daily, further complicates this, meaning an image deemed "safe" yesterday might be vulnerable today.

This realization led to the emphasis on Software Bill of Materials (SBOMs) and vulnerability reports. An SBOM provides a comprehensive list of all components, libraries, and dependencies within a software artifact, offering transparency into its composition. Vulnerability reports, on the other hand, detail known security flaws present in these components. Both artifacts are crucial for understanding the true security posture of a deployed workload. The challenge then shifted to verifying the integrity and authenticity of these associated artifacts, not just the container image itself. This is where the concept of attestations becomes pivotal: signed statements that vouch for the integrity and authenticity of an artifact, ensuring that the SBOM or vulnerability report itself is trustworthy and hasn't been tampered with. Ratify steps into this space, providing the missing link to verify these crucial supply chain artifacts and enforce policies based on their content.

Key Findings

▶ Watch: Three key scenarios for Ratify deployment (2:00)

Yi Zha's presentation illuminated several key findings and capabilities of the Ratify project, positioning it as an indispensable tool for cloud-native supply chain security. At its core, Ratify is presented as a pluggable verification engine designed specifically to safeguard the integrity and authenticity of artifacts within the cloud-native ecosystem.

A significant finding is Ratify's broad support for various signature formats and artifact types. It seamlessly integrates with established signing solutions like the Notary Project signature and Cosign signatures, including both KMS-based and keyless signing methods. This versatility ensures compatibility with diverse existing security infrastructures. Beyond mere image signatures, Ratify's true power lies in its ability to verify a spectrum of critical supply chain artifacts, including Software Bill of Materials (SBOMs)—often in SPDX format—and vulnerability reports, typically presented in safer JSON format. The project also directly supports the verification of attestations, which are signed statements about these artifacts.

Another crucial aspect highlighted is Ratify's robust policy enforcement capabilities. It leverages the Rego language, widely used with Open Policy Agent (OPA) and Gatekeeper, to define granular security and compliance policies. This allows organizations to specify precise rules, such as disallowing images with critical CVEs or non-compliant licenses. The speaker also mentioned plans to support the CUE language in the future, indicating a commitment to flexibility. Furthermore, Ratify is compliant with OCI 1.1, enabling efficient pulling and verification of OCI artifacts.

The talk detailed three primary scenarios where Ratify provides significant value:

1. Admission Control: Integrating with Gatekeeper and OPA to enforce policies on workloads before they are deployed to Kubernetes clusters. This is the most common and immediate application.
2. Node-level Runtime Verification: Working with containerd to validate container images directly on the node. This is particularly useful for scenarios like Kubernetes cluster bootstrapping, where admission controllers might not yet be operational, or for verifying cached images. The speaker noted this scenario is currently in a proof of concept stage.
3. CI/CD System Integration: Enabling early validation of signatures and enforcement of supply chain policies (e.g., on SBOMs and vulnerability reports) directly within the Continuous Integration/Continuous Delivery pipeline, shifting security left.

The overarching key finding is the strategic shift Ratify facilitates: moving beyond the limitations of simple image signing to a holistic verification model that encompasses all relevant supply chain artifacts through the use of attestations. This comprehensive approach is essential for establishing true trust in cloud-native deployments.

Technical Deep Dive

▶ Watch: Deep dive: Understanding signed attestations and statements (3:15)

Ratify operates as a sophisticated, pluggable verification engine, engineered to provide a flexible and extensible framework for securing the cloud-native supply chain. Its architecture is designed to integrate seamlessly into various stages of the software lifecycle, from development to runtime.

At its core, Ratify's verification process hinges on its ability to understand and validate different types of cryptographic signatures and artifact formats. For signatures, it offers comprehensive support for two leading standards: Notary Project signatures and Cosign signatures. Cosign, a key component of the Sigstore project, further supports diverse signing mechanisms, including KMS (Key Management Service) based signatures for enterprise environments and keyless signatures, which leverage ephemeral keys and public transparency logs like Rekor for simpler, yet secure, signing workflows. This broad compatibility ensures that Ratify can verify artifacts signed by a wide array of tools and processes.

The true innovation of Ratify lies in its ability to verify a range of supply chain artifacts beyond just the container image itself. These include:

• Software Bill of Materials (SBOMs): These are formal, machine-readable inventories of the components that make up a software package. While the talk specifically mentioned SPDX format, Ratify's extensible nature implies potential support for other formats like CycloneDX. Ratify verifies the SBOM's signature, then allows policies to be applied to its content—for example, checking for specific license types that might violate organizational compliance rules.
• Vulnerability Reports: These reports detail known security vulnerabilities (CVEs) present in the software's components. The speaker mentioned a safer JSON format for these reports. Similar to SBOMs, Ratify first verifies the report's signature, then enables policy checks on its content, such as ensuring the report is "fresh" (e.g., generated within the last day) or that it doesn't contain CVEs above a certain severity threshold (e.g., critical or high-severity CVEs).
• Attestations: These are signed statements that provide verifiable information about an artifact. An attestation could state that an SBOM was generated by a specific tool, or that a vulnerability scan was performed at a certain time with a particular result. Ratify treats these attestations as first-class citizens, verifying their signatures and then their claims.

Policy enforcement within Ratify is powered by the Rego language, the declarative policy language used by Open Policy Agent (OPA). This allows organizations to write highly granular and expressive policies that govern what constitutes a "trusted" or "compliant" artifact. For instance, a Rego policy could dictate:

(Note: The above Rego code is illustrative and conceptual, as the exact data structure Ratify exposes to OPA wasn't detailed in the transcript, but it reflects the type of policies Ratify enables.)

Ratify's compliance with OCI 1.1 is crucial for its operational efficiency. OCI (Open Container Initiative) artifacts, such as container images, are stored in registries. OCI 1.1 provides a standardized way to associate other artifacts (like SBOMs and vulnerability reports) with a primary artifact (the container image). This allows Ratify to efficiently discover and pull all related signed artifacts from an OCI registry for verification.

The talk outlined three distinct integration scenarios:

1. Admission Control Integration (Scenario 1): This is Ratify's most prominent use case. When a user attempts to deploy a workload (e.g., a Pod) to a Kubernetes cluster, the request is intercepted by an admission controller, typically Gatekeeper (an OPA-based admission controller). Ratify acts as an external data provider for Gatekeeper. Gatekeeper queries Ratify for verification results pertaining to the container images and their associated attestations. Based on the Rego policies configured in Gatekeeper, Ratify's findings (e.g., "SBOM is signed and valid, no disallowed licenses," or "Vulnerability report is fresh and has no critical CVEs") determine whether the admission request is allowed or denied. This ensures that only compliant workloads are ever scheduled.
2. Runtime Verification with containerd (Scenario 2): This scenario focuses on verifying images at the node level, after they have been admitted but before they are executed by the container runtime (containerd). This is particularly valuable during Kubernetes cluster bootstrapping, where admission controllers might not yet be fully operational, or for validating cached images on a node. If a node is compromised, or an image was pulled before policies were updated, this layer provides an additional defense. The speaker noted this is currently in a proof of concept stage, indicating active development in this area.
3. CI/CD System Integration (Scenario 3): Integrating Ratify into the CI/CD pipeline allows for "shift left" security. Instead of waiting until deployment to Kubernetes, Ratify can validate signatures, SBOMs, and vulnerability reports as soon as artifacts are built or pushed to a registry. This catches issues earlier in the development lifecycle, reducing remediation costs and speeding up secure software delivery.

The speaker presented a clear example of how attestations are chained: an OCI image is signed with a Notary Project signature. This image then has a vulnerability report (in safer JSON format), which is itself signed with a signature. Additionally, the image has an SBOM (in SPDX format), which is also signed with a Notary Project signature. Ratify's role is to verify each of these individual signatures and then apply policies to the content of the SBOM and vulnerability report, providing a comprehensive trust chain.

Demo / Proof of Concept

▶ Watch: Importance of attestations beyond image signatures (4:00)

While the presentation did not feature a live, interactive demonstration of Ratify in action, it effectively conveyed the conceptual flow and the technical underpinnings through illustrative examples and architectural diagrams.

The speaker presented a visual representation of a typical OCI image and its associated artifacts, serving as a conceptual demonstration of Ratify's verification scope. This example showed an OCI image that had been signed using a Notary Project signature. Crucially, it also depicted two additional artifacts directly linked to this image: a vulnerability report in a "safer JSON format" and a Software Bill of Materials (SBOM) in SPDX format. The key point illustrated was that each of these associated artifacts—the vulnerability report and the SBOM—was also individually signed with a Notary Project signature. This visual explanation highlighted how Ratify would verify not only the primary image's signature but also the signatures of its critical metadata, ensuring the integrity and authenticity of the entire supply chain data.

Furthermore, the talk explicitly mentioned that one of Ratify's key integration scenarios, specifically its use for runtime verification with containerd at the node level, is currently in a proof of concept stage. This indicates that while the functionality is actively being developed and tested, it may not yet be production-ready or widely deployed. The scenario for bootstrapping Kubernetes clusters and verifying cached images on nodes underscores a future capability that Ratify aims to deliver, complementing its current admission control integrations.

In essence, the "demo" aspect was more of a detailed explanation of how Ratify processes and validates a chain of signed artifacts, rather than a step-by-step walkthrough of its deployment or operation. This approach was effective in conveying the project's technical depth and its proposed solutions to complex supply chain security challenges.

Defensive Implications

▶ Watch: Example: Enforcing policies with Ratify and Gatekeeper (4:45)

Ratify offers profound defensive implications for organizations operating in cloud-native environments, particularly those relying on Kubernetes. Its capabilities directly address several critical attack vectors within the software supply chain, moving beyond reactive security measures to proactive policy enforcement.

Firstly, Ratify significantly enhances an organization's ability to prevent supply chain attacks. By acting as a gatekeeper at various stages—admission, runtime, and CI/CD—it ensures that only artifacts verified against predefined security policies are allowed to proceed. This means that if a malicious actor injects code into a dependency, or alters an SBOM to hide non-compliant components, Ratify's verification of the associated attestations and the enforcement of policies would detect and block such attempts. It provides a robust mechanism to establish and maintain a trusted software supply chain.

The project empowers defenders with granular policy enforcement. Through its integration with Gatekeeper and leveraging the Rego language, security teams can define precise rules that reflect their organization's specific risk tolerance and compliance requirements. For example, policies can mandate that all deployed images must have a signed SBOM, no critical or high-severity CVEs (as per a recent vulnerability report), and no dependencies with licenses incompatible with corporate policy. This moves away from generic security checks to highly tailored, automated enforcement. The ability to check the "freshness" of vulnerability reports (e.g., "within a day") is particularly powerful, as it allows organizations to react swiftly to newly discovered vulnerabilities.

For Kubernetes environments, Ratify's admission control integration is a critical defensive layer. It prevents untrusted or non-compliant container images from ever being scheduled on a cluster. This "shift left" in enforcement, occurring before a workload even starts, drastically reduces the attack surface and the potential impact of compromised artifacts. By denying admission to images that fail verification, Ratify acts as an essential last line of defense before deployment.

Furthermore, the ongoing runtime verification (PoC with containerd) promises an additional layer of defense. While admission control is crucial, runtime checks can catch scenarios where an image might have been trusted at admission time but later became untrusted due to new vulnerability disclosures or if a node's cached image was somehow compromised. This provides continuous assurance, complementing the initial admission checks.

Integrating Ratify into the CI/CD system allows organizations to "shift security left" even further. By validating signatures, SBOMs, and vulnerability reports early in the development and build pipeline, potential issues can be identified and remediated before they ever reach a production environment. This reduces the cost and complexity of fixing vulnerabilities, improves developer productivity, and accelerates the delivery of secure software.

In essence, Ratify helps organizations transition from a reactive posture (fixing vulnerabilities after they're deployed) to a proactive, preventative approach. It fosters a comprehensive trust model where not just the executable code, but all associated metadata and contextual information—like SBOMs and vulnerability reports—are cryptographically verified and enforced by policy. This holistic view is indispensable for building resilient and secure cloud-native infrastructure in the face of evolving cyber threats. Defenders should consider Ratify as a foundational component in their Kubernetes security strategy, leveraging its capabilities alongside existing signing tools like Notary Project and Cosign to establish end-to-end supply chain integrity.

Key Takeaways

• Comprehensive Supply Chain Security: Ratify is a pluggable verification engine designed to safeguard the cloud-native secure supply chain by verifying not just container image signatures, but also associated artifacts like SBOMs and vulnerability reports.
• Attestations are Key: Simple image signatures are insufficient. Ratify leverages attestations—signed statements about artifacts—to ensure the integrity and authenticity of critical metadata such as Software Bill of Materials (SBOMs) and vulnerability reports.
• Flexible Policy Enforcement: Ratify integrates with Gatekeeper and uses the Rego language (with future plans for CUE) to enable highly granular and dynamic policy enforcement based on artifact content (e.g., license issues in SBOMs, critical CVEs in vulnerability reports, freshness of reports).
• Multi-Scenario Integration: It supports three key deployment scenarios: admission control for Kubernetes workloads, node-level runtime verification with containerd (currently PoC), and integration into CI/CD systems for early validation.
• Broad Signature and Artifact Support: Ratify supports widely adopted signature schemes including Notary Project signatures and Cosign signatures (KMS and keyless), and processes artifact types like SPDX SBOMs and safer JSON vulnerability reports.
• OCI 1.1 Compliance: Its compliance with OCI 1.1 ensures efficient discovery and pulling of associated artifacts from container registries, streamlining the verification process.

About the Speaker(s)

Yi Zha is a prominent figure in the cloud-native security community, deeply involved in projects focused on securing the software supply chain. At the time of this KubeCon EU talk, Yi Zha was transitioning roles, having previously served as a maintainer for the Notary Project and now taking on the role of maintainer for the Ratify project. This background underscores their expertise in artifact signing, verification, and the broader challenges of ensuring trust and integrity in cloud-native software delivery. Their work directly contributes to open-source initiatives aimed at strengthening the security posture of Kubernetes and other cloud-native technologies.