This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.9.2. Configuring image settings
You can configure image registry settings by editing the image.config.openshift.io/cluster custom resource (CR). The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster CR for any changes to the registries and reboots the nodes when it detects changes.
Procedure
Edit the
image.config.openshift.io/clustercustom resource:oc edit image.config.openshift.io/cluster
$ oc edit image.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is an example
image.config.openshift.io/clusterCR:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Image: Holds cluster-wide information about how to handle images. The canonical, and only valid name iscluster.- 2
allowedRegistriesForImport: Limits the container image registries from which normal users may import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images orImageStreamMappingsfrom the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.- 3
additionalTrustedCA: A reference to a config map containing additional certificate authorities (CA) that are trusted during image stream import, pod image pull,openshift-image-registrypullthrough, and builds. The namespace for this config map isopenshift-config. The format of the config map is to use the registry hostname as the key, and the PEM certificate as the value, for each additional registry CA to trust.- 4
registrySources: Contains configuration that determines how the container runtime should treat individual registries when accessing images for builds and pods. For instance, whether or not to allow insecure access. It does not contain configuration for the internal cluster registry. This example listsallowedRegistries, which defines the registries that are allowed to be used. One of the registries listed is insecure.
To check that the changes are applied, list your nodes:
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.1. Adding specific registries 复制链接链接已复制到粘贴板!
You can add a list of registries that are permitted for image pull and push actions by editing the image.config.openshift.io/cluster custom resource (CR). OpenShift Container Platform applies the changes to this CR to all nodes in the cluster.
When pulling or pushing images, the container runtime searches the registries listed under the registrySources parameter in the image.config.openshift.io/cluster CR. If you created a list of registries under the allowedRegistries parameter, the container runtime searches only those registries. Registries not in the list are blocked.
When the allowedRegistries parameter is defined, all registries, including the registry.redhat.io and quay.io registries, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, you must add registry.redhat.io and quay.io to the allowedRegistries list, as they are required by payload images within your environment. For disconnected clusters, mirror registries must also be added.
Procedure
Edit the
image.config.openshift.io/clusterCR:oc edit image.config.openshift.io/cluster
$ oc edit image.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is an example
image.config.openshift.io/clusterCR with an allowed list:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
registrySources: Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.- 2
allowedRegistries: Registries to use for image pull and push actions. All other registries are blocked.
注意Either the
allowedRegistriesparameter or theblockedRegistriesparameter can be set, but not both.The Machine Config Operator (MCO) watches the
image.config.openshift.io/clusterCR for any changes to registries and reboots the nodes when it detects changes. Changes to the allowed registries creates or updates the image signature policy in the/host/etc/containers/policy.jsonfile on each node.To check that the registries have been added to the policy file, use the following command on a node:
cat /host/etc/containers/policy.json
$ cat /host/etc/containers/policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following policy indicates that only images from the example.com, quay.io, and registry.redhat.io registries are permitted for image pulls and pushes:
例 9.1. Example image signature policy file
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If your cluster uses the registrySources.insecureRegistries parameter, ensure that any insecure registries are included in the allowed list.
For example:
9.2.2. Blocking specific registries 复制链接链接已复制到粘贴板!
You can block any registry by editing the image.config.openshift.io/cluster custom resource (CR). OpenShift Container Platform applies the changes to this CR to all nodes in the cluster.
When pulling or pushing images, the container runtime searches the registries listed under the registrySources parameter in the image.config.openshift.io/cluster CR. If you created a list of registries under the blockedRegistries parameter, the container runtime does not search those registries. All other registries are allowed.
To prevent pod failure, do not add the registry.redhat.io and quay.io registries to the blockedRegistries list, as they are required by payload images within your environment.
Procedure
Edit the
image.config.openshift.io/clusterCR:oc edit image.config.openshift.io/cluster
$ oc edit image.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is an example
image.config.openshift.io/clusterCR with a blocked list:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
registrySources: Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.- 2
- Specify registries that should not be used for image pull and push actions. All other registries are allowed.
注意Either the
blockedRegistriesregistry or theallowedRegistriesregistry can be set, but not both.The Machine Config Operator (MCO) watches the
image.config.openshift.io/clusterCR for any changes to registries and reboots the nodes when it detects changes. Changes to the blocked registries appear in the/etc/containers/registries.conffile on each node.To check that the registries have been added to the policy file, use the following command on a node:
cat /host/etc/containers/registries.conf
$ cat /host/etc/containers/registries.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following example indicates that images from the
untrusted.comregistry are prevented for image pulls and pushes:Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.3. Allowing insecure registries 复制链接链接已复制到粘贴板!
You can add insecure registries by editing the image.config.openshift.io/cluster custom resource (CR). OpenShift Container Platform applies the changes to this CR to all nodes in the cluster.
Registries that do not use valid SSL certificates or do not require HTTPS connections are considered insecure.
Insecure external registries should be avoided to reduce possible security risks.
Procedure
Edit the
image.config.openshift.io/clusterCR:oc edit image.config.openshift.io/cluster
$ oc edit image.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is an example
image.config.openshift.io/clusterCR with an insecure registries list:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
registrySources: Contains configurations that determine how the container runtime should treat individual registries when accessing images for builds and pods. It does not contain configuration for the internal cluster registry.- 2
- Specify an insecure registry.
- 3
- Ensure that any insecure registries are included in the
allowedRegistrieslist.
注意When the
allowedRegistriesparameter is defined, all registries, including the registry.redhat.io and quay.io registries, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, you must addregistry.redhat.ioandquay.ioto theallowedRegistrieslist, as they are required by payload images within your environment. Do not add theregistry.redhat.ioandquay.ioregistries to theblockedRegistrieslist.The Machine Config Operator (MCO) watches the
image.config.openshift.io/clusterCR for any changes to registries and reboots the nodes when it detects changes. Changes to the insecure and blocked registries appear in the/etc/containers/registries.conffile on each node.To check that the registries have been added to the policy file, use the following command on a node:
cat /host/etc/containers/registries.conf
$ cat /host/etc/containers/registries.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following example indicates that images from the
insecure.comregistry is insecure and is allowed for image pulls and pushes.Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The image.config.openshift.io/cluster custom resource can contain a reference to a config map that contains additional certificate authorities to be trusted during image registry access.
Prerequisites
- The certificate authorities (CA) must be PEM-encoded.
Procedure
You can create a config map in the openshift-config namespace and use its name in AdditionalTrustedCA in the image.config.openshift.io custom resource to provide additional CAs that should be trusted when contacting external registries.
The config map key is the host name of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate is the value, for each additional registry CA to trust.
Image registry CA config map example
- 1
- If the registry has the port, such as
registry-with-port.example.com:5000,:should be replaced with...
You can configure additional CAs with the following procedure.
To configure an additional CA:
oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
$ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc edit image.config.openshift.io cluster
$ oc edit image.config.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec: additionalTrustedCA: name: registry-configspec: additionalTrustedCA: name: registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.5. Configuring image registry repository mirroring 复制链接链接已复制到粘贴板!
Setting up container registry repository mirroring enables you to do the following:
- Configure your OpenShift Container Platform cluster to redirect requests to pull images from a repository on a source image registry and have it resolved by a repository on a mirrored image registry.
- Identify multiple mirrored repositories for each target repository, to make sure that if one mirror is down, another can be used.
The attributes of repository mirroring in OpenShift Container Platform include:
- Image pulls are resilient to registry downtimes.
- Clusters in restricted networks can pull images from critical locations, such as quay.io, and have registries behind a company firewall provide the requested images.
- A particular order of registries is tried when an image pull request is made, with the permanent registry typically being the last one tried.
-
The mirror information you enter is added to the
/etc/containers/registries.conffile on every node in the OpenShift Container Platform cluster. - When a node makes a request for an image from the source repository, it tries each mirrored repository in turn until it finds the requested content. If all mirrors fail, the cluster tries the source repository. If successful, the image is pulled to the node.
Setting up repository mirroring can be done in the following ways:
At OpenShift Container Platform installation:
By pulling container images needed by OpenShift Container Platform and then bringing those images behind your company’s firewall, you can install OpenShift Container Platform into a datacenter that is in a restricted network.
After OpenShift Container Platform installation:
Even if you don’t configure mirroring during OpenShift Container Platform installation, you can do so later using the
ImageContentSourcePolicyobject.
The following procedure provides a post-installation mirror configuration, where you create an ImageContentSourcePolicy object that identifies:
- The source of the container image repository you want to mirror.
- A separate entry for each mirror repository you want to offer the content requested from the source repository.
You can only configure global pull secrets for clusters that have an ImageContentSourcePolicy object. You cannot add a pull secret to a project.
Prerequisites
-
Access to the cluster as a user with the
cluster-adminrole.
Procedure
Configure mirrored repositories, by either:
- Setting up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.
Using a tool such as
skopeoto copy images manually from the source directory to the mirrored repository.For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL) 7 or RHEL 8 system, use the
skopeocommand as shown in this example:skopeo copy \ docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \ docker://example.io/example/ubi-minimal
$ skopeo copy \ docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \ docker://example.io/example/ubi-minimalCopy to Clipboard Copied! Toggle word wrap Toggle overflow In this example, you have a container image registry that is named
example.iowith an image repository namedexampleto which you want to copy theubi8/ubi-minimalimage fromregistry.access.redhat.com. After you create the registry, you can configure your OpenShift Container Platform cluster to redirect requests made of the source repository to the mirrored repository.
- Log in to your OpenShift Container Platform cluster.
Create an
ImageContentSourcePolicyfile (for example,registryrepomirror.yaml), replacing the source and mirrors with your own registry and repository pairs and images:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the new
ImageContentSourcePolicyobject:oc create -f registryrepomirror.yaml
$ oc create -f registryrepomirror.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow After the
ImageContentSourcePolicyobject is created, the new settings are deployed to each node and the cluster starts using the mirrored repository for requests to the source repository.To check that the mirrored configuration settings, are applied, do the following on one of the nodes.
List your nodes:
oc get node
$ oc get nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can see that scheduling on each worker node is disabled as the change is being applied.
Start the debugging process to access the node:
oc debug node/ip-10-0-147-35.ec2.internal
$ oc debug node/ip-10-0-147-35.ec2.internalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`
Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host`Copy to Clipboard Copied! Toggle word wrap Toggle overflow Access the node’s files:
chroot /host
sh-4.2# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check the
/etc/containers/registries.conffile to make sure the changes were made:cat /etc/containers/registries.conf
sh-4.2# cat /etc/containers/registries.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pull an image digest to the node from the source and check if it is resolved by the mirror.
ImageContentSourcePolicyobjects support image digests only, not image tags.podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Troubleshooting repository mirroring
If the repository mirroring procedure does not work as described, use the following information about how repository mirroring works to help troubleshoot the problem.
- The first working mirror is used to supply the pulled image.
- The main registry is only used if no other mirror works.
-
From the system context, the
Insecureflags are used as fallback. -
The format of the
/etc/containers/registries.conffile has changed recently. It is now version 2 and in TOML format.
Additional resources
For more information about global pull secrets, see Updating the global cluster pull secret.