Feature Overview (aka. Goal Summary)  

OLM v1 adheres to the platform-wide namespace-level signature trust policies defined by OpenShift signature policies.  

Goals (aka. expected user outcomes)

OLM v1 contributes to a more secure and reliable operator and broader workload ecosystem while adhering to the platform's image trust policies enforced by OpenShift signature trust policies.  This includes:

• Validating image signatures: Verifying that images possess valid cryptographic signatures.
• Enforcing registry restrictions: Rejecting images from untrusted registries.
• Complying with granular policies: Image policies can be enforced consistently across all namespaces or for specific namespace(s).

In essence, OLM v1 must support and implement the same behavior that OpenShift’s container runtime is using when admitting Pods, about image references and applicable signature policies and it needs to use the runtime’s configuration.

Requirements (aka. Acceptance Criteria):

• Policy enforcement:
  • Validating image signatures: Adheres to the platform's image policy for signature validation (and other future KMS-related use cases such as key rotation and key revocation) by using the platform’s respective APIs
  • Policy-based decisions: Rely on the platform's image policies to decide operator installation, updates, deletion, and catalog admission. 
    • For example, if an operator's bundle image does not meet the required security standards, OLM v1 should reject processing them.

• User experience:
  • Offer clear indications of image signature status (valid, invalid, or missing) to users in the top-level APIs that were triggering the processing of said image.

• Sigstore integration (if not delegating to underlying CRI):
  • Verify the signatures of all images before installing or updating operators based on the platform's Sigstore policies.
  • Interact with the platform's Sigstore infrastructure (e.g., verification servers) to verify signatures.

Documentation Considerations

• SigStore integration: 
  • Explain how OLM v1 follows the platform's image policy for signature verification to make decisions regarding operator installation and updates.

• Policy enforcement:
  • How to define image trust policies: Link users to the existing OpenShift docs section detailing how to create policies that define acceptable images, registries, and signature requirements for the entire cluster or individual namespaces.
  • Policy-based decisions: Explain how policy is used to make decisions about operator installation and updates, including the specific criteria for rejecting images that do not meet required security standards.

• User Experience:
  • How to review and understand image policy violations for troubleshooting image signatures validation status.
  • Guidance on addressing policy violations (e.g., link to existing OpenShift docs section for more details).

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

• What Sigstore is: 
  • Sigstore is an open-source project aimed at improving software supply chain security. It provides tools and services for developers to securely sign and verify software artifacts, which include container images, binaries, and software bills of materials (SBOMs).
  • With Sigstore, providers can ensure the authenticity and integrity of their software artifacts, providing increased trust and security for end-users.

• Key components of Sigstore:
  • Cosign: Sigstore's primary tool for signing and verifying software artifacts. 
    • It integrates with key management systems (KMS) and supports key revocation lists.
    • It generates signatures using ephemeral keys and binds them to the artifact.   
  • Fulcio: A certificate authority (CA) that issues short-lived certificates for signing artifacts. 
    • No need for the developers to manage their certificates.   
    • (OCP has no roadmap for Fulcio).
  • Rekor: A public transparency log either in its Linux Foundation (LF) instance or a corporate instance, provides an immutable and append-only ledger for recording signatures and revocation information (signed metadata).
    • This provides an auditable record of the signature

• How Sigstore Works (at a super high level):
  • Signing an Artifact: 
    • The developer/provider uses Cosign to sign the artifact with an ephemeral key or a private key.  
    • A certificate is obtained from Fulcio to bind the ephemeral key to the developer's identity (OCP has no roadmap for Fulcio).
    • The signature, certificate, and artifact metadata are uploaded to Rekor.
  • Verifying an Artifact:
    • The verifier downloads the artifact and its signature.
    • The signature is optionally verified using the certificate from Rekor.
    • The artifact's integrity is checked against the signature using either a private key or an OIDC identity linked in Fulcio.

• How OpenShift integrates Sigstore (focus on the Cosign and Rekor):
  • [Outcome] OCPSTRAT-918 Support Sigstore toolchain to sign and verify signed artifacts
    • OCPSTRAT-453 Dev Preview in 4.16 Re-validation of Sigstore signed image at cluster level
    • OCPSTRAT-1245 [Tech Preview] Add Sigstore signatures to core OCP payload and enable verification- phase 1 in 4.17
    • OCPSTRAT-1585 [Tech Preview] Add Sigstore signatures to core OCP payload and enable verification - phase 2 in 4.18
  • Supports verifying a signed image via a known public key
    • Cloud-based KMS solutions or direct passing of the public key is still supported, this is how Red Hat content is signed.
  • Supports verifying a signed image in a signature transparency log
    • Verification of signatures should be enforced by checking Rekor (Linux Foundation or a corporate instance)
      • Red Hat provides a public Rekor instance containing signature transaction records for Red Hat content
    • Signature validation does not depend on the availability of Rekor
    • Rekor: provides an immutable and append-only ledger for storing signed metadata.
  • Rejects deployment of unsigned artifacts either on a cluster or namespace level **  ** 
    • The container runtime verifies the integrity of signed images, if a signature is present.
  • OpenShift payload images are signed and verified with Sigstore infrastructure
    • OpenShift payload images include: core images, operator catalogs, operator bundles, operator images, operators’ related images, sample imagestream, and Cincinnati graph images.
  • oc-mirror: Sigstore-style signatures should be mirrored by default with an opt-out option, while Sigstore-style attachments can optionally be discovered and mirrored.
    • OCPSTRAT-1417 oc-mirror automatically detects and mirror Sigstore-style attachments

• How are customers expected to interact with Sigstore-related features:
  • Customers leverage OpenShift Platform Plus to create trust relationships for running container images (and later on arbitrary artifacts or manifests) in a standardized way.
  • Customers can trust signed images from a Red Hat registry or their registry like Red Hat Quay and restrict running images only with trusted signatures.
  • OpenShifts container runtime is enforcing signature validation policies.  The rules can be defined for image signatures, registries, and other attributes, scoped to specific namespace(s) or across all namespaces:
    • Enforcement is configured on a per-namespace basis (or all namespaces)
    • Customers can define multiple policies and apply them to different namespaces. 
    • The policy controller can validate signatures, attestations, and other image attributes.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>