$ oc policy add-role-to-user \
system:image-puller system:serviceaccount:project-a:default \
--namespace=project-b
If you are using the OpenShift image registry and are pulling from image streams located in the same project, then your pod service account should already have the correct permissions and no additional action should be required.
However, for other scenarios, such as referencing images across OKD projects or from secured registries, additional configuration steps are required.
You can obtain the image pull secret from Red Hat OpenShift Cluster Manager. This pull secret is called pullSecret
.
You use this pull secret to authenticate with the services that are provided by the included authorities, Quay.io and registry.redhat.io, which serve the container images for OKD components.
When using the OpenShift image registry, to allow pods in project-a
to reference images in project-b
, a service account in project-a
must be bound to the system:image-puller
role in project-b
.
When you create a pod service account or a namespace, wait until the service account is provisioned with a docker pull secret; if you create a pod before its service account is fully provisioned, the pod fails to access the OpenShift image registry. |
To allow pods in project-a
to reference images in project-b
, bind a service account in project-a
to the system:image-puller
role in project-b
:
$ oc policy add-role-to-user \
system:image-puller system:serviceaccount:project-a:default \
--namespace=project-b
After adding that role, the pods in project-a
that reference the default service account are able to pull images from project-b
.
To allow access for any service account in project-a
, use the group:
$ oc policy add-role-to-group \
system:image-puller system:serviceaccounts:project-a \
--namespace=project-b
To pull a secured container from other private or secured registries, you must create a pull secret from your container client credentials, such as Docker or Podman, and add it to your service account.
Both Docker and Podman use a configuration file to store authentication details to log in to secured or insecure registry:
Docker: By default, Docker uses $HOME/.docker/config.json
.
Podman: By default, Podman uses $HOME/.config/containers/auth.json
.
These files store your authentication information if you have previously logged in to a secured or insecure registry.
Both Docker and Podman credential files and the associated pull secret can contain multiple references to the same registry if they have unique paths, for example, |
config.json
file{
"auths":{
"cloud.openshift.com":{
"auth":"b3Blb=",
"email":"you@example.com"
},
"quay.io":{
"auth":"b3Blb=",
"email":"you@example.com"
},
"quay.io/repository-main":{
"auth":"b3Blb=",
"email":"you@example.com"
}
}
}
apiVersion: v1
data:
.dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
creationTimestamp: "2021-09-09T19:10:11Z"
name: pull-secret
namespace: default
resourceVersion: "37676"
uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque
Create a secret from an existing authentication file:
For Docker clients using .docker/config.json
, enter the following command:
$ oc create secret generic <pull_secret_name> \
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
--type=kubernetes.io/dockerconfigjson
For Podman clients using .config/containers/auth.json
, enter the following command:
$ oc create secret generic <pull_secret_name> \
--from-file=<path/to/.config/containers/auth.json> \
--type=kubernetes.io/podmanconfigjson
If you do not already have a Docker credentials file for the secured registry, you can create a secret by running the following command:
$ oc create secret docker-registry <pull_secret_name> \
--docker-server=<registry_server> \
--docker-username=<user_name> \
--docker-password=<password> \
--docker-email=<email>
You can use a pull secret to allow workloads to pull images from a private registry with one of the following methods:
By linking the secret to a ServiceAccount
, which automatically applies the secret to all pods using that service account.
By defining imagePullSecrets
directly in workload configurations, which is useful for environments like GitOps or ArgoCD.
You can use a secret for pulling images for pods by adding the secret to your service account. Note that the name of the service account should match the name of the service account that pod uses. The default service account is default
.
Enter the following command to link the pull secret to a ServiceAccount
:
$ oc secrets link default <pull_secret_name> --for=pull
To verify the change, enter the following command:
$ oc get serviceaccount default -o yaml
apiVersion: v1
imagePullSecrets:
- name: default-dockercfg-123456
- name: <pull_secret_name>
kind: ServiceAccount
metadata:
annotations:
openshift.io/internal-registry-pull-secret-ref: <internal_registry_pull_secret>
creationTimestamp: "2025-03-03T20:07:52Z"
name: default
namespace: default
resourceVersion: "13914"
uid: 9f62dd88-110d-4879-9e27-1ffe269poe3
secrets:
- name: <pull_secret_name>
Instead of linking the secret to a service account, you can alternatively reference it directly in your pod or workload definition. This is useful for GitOps workflows such as ArgoCD. For example:
apiVersion: v1
kind: Pod
metadata:
name: <secure_pod_name>
spec:
containers:
- name: <container_name>
image: quay.io/my-private-image
imagePullSecrets:
- name: <pull_secret_name>
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: <example_workflow>
spec:
entrypoint: <main_task>
imagePullSecrets:
- name: <pull_secret_name>
A private registry can delegate authentication to a separate service. In these cases, image pull secrets must be defined for both the authentication and registry endpoints.
Create a secret for the delegated authentication server:
$ oc create secret docker-registry \
--docker-server=sso.redhat.com \
--docker-username=developer@example.com \
--docker-password=******** \
--docker-email=unused \
redhat-connect-sso
secret/redhat-connect-sso
Create a secret for the private registry:
$ oc create secret docker-registry \
--docker-server=privateregistry.example.com \
--docker-username=developer@example.com \
--docker-password=******** \
--docker-email=unused \
private-registry
secret/private-registry
You can update the global pull secret for your cluster by either replacing the current pull secret or appending a new pull secret.
To transfer your cluster to another owner, you must first initiate the transfer in OpenShift Cluster Manager, and then update the pull secret on the cluster. Updating a cluster’s pull secret without initiating the transfer in OpenShift Cluster Manager causes the cluster to stop reporting Telemetry metrics in OpenShift Cluster Manager. For more information about transferring cluster ownership, see "Transferring cluster ownership" in the Red Hat OpenShift Cluster Manager documentation. |
You have access to the cluster as a user with the cluster-admin
role.
Optional: To append a new pull secret to the existing pull secret, complete the following steps:
Enter the following command to download the pull secret:
$ oc get secret/pull-secret -n openshift-config \
--template='{{index .data ".dockerconfigjson" | base64decode}}' \
><pull_secret_location> (1)
1 | Provide the path to the pull secret file. |
Enter the following command to add the new pull secret:
$ oc registry login --registry="<registry>" \ (1)
--auth-basic="<username>:<password>" \ (2)
--to=<pull_secret_location> (3)
1 | Provide the new registry. You can include multiple repositories within the same registry, for example: --registry="<registry/my-namespace/my-repository>" . |
2 | Provide the credentials of the new registry. |
3 | Provide the path to the pull secret file. |
Alternatively, you can perform a manual update to the pull secret file.
Enter the following command to update the global pull secret for your cluster:
$ oc set data secret/pull-secret -n openshift-config \
--from-file=.dockerconfigjson=<pull_secret_location> (1)
1 | Provide the path to the new pull secret file. |
This update is rolled out to all nodes, which can take some time depending on the size of your cluster.
As of OKD 4.7.4, changes to the global pull secret no longer trigger a node drain or reboot. |