NOTE: All features will be tech-preview in the first release and then will graduate to GA in the next release or when it is ready for GA.

Epic Goal

• Runtime validation of container images using sigstore signatures.

Why is this important?

• The Red Hat-sponsored Sigstore project is gaining traction in the Kubernetes community, aiming to simplify the signing of cloud-native artifacts. OpenShift leverages Sigstore tooling to enable scalable and flexible signature validation, including support for disconnected environments. This functionality will be available as a Tech Preview in 4.17 and is targeted for General Availability (GA) in the upcoming 4.18 release. To fully support this integration, the (cluster)extension lifecycle management needs to (be prepared to) handle runtime validation of Sigstore signatures for container images.
•  

Scenarios

1. ...

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. Very high level intro questions:
   1. What is sigstore?
   2. How does it work?
   3. Where is it already integrated?
   4. Are there Go libraries available that abstract its core functionality?
2. Which OLM-related images do users expect to be subject to image signature verification?
3. How are users of OLM expected to interact with sigstore-related features?
   1. Will any OLM user want to enable or disable image signature verification separately from any defaults? If so, how is that expected to work for each of the following classes of images.
      1. For Catalogs
      2. For Bundles
      3. For operator and related images
   2. Will any OLM user want to be able to define specific verification configurations for catalog, bundle, operator, or operand images (e.g. a separate CA for verification)?
      1. If so, what sorts of things should be configurable?
   3. If an image is not signed, what is OLM expected to do?
   4. If an image signature is invalid, what is OLM expected to do?
4. Does this feature preclude OLM from using other distribution mechanisms and protocols?
5. Do all image registry clients need to perform image signature verification? If only a subset, why that particular subset? (Thinking of opm, kubectl-operator, etc.)
6. For the OLM content distribution persona, how can OLM facilitate signing of their OLM artifacts?
7. Is it sufficient to delegate all image signature verification functionality to an underlying CRI?
   1. If so, how will OLM users know if the underlying CRI implements image signature verification?
   2. If so, how will image signature verification work for non-runnable images
      1. helm OCI artifacts
      2. potential future for OLM-specific OCI artifacts for catalogs and bundles.

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>