Skip to content

OSDOCS Project-Scoped Image Pull Secrets for Mirrored Registries: GA #118568

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mburke5678 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

OSDOCS Project-Scoped Image Pull Secrets for Mirrored Registries: GA #118568

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions modules/images-configuration-registry-mirror-project-secret.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,6 @@ As a cluster administrator, you can edit the cluster-wide `CRIOCredentialProvide

By default, if your cluster uses an `ImageDigestMirrorSet`, `ImageTagMirrorSet`, or `ImageContentSourcePolicy` object to configure repository mirroring, you must use a global pull secret for mirrored registries. You cannot add an image pull secret to a project. However, you can use the cluster-wide `CRIOCredentialProviderConfig` object to configure the kubelet to trigger the CRI-O credential provider, which enables project-scoped image pull secrets.

:FeatureName: Project-scoped image pull secrets for mirrored registries
include::snippets/technology-preview.adoc[]

An administrator edits the `CRIOCredentialProviderConfig` object named `cluster`, to list the registries that a developer can pull from by using a project-scoped secret. The administrator then creates an image pull secret in each namespace where it is needed and configures role-based access control (RBAC) permissions that allow the pod's service account within that namespace to access the secret. The admin can create a different pull secret with different credentials for each namespace or use the same pull secret in multiple namespaces.

When a developer uses a pod spec in one of those namespaces to pull an image from a listed registry, the `CRIOCredentialProviderConfig` object triggers the CRI-O credential provider. The credential provider resolves mirror configurations, discovers namespace-scoped secrets, and generates short-lived authentication files for CRI-O consumption. This process maintains credential isolation between namespaces while preserving existing mirror configuration methods.
Expand All @@ -22,7 +19,7 @@ The following is an example `CRIOCredentialProviderConfig` object:

[source,terminal]
----
apiVersion: config.openshift.io/v1alpha1
apiVersion: config.openshift.io/v1
kind: CRIOCredentialProviderConfig
metadata:
name: cluster
Expand Down Expand Up @@ -82,7 +79,6 @@ In this example, the `crio-credential-provider` configuration was generated from
.Prerequisites

* You have access to the cluster as a user with the `cluster-admin` role.
* You have enabled the `TechPreviewNoUpgrade` feature set in your cluster's `FeatureGate` custom resource (CR). For more information, see "Understanding feature gates".

// The pull secret step 2 is taken from creating-pull-secret
.Procedure
Expand Down Expand Up @@ -172,7 +168,7 @@ $ oc edit criocredentialproviderconfig cluster
+
[source,terminal]
----
apiVersion: config.openshift.io/v1alpha1
apiVersion: config.openshift.io/v1
kind: CRIOCredentialProviderConfig
metadata:
name: cluster
Expand Down