Chapter 7. Image configuration resources
Use the following procedure to configure image registries.
7.1. Image controller configuration parameters
The image.config.openshift.io/cluster
resource holds cluster-wide information about how to handle images. The canonical, and only valid name is cluster
. Its spec
offers the following configuration parameters.
Parameter | Description |
---|---|
|
Every element of this list contains a location of the registry specified by the registry domain name. The domain name can include wildcards.
|
|
The namespace for this ConfigMap is |
|
|
|
|
| Holds cluster-wide information about how to handle the registries config.
Only one of |
When the allowedRegistries
parameter is defined, all registries including registry.redhat.io
and quay.io
are blocked unless explicitly listed. If using the parameter, declare source registries registry.redhat.io
and quay.io
as required by payload images within your environment, to prevent Pod failure. For disconnected clusters, mirror registries should also be added.
The status
field of the image.config.openshift.io/cluster
resource holds observed values from the cluster.
Parameter | Description |
---|---|
|
|
|
|
7.2. Configuring image settings
You can configure image registry settings by editing the image.config.openshift.io/cluster
resource. The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster
for any changes to registries and reboots the nodes when it detects changes.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
resource:apiVersion: config.openshift.io/v1 kind: Image1 metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport:2 - domainName: quay.io insecure: false additionalTrustedCA:3 name: myconfigmap registrySources:4 insecureRegistries:5 - insecure.com blockedRegistries:6 - untrusted.com status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 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 orImageStreamMappings
from the API are not affected by this policy. Typically only cluster administrators will have the appropriate permissions.- 3
additionalTrustedCA
: A reference to a ConfigMap containing additional CAs that should be trusted duringImageStream import
,pod image pull
,openshift-image-registry pullthrough
, and builds. The namespace for this ConfigMap isopenshift-config
. The format of the ConfigMap 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.- 5
insecureRegistries
: Registries which do not have a valid TLS certificate or only support HTTP connections.- 6
blockedRegistries
: Blacklisted for image pull and push actions. All other registries are allowed.
7.2.1. Importing insecure registries and blocking registries
You can add insecure registries or 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.
Insecure external registries, such as those do not have a valid TLS certificate or only support HTTP connections, should be avoided.
Procedure
Edit the
image.config.openshift.io/cluster
custom resource:$ oc edit image.config.openshift.io/cluster
The following is an example
image.config.openshift.io/cluster
resource:apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 1 name: cluster resourceVersion: "8302" selfLink: /apis/config.openshift.io/v1/images/cluster uid: e34555da-78a9-11e9-b92b-06d6c7da38dc spec: allowedRegistriesForImport: - domainName: quay.io insecure: false additionalTrustedCA: name: myconfigmap registrySources: insecureRegistries:1 - insecure.com blockedRegistries:2 - untrusted.com allowedRegistries: - quay.io 3 status: internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
- 1
- Specify an insecure registry.
- 2
- Specify registries that should be blacklisted for image pull and push actions. All other registries are allowed. Either
blockedRegistries
orallowedRegistries
can be set, but not both. - 3
- Specify registries that should be permitted for image pull and push actions. All other registries are denied. Either
blockedRegistries
orallowedRegistries
can be set, but not both.
The Machine Config Operator (MCO) watches the
image.config.openshift.io/cluster
for any changes to registries and reboots the nodes when it detects changes. Changes to the registries appear in the /host/etc/containers/registries.conf file on each node.cat /host/etc/containers/registries.conf [registries] [registries.search] registries = ["registry.access.redhat.com", "docker.io"] [registries.insecure] registries = ["insecure.com"] [registries.block] registries = ["untrusted.com"]
7.2.2. Configuring image registry repository mirroring
Setting up container registry repository mirroring lets you:
- 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.
Here are some of the attributes of repository mirroring in OpenShift Container Platform:
- Image pulls are resilient to registry downtimes
- Clusters in restricted networks can request to 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.conf
file 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. Upon success, the image is pulled to the node.
Setting up repository mirroring can be done in the following ways:
- At OpenShift Container Platform installation time: 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. See Mirroring the OpenShift Container Platform image repository for details.
-
After OpenShift Container Platform installation time: Even if you don’t configure mirroring during OpenShift Container Platform installation, you can do so later using the
ImageContentSourcePolicy
object.
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.
Prerequisites
-
Access to the cluster as a user with the
cluster-admin
role.
Procedure
Configure mirrored repositories. To do that, you can either:
- Set 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.
Use a tool such as
skopeo
to 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
skopeo
command as shown in this example:$ skopeo copy \ docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:c505667389712dc337986e29ffcb65116879ef27629dc3ce6e1b17727c06e78f \ docker://example.io/ubi8/ubi-minimal
In this example, you have a container image registry that is named
example.io
with an image repository namedexample
to which you want to copy theubi8/ubi-minimal
image 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
ImageContentSourcePolicy
file (for example,registryrepomirror.yaml
), replacing the source and mirrors with those of your own registry and repository pairs and images:apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: ubi8repo spec: repositoryDigestMirrors: - mirrors: - example.io/example/ubi-minimal1 source: registry.access.redhat.com/ubi8/ubi-minimal2 - mirrors: - example.com/example/ubi-minimal source: registry.access.redhat.com/ubi8/ubi-minimal
Create the new
ImageContentSourcePolicy
:$ oc create -f registryrepomirror.yaml
After the
ImageContentSourcePolicy
is created, the new settings are deployed to each node and shortly start using the mirrored repository for requests to the source repository.To check that the mirrored configuration worked, go to one of your nodes. For example:
List your nodes:
$ oc get node NAME STATUS ROLES AGE VERSION ip-10-0-137-44.ec2.internal Ready worker 7m v1.14.6+90fadebfa ip-10-0-138-148.ec2.internal Ready master 11m v1.14.6+90fadebfa ip-10-0-139-122.ec2.internal Ready master 11m v1.14.6+90fadebfa ip-10-0-147-35.ec2.internal Ready,SchedulingDisabled worker 7m v1.14.6+90fadebfa ip-10-0-153-12.ec2.internal Ready worker 7m v1.14.6+90fadebfa ip-10-0-154-10.ec2.internal Ready master 11m v1.14.6+90fadebfa
You can see that scheduling on each worker node is disabled as the change is being applied.
Check the
/etc/containers/registries.conf
file to make sure the changes were made:$ oc debug node/ip-10-0-147-35.ec2.internal Starting pod/ip-10-0-147-35ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# chroot /host sh-4.2# cat /etc/containers/registries unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] location = "registry.access.redhat.com/ubi8/" insecure = false blocked = false mirror-by-digest-only = true prefix = "" [[registry.mirror]] location = "example.io/example/ubi8-minimal" insecure = false [[registry.mirror]] location = "example.com/example/ubi8-minimal" insecure = false
Pull an image to the node from the source and check if it is actually resolved by the mirror.
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal
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 will only be used if no other mirror works.
-
From the system context, the
Insecure
flags are used as fallback. -
The format of the
/etc/containers/registries
file has changed recently. It is now version 2 and in TOML format.