-
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
I agree with Joe, we need to test this from OLM point of view. Specially because the core work got done as part of another feature.
Joe Lanford
added a comment - rhn-support-jiazha I think we may still want this to be tested in the context of OLM because OLM is the client that is reading/loading `/etc/containers/policy.json` and then using it when calling the containers/image library to pull an image.
It is possible that we have a bug in our code that is different than the code that exists in cri-o to pull images.
Joe Lanford
added a comment - rhn-support-jiazha I think we may still want this to be tested in the context of OLM because OLM is the client that is reading/loading `/etc/containers/policy.json` and then using it when calling the containers/image library to pull an image.
It is possible that we have a bug in our code that is different than the code that exists in cri-o to pull images. Joe Lanford
added a comment - rhn-support-jiazha We did not end up having time to do an official design for image signature verification in the 4.18 cycle. However, as part of https://issues.redhat.com/browse/OPRUN-3460 and the switch to using the containers/image library, we ended up having to implement something.
That something was to use whatever configuration we find in the mounted /etc/containers directory. And if nothing is found, don't do image signature verification.
Tests should verify that the cluster's global signature policy is honored when catalog and bundle images are pulled by catalogd and operator-controller. Because of the lack of design, the engineering team does not consider image signature verification to be a specific feature of OLMv1 (yet). However we may be able to retroactively write a design doc and declare it as a feature if it turns out the existing implementation is sufficient/correct.
If the implementation that occurred as part of OPRUN-3460 is buggy in its attempt to support image pulling, we can fix those as bugs. However if there are structural or conceptual problems with the current implementation, fixing those will require designs and the solution may not be backport-able.
Joe Lanford
added a comment - rhn-support-jiazha We did not end up having time to do an official design for image signature verification in the 4.18 cycle. However, as part of https://issues.redhat.com/browse/OPRUN-3460 and the switch to using the containers/image library, we ended up having to implement something .
That something was to use whatever configuration we find in the mounted /etc/containers directory. And if nothing is found, don't do image signature verification.
Tests should verify that the cluster's global signature policy is honored when catalog and bundle images are pulled by catalogd and operator-controller. Because of the lack of design, the engineering team does not consider image signature verification to be a specific feature of OLMv1 (yet). However we may be able to retroactively write a design doc and declare it as a feature if it turns out the existing implementation is sufficient/correct.
If the implementation that occurred as part of OPRUN-3460 is buggy in its attempt to support image pulling, we can fix those as bugs. However if there are structural or conceptual problems with the current implementation, fixing those will require designs and the solution may not be backport-able. Hi rhn-coreos-tunwu , sorry for the late reply. I don't think this feature is finished, but wait for jlanford@redhat.com 's confirmation.
lmohanty@redhat.com, jlanford@redhat.com, rhn-support-jiazha, do we end up verifying this work with the OCP 4.18 release? Were any tests done already?
Hi jlanford@redhat.com and lmohanty@redhat.com , since the branch readiness (November 20) is approaching, should we update the TargetVersion to openshift-4.19? Thanks!
Joe Lanford
added a comment - I unset targetVersion (which was originally set to 4.18). We have not made any progress on this epic, and we are not expecting to deliver it in 4.18.
Joe Lanford
added a comment - I unset targetVersion (which was originally set to 4.18). We have not made any progress on this epic, and we are not expecting to deliver it in 4.18. 
Looks great! `tc-approved` label added.