Chapter 15. Image Pull Secrets


15.1. Overview

Docker registries can be secured to prevent unauthorized parties from accessing certain images. If you are using OpenShift’s integrated Docker registry and are pulling from image streams located in the same project, then your pod’s service account should already have permissions and no additional action should be required. If this is not the case, then additional configuration steps are required.

15.2. Integrated Registry Authentication and Authorization

OpenShift’s integrated Docker registry authenticates using the same tokens as the OpenShift API. To perform a docker login against the integrated registry, you can choose any user name and email, but the password must be a valid OpenShift token. In order to pull an image, the authenticated user must have get rights on the requested imagestreams/layers. In order to push an image, the authenticated user must have update rights on the requested imagestreams/layers.

By default, all service accounts in a project have rights to pull any image in the same project, and the builder service account has rights to push any image in the same project.

15.2.1. Allowing Pods to Reference Images Across Projects

When using the integrated 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:

Copy to Clipboard Toggle word wrap
$ 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 will be able to pull images from project-b.

To allow access for any service account in project-a, use the group:

Copy to Clipboard Toggle word wrap
$ oc policy add-role-to-group \
    system:image-puller system:serviceaccounts:project-a \
    --namespace=project-b

15.3. Allowing Pods to Reference Images from Other Secured Registries

To pull a secured Docker image that is not from OpenShift’s integrated registry, you must create a secret and add it to your service account.

Note

Docker configuration files for storage of secrets has changed formats from .dockercfg to .docker/config.json

If you already have a file for the secured registry, you can create a secret from that file by running the following for .docker/config.json:

Copy to Clipboard Toggle word wrap
# oc secrets new <pull_secret_name> \
     .dockerconfigjson=path/to/.docker/config.json

Alternatively, run the following for .dockercfg:

Copy to Clipboard Toggle word wrap
$ oc secrets new <pull_secret_name> \
    .dockercfg=<path/to/.dockercfg>

If you do not already have a file for the secured registry, you can create a secret by running:

Copy to Clipboard Toggle word wrap
$ oc secrets new-dockercfg <pull_secret_name> \
    --docker-server=<registry_server> --docker-username=<user_name> \
    --docker-password=<password> --docker-email=<email>

To use a secret for pulling images for pods, you must add the secret to your service account. The name of the service account in this example should match the name of the service account the pod will use; default is the default service account:

Copy to Clipboard Toggle word wrap
$ oc secrets add serviceaccount/default secrets/<pull_secret_name> --for=pull

To use a secret for pushing and pulling build images, the secret must be mountable inside of a pod. You can do this by running:

Copy to Clipboard Toggle word wrap
$ oc secrets add serviceaccount/builder secrets/<pull_secret_name>
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.