Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1869

[Phase 1: Cosign tag-based discovery] oc-mirror v2: Discover and mirror SigStore-style attachments

XMLWordPrintable

    • Strategic Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • 100% To Do, 0% In Progress, 0% Done
    • 0

      Feature Overview (aka. Goal Summary)  

      oc-mirror v2 can mirror images and their associated signatures and public keys, providing flexibility for both current “SigStore/Cosign tag-based” and the future “OCI 1.1 referrer-based” discovery modes.

      Goals (aka. expected user outcomes)

      • oc-mirror v2 can discover and mirror image signatures alongside the images it mirrors, adhering to the Cosign tag convention.
      • oc-mirror v2 can also mirror public keys necessary for verifying image signatures, including Red Hat's public key for verifying Red Hat content. 
        • (Out of scope for Phase 1) and Rekor's public key for verifying signature transaction records for Red Hat content.
      • (Out of scope for Phase 1) In the future, oc-mirror v2 will prioritize discovering image signatures using the OCI 1.1 referrer-based approach, falling back to the SigStore/Cosign tag-based approach if necessary.
         

      Background

      As part of OCPSTRAT-918 and OCPSTRAT-1245, we’re extending OpenShift’s support for SigStore signatures, enabling scalable and flexible validation, including in offline environments.

      To facilitate offline verification, oc-mirror v2 will detect images with associated SigStore signatures.  Since Red Hat images currently don’t use the OCI referrer-based approach, oc-mirror v2 will initially focus on discovering and mirroring image signatures alongside images, following the SigStore/Cosign tag-based convention.  However, it’s designed to support the future OCI 1.1 referrer-based approach for seamless transition.

      Requirements (aka. Acceptance Criteria):

      • Cosign tag-based Signature Discovery: Identify and locate image signatures associated with target images, adhering to the Cosign tag convention.
      • Signature Verification: Support verifying the authenticity and integrity of the Red Hat image signatures using the public keys, including:
        • Red Hat's public key for verifying Red Hat content.
        • (Out of scope for Phase 1) Rekor's public key for verifying signature transaction records for Red Hat content.
      • Signature Mirroring: Mirror image signatures alongside the corresponding images.
        • Users can disable signature mirroring via a configuration option to prevent mirroring failures from blocking the overall image mirroring process.
      • Public Key Mirroring (or made available offline): 
        • Mirror public keys required for signature verification, including:
          • Red Hat's public key for verifying Red Hat content.
          • (Out of scope for Phase 1) Rekor's public key for verifying signature transaction records for Red Hat content.
        • To support enclave use cases, mirror public keys and store them locally to enable offline verification. 
          • This may require special permissions to access the /etc directory for storage.

      Out of Scope in Phase 1

      High-level list of items that are out of scope.  Initial completion during Refinement status.

      • OCI 1.1 referrer-based Discovery: The tool should be able to discover signatures referenced in the OCI 1.1 image manifest.
      • SigStore-style Attachments Mirroring: SigStore-style attachments, such as SBOMs in formats like text/spdx or application/vnd.cyclonedx, should be optionally discoverable and mirrorable. 
        • Users can choose to enable this feature and specify the desired OCI media types.
      • Flexible Signature Discovery - OCI 1.1 First, Cosign Second: oc-mirror v2 will prioritize discovering image signatures using the OCI 1.1 referrer-based approach, falling back to the SigStore/Cosign tag-based approach if necessary.

       

      Documentation Considerations

      Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

      <your text here>

       

              rhn-coreos-tunwu Tony Wu
              rhn-coreos-tunwu Tony Wu
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: