OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

This feature enables OpenShift users to leverage project-level imagePullSecrets for authenticating with mirrored image registries configured via ImageContentSourcePolicy (ICSP), ImageDigestMirrorSet (IDMS), and ImageTagMirrorSet (ITMS). This will enhance security by allowing granular access control to mirrored images within multi-tenant clusters, eliminating the need to expose sensitive credentials globally.

Why is this important?

The outlined scenario below demonstrates how admins can create secrets for certain mirrors within a Kubernetes namespace. Users can then create workloads without caring about the mirror itself, even when the resolved registry requires authentication.

Scenario

1. Admin creates the mirror configuration using IDMS/ITMS/ICSP to map registry.local to mirror.local
2. Admin creates an image pull secret for mirror.local 
3. User creates pod to pull image from registry.local
4. Credential provider resolves auth data for mirror.local and provides that to the kubelet
5. CRI-O will use the credentials for mirror.local and also pull from that registry

Acceptance Criteria

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

Dependencies (internal and external)

• Upstream feature KubeletServiceAccountTokenForCredentialProviders, which has been graduated to beta in Kubernetes v1.34.

Previous Work (Optional):

Most of the previous work is covered by:

• A Miro board outlining the whole scenario and configuration: https://miro.com/app/board/uXjVJP4ugG8=/?share_link_id=405058885452
• A shell-script based PoC: https://gist.github.com/saschagrunert/0f1f89bbfd29eea7ba94eb1aa1059cdb

Open questions::

• Does the MCO have to do the configuration part or can it be static?

Concerns

• Accessing the kube API will introduce a performance penalty.
• Accessing the kube API will inherently add a security risk.
• Shipping a new binary will increase maintenance effort.

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>