-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
Runtime validation of container images using sigstore signatures
-
Strategic Product Work
-
11
-
False
-
None
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-1347 - [GA release] Next-gen OLM (OLM v1)
-
-
0% To Do, 0% In Progress, 100% Done
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
- ...
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- Very high level intro questions:
- What is sigstore?
- How does it work?
- Where is it already integrated?
- Are there Go libraries available that abstract its core functionality?
- Which OLM-related images do users expect to be subject to image signature verification?
- How are users of OLM expected to interact with sigstore-related features?
- 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.
- For Catalogs
- For Bundles
- For operator and related images
- 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)?
- If so, what sorts of things should be configurable?
- If an image is not signed, what is OLM expected to do?
- If an image signature is invalid, what is OLM expected to do?
- 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.
- Does this feature preclude OLM from using other distribution mechanisms and protocols?
- 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.)
- For the OLM content distribution persona, how can OLM facilitate signing of their OLM artifacts?
- Is it sufficient to delegate all image signature verification functionality to an underlying CRI?
- If so, how will OLM users know if the underlying CRI implements image signature verification?
- If so, how will image signature verification work for non-runnable images
- helm OCI artifacts
- 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>
- relates to
-
-
- Closed
-
-
-
- Closed
-
[OPRUN-3470] Runtime validation of container images using sigstore signatures
| Parent Link |
New:
|
| Priority | Original: Undefined [ 10300 ] | New: Major [ 3 ] |
| Description |
Original:
[OCP/Telco Definition of Done|https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde]
[Epic Template descriptions and documentation.|https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit] *{color:#ff0000}<--- Cut-n-Paste the entire contents of this description into your new Epic --->{color}* h1. Epic Goal * 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{*}. h2. Why is this important? * … h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
New:
[OCP/Telco Definition of Done|https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde]
[Epic Template descriptions and documentation.|https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit] *{color:#ff0000}<--- Cut-n-Paste the entire contents of this description into your new Epic --->{color}* h1. Epic Goal * h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
| Description |
Original:
[OCP/Telco Definition of Done|https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde]
[Epic Template descriptions and documentation.|https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit] *{color:#ff0000}<--- Cut-n-Paste the entire contents of this description into your new Epic --->{color}* h1. Epic Goal * h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
New:
[OCP/Telco Definition of Done|https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde]
[Epic Template descriptions and documentation.|https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit] *{color:#ff0000}<--- Cut-n-Paste the entire contents of this description into your new Epic --->{color}* h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
| Summary | Original: Runtime validation of sigstore signatures for container images. | New: Runtime validation of container images using sigstore signatures |
| Epic Name | Original: Runtime validation of sigstore signatures for container images. | New: Runtime validation of container images using sigstore signatures |
| Description |
Original:
[OCP/Telco Definition of Done|https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde]
[Epic Template descriptions and documentation.|https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit] *{color:#ff0000}<--- Cut-n-Paste the entire contents of this description into your new Epic --->{color}* h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
New:
h1. NOTE: All features will be tech-preview in the first release and then will graduate to GA
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
| Description |
Original:
h1. NOTE: All features will be tech-preview in the first release and then will graduate to GA
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
New:
h1. 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.
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
| Target Version | New: openshift-4.18 [ 12425404 ] |
Joe Lanford
made changes -
| Description |
Original:
h1. 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.
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # … h2. 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> |
New:
h1. 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.
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # Which images do users expect to be subject to image signature verification? # How are users of OLM expected to interact with sigstore-related features? ## Will any OLM user want to disable image signature verification? If so, how is that expected to work for each of the following classes of images. ### For Catalogs ### For Bundles ### For operator and related images ## Will any OLM user want to be able to define specific verification configurations for catalog, bundle, operator, or operand images? ### If so, what sorts of things should be configurable? ## If an image is not signed, what is OLM expected to do? ## If an image signature is invalid, what is OLM expected to do? ## How does OLM # Does this feature preclude OLM from using other distribution mechanisms and protocols? # 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.) # What tools exist that will enable OLM artifacts to be signed when pushed to a registry? ## How will we integrate those tools? h2. 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> |
Joe Lanford
made changes -
| Description |
Original:
h1. 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.
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # Which images do users expect to be subject to image signature verification? # How are users of OLM expected to interact with sigstore-related features? ## Will any OLM user want to disable image signature verification? If so, how is that expected to work for each of the following classes of images. ### For Catalogs ### For Bundles ### For operator and related images ## Will any OLM user want to be able to define specific verification configurations for catalog, bundle, operator, or operand images? ### If so, what sorts of things should be configurable? ## If an image is not signed, what is OLM expected to do? ## If an image signature is invalid, what is OLM expected to do? ## How does OLM # Does this feature preclude OLM from using other distribution mechanisms and protocols? # 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.) # What tools exist that will enable OLM artifacts to be signed when pushed to a registry? ## How will we integrate those tools? h2. 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> |
New:
h1. 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.
h1. Epic Goal * Runtime validation of container images using sigstore signatures. h2. 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{*}. * h2. Scenarios # ... h2. Acceptance Criteria * CI - MUST be running successfully with tests automated * Release Technical Enablement - Provide necessary release enablement details and documents. * ... h2. Dependencies (internal and external) # ... h2. Previous Work (Optional): # … h2. Open questions:: # Very high level intro questions: ## What is sigstore? ## How does it work? ## Where is it already integrated? ## Are there Go libraries available that abstract its core functionality? # Which OLM-related images do users expect to be subject to image signature verification? # How are users of OLM expected to interact with sigstore-related features? ## 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. ### For Catalogs ### For Bundles ### For operator and related images ## 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)? ### If so, what sorts of things should be configurable? ## If an image is not signed, what is OLM expected to do? ## If an image signature is invalid, what is OLM expected to do? # Does this feature preclude OLM from using other distribution mechanisms and protocols? # 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.) # For the OLM content distribution persona, how can OLM facilitate signing of their OLM artifacts? # Is it sufficient to delegate all image signature verification functionality to an underlying CRI? ## If so, how will OLM users know if the underlying CRI implements image signature verification? ## If so, how will image signature verification work for non-runnable images ### helm OCI artifacts ### potential future for OLM-specific OCI artifacts for catalogs and bundles. h2. 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> |
Joe Lanford
made changes -
| Link |
New:
This issue relates to |
Joe Lanford
made changes -
| Link |
New:
This issue relates to |
OpenShift Jira Automation Bot
made changes -
| Work Type | New: BU Product Work [ 40155 ] |
Joe Lanford
made changes -
| Target Version | Original: openshift-4.18 [ 12425404 ] |
| QA Contact | New: Jian Zhang [ jiazha ] |
OpenShift Jira Automation Bot
made changes -
| Work Type | Original: BU Product Work [ 40155 ] | New: Strategic Product Work [ 40154 ] |
OpenShift Jira Automation Bot
made changes -
| Work Type | Original: Strategic Product Work [ 40154 ] | New: BU Product Work [ 40155 ] |
Joe Lanford
made changes -
| Status | Original: New [ 10016 ] | New: Dev Complete [ 10822 ] |
Joe Lanford
made changes -
| Target Version | New: openshift-4.18 [ 12425404 ] |
OpenShift Jira Automation Bot
made changes -
| Work Type | Original: BU Product Work [ 40155 ] | New: Strategic Product Work [ 40154 ] |
OpenShift Jira Automation Bot
made changes -
| Work Type | Original: Strategic Product Work [ 40154 ] | New: BU Product Work [ 40155 ] |
OpenShift Jira Automation Bot
made changes -
| Work Type | Original: BU Product Work [ 40155 ] | New: Strategic Product Work [ 40154 ] |
| Link | New: This issue is related to OCPNODE-2253 [ OCPNODE-2253 ] |
| Labels | New: no-qe |
| Resolution | New: Done [ 1 ] | |
| Status | Original: Dev Complete [ 10822 ] | New: Release Pending [ 15735 ] |
| QA Contact | Original: Jian Zhang [ jiazha ] | New: Kui Wang [ kuiwang ] |
| Status | Original: Release Pending [ 15735 ] | New: Testing [ 15757 ] |
| Labels | Original: no-qe |
Joe Lanford
made changes -
| Labels | New: tc-approved |
Kui Wang
made changes -
| Status | Original: Testing [ 15757 ] | New: Release Pending [ 15735 ] |
| Status | Original: Release Pending [ 15735 ] | New: Closed [ 6 ] |
