Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 9. Image configuration resources

Use the following procedure to configure image registries.

9.1. Image controller configuration parameters
Copiar enlace

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.

Note

Parameters such as 

DisableScheduledImport
, 
MaxImagesBulkImportedPerRepository
, 
MaxScheduledImportsPerMinute
, 
ScheduledImageImportMinimumIntervalSeconds
, 
InternalRegistryHostname
are not configurable.

Expand
ParameterDescription

allowedRegistriesForImport

Limits the container image registries from which normal users can 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 or 

ImageStreamMappings
from the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.

Every element of this list contains a location of the registry specified by the registry domain name. 

domainName
: Specifies a domain name for the registry. In case the registry uses a non-standard 
80
or 
443
port, the port should be included in the domain name as well. 

insecure
: Insecure indicates whether the registry is secure or insecure. By default, if not otherwise specified, the registry is assumed to be secure. 

additionalTrustedCA

A reference to a config map containing additional CAs that should be trusted during 

image stream import
, 
pod image pull
, 
openshift-image-registry pullthrough
, and builds.

The namespace for this config map is 

openshift-config
. The format of the config map is to use the registry hostname as the key, and the PEM-encoded certificate as the value, for each additional registry CA to trust. 

externalRegistryHostnames

Provides the hostnames for the default external image registry. The external hostname should be set only when the image registry is exposed externally. The first value is used in 

publicDockerImageRepository
field in image streams. The value must be in 
hostname[:port]
format. 

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. 

insecureRegistries
: Registries which do not have a valid TLS certificate or only support HTTP connections. You can specify an individual repository within a registry. For example: 
reg1.io/myrepo/myapp:latest
. 

blockedRegistries
: Registries for which image pull and push actions are denied. You can specify an individual repository within a registry. For example: 
reg1.io/myrepo/myapp:latest
. All other registries are allowed. 

allowedRegistries
: Registries for which image pull and push actions are allowed. You can specify an individual repository within a registry. For example: 
reg1.io/myrepo/myapp:latest
. All other registries are blocked. 

containerRuntimeSearchRegistries
: Registries for which image pull and push actions are allowed using image short names. All other registries are blocked.

Either 

blockedRegistries
or 
allowedRegistries
can be set, but not both.

Warning

When the 

allowedRegistries
parameter is defined, all registries, including 
registry.redhat.io
and 
quay.io
registries and the default internal image registry, are blocked unless explicitly listed. When using the parameter, to prevent pod failure, add all registries including the 
registry.redhat.io
and 
quay.io
registries and the 
internalRegistryHostname
to the 
allowedRegistries
list, as they are required by payload images within your environment. 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.

Expand
ParameterDescription

internalRegistryHostname

Set by the Image Registry Operator, which controls the 

internalRegistryHostname
. It sets the hostname for the default internal image registry. The value must be in 
hostname[:port]
format. For backward compatibility, you can still use the 
OPENSHIFT_DEFAULT_REGISTRY
environment variable, but this setting overrides the environment variable. 

externalRegistryHostnames

Set by the Image Registry Operator, provides the external hostnames for the image registry when it is exposed externally. The first value is used in 

publicDockerImageRepository
field in image streams. The values must be in 
hostname[:port]
format.

9.2. Configuring image registry settings
Copiar enlace

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

  1. 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
    CR: 

    apiVersion: config.openshift.io/v1
kind: Image
    1 
    
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 
    
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - image-registry.openshift-image-registry.svc:5000
    - reg1.io/myrepo/myapp:latest
    insecureRegistries:
    - insecure.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 is cluster.
    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 or ImageStreamMappings from 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-registry pullthrough, and builds. The namespace for this config map is openshift-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 whether the container runtime allows or blocks individual registries when accessing images for builds and pods. Either the allowedRegistries parameter or the blockedRegistries parameter can be set, but not both. You can also define whether or not to allow access to insecure registries or registries that allow registries that use image short names. This example uses the allowedRegistries parameter, which defines the registries that are allowed to be used. The insecure registry insecure.com is also allowed. The registrySources paramter does not contain configuration for the internal cluster registry.
    Note

    When the 

    allowedRegistries
    parameter is defined, all registries, including the registry.redhat.io and quay.io registries and the default internal image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, you must add the 
    registry.redhat.io
    and 
    quay.io
    registries and the 
    internalRegistryHostname
    to the 
    allowedRegistries
    list, as they are required by payload images within your environment. Do not add the 
    registry.redhat.io
    and 
    quay.io
    registries to the 
    blockedRegistries
    list.

    When using the 

    allowedRegistries
    , 
    blockedRegistries
    , or 
    insecureRegistries
    parameter, you can specify an individual repository within a registry. For example: 
    reg1.io/myrepo/myapp:latest
    .

    Insecure external registries should be avoided to reduce possible security risks.

  2. To check that the changes are applied, list your nodes: 

    $ oc get nodes

    Example output

    NAME                                       STATUS                     ROLES    AGE   VERSION
ci-ln-j5cd0qt-f76d1-vfj5x-master-0         Ready                         master   98m   v1.19.0+7070803
ci-ln-j5cd0qt-f76d1-vfj5x-master-1         Ready,SchedulingDisabled      master   99m   v1.19.0+7070803
ci-ln-j5cd0qt-f76d1-vfj5x-master-2         Ready                         master   98m   v1.19.0+7070803
ci-ln-j5cd0qt-f76d1-vfj5x-worker-b-nsnd4   Ready                         worker   90m   v1.19.0+7070803
ci-ln-j5cd0qt-f76d1-vfj5x-worker-c-5z2gz   NotReady,SchedulingDisabled   worker   90m   v1.19.0+7070803
ci-ln-j5cd0qt-f76d1-vfj5x-worker-d-stsjv   Ready                         worker   90m   v1.19.0+7070803

9.2.1. Adding specific registries
Copiar enlace

You can add a list of registries, and optionally an individual repository within a registry, 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.

Warning

When the 

allowedRegistries
parameter is defined, all registries, including the 
registry.redhat.io
and 
quay.io
registries and the default internal image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, add the 
registry.redhat.io
and 
quay.io
registries and the 
internalRegistryHostname
to the 
allowedRegistries
list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.

Procedure

  1. Edit the 

    image.config.openshift.io/cluster
    CR: 

    $ oc edit image.config.openshift.io/cluster

    The following is an example 

    image.config.openshift.io/cluster
    CR with an allowed list: 

    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:
  registrySources:
    1 
    
    allowedRegistries:
    2 
    
    - example.com
    - quay.io
    - registry.redhat.io
    - reg1.io/myrepo/myapp:latest
    - image-registry.openshift-image-registry.svc:5000
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    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, and optionally a repository in that registry, to use for image pull and push actions. All other registries are blocked.
    Note

    Either the 

    allowedRegistries
    parameter or the 
    blockedRegistries
    parameter can be set, but not both.

    The Machine Config Operator (MCO) watches the 

    image.config.openshift.io/cluster
    resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the 
    Ready
    state, the allowed registries list is used to update the image signature policy in the 
    /host/etc/containers/policy.json
    file on each node.

  2. 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

    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:

    Example 9.1. Example image signature policy file

    {
   "default":[
      {
         "type":"reject"
      }
   ],
   "transports":{
      "atomic":{
         "example.com":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "image-registry.openshift-image-registry.svc:5000":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "insecure.com":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "quay.io":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "reg4.io/myrepo/myapp:latest":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "registry.redhat.io":[
            {
               "type":"insecureAcceptAnything"
            }
         ]
      },
      "docker":{
         "example.com":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "image-registry.openshift-image-registry.svc:5000":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "insecure.com":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "quay.io":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "reg4.io/myrepo/myapp:latest":[
            {
               "type":"insecureAcceptAnything"
            }
         ],
         "registry.redhat.io":[
            {
               "type":"insecureAcceptAnything"
            }
         ]
      },
      "docker-daemon":{
         "":[
            {
               "type":"insecureAcceptAnything"
            }
         ]
      }
   }
}
Note

If your cluster uses the 

registrySources.insecureRegistries
parameter, ensure that any insecure registries are included in the allowed list.

For example: 

spec:
  registrySources:
    insecureRegistries:
    - insecure.com
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    - image-registry.openshift-image-registry.svc:5000

9.2.2. Blocking specific registries
Copiar enlace

You can block any registry, and optionally an individual repository within a 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.

Warning

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

  1. Edit the 

    image.config.openshift.io/cluster
    CR: 

    $ oc edit image.config.openshift.io/cluster

    The following is an example 

    image.config.openshift.io/cluster
    CR with a blocked list: 

    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:
  registrySources:
    1 
    
    blockedRegistries:
    2 
    
    - untrusted.com
    - reg1.io/myrepo/myapp:latest
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    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, and optionally a repository in that registry, that should not be used for image pull and push actions. All other registries are allowed.
    Note

    Either the 

    blockedRegistries
    registry or the 
    allowedRegistries
    registry can be set, but not both.

    The Machine Config Operator (MCO) watches the 

    image.config.openshift.io/cluster
    resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the 
    Ready
    state, changes to the blocked registries appear in the 
    /etc/containers/registries.conf
    file on each node.

  2. 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

    The following example indicates that images from the 

    untrusted.com
    registry are prevented for image pulls and pushes:

    Example output

    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

[[registry]]
  prefix = ""
  location = "untrusted.com"
  blocked = true

9.2.3. Allowing insecure registries
Copiar enlace

You can add insecure registries, and optionally an individual repository within a 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.

Registries that do not use valid SSL certificates or do not require HTTPS connections are considered insecure.

Warning

Insecure external registries should be avoided to reduce possible security risks.

Procedure

  1. Edit the 

    image.config.openshift.io/cluster
    CR: 

    $ oc edit image.config.openshift.io/cluster

    The following is an example 

    image.config.openshift.io/cluster
    CR with an insecure registries list: 

    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:
  registrySources:
    1 
    
    insecureRegistries:
    2 
    
    - insecure.com
    - reg4.io/myrepo/myapp:latest
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    3 
    
    - reg4.io/myrepo/myapp:latest
    - image-registry.openshift-image-registry.svc:5000
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    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. You can specify a repository in that registry.
    3
    Ensure that any insecure registries are included in the allowedRegistries list.
    Note

    When the 

    allowedRegistries
    parameter is defined, all registries, including the registry.redhat.io and quay.io registries and the default internal image registry, are blocked unless explicitly listed. If you use the parameter, to prevent pod failure, add all registries including the 
    registry.redhat.io
    and 
    quay.io
    registries and the 
    internalRegistryHostname
    to the 
    allowedRegistries
    list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.

    The Machine Config Operator (MCO) watches the 

    image.config.openshift.io/cluster
    CR for any changes to the registries, then drains and uncordons the nodes when it detects changes. After the nodes return to the 
    Ready
    state, changes to the insecure and blocked registries appear in the 
    /etc/containers/registries.conf
    file on each node.

  2. 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

    The following example indicates that images from the 

    insecure.com
    registry is insecure and is allowed for image pulls and pushes.

    Example output

    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

[[registry]]
  prefix = ""
  location = "insecure.com"
  insecure = true

9.2.4. Adding registries that allow image short names
Copiar enlace

You can add registries to search for an image short name 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.

An image short name enables you to search for images without including the fully qualified domain name in the pull spec. For example, you could use 

rhel7/etcd
instead of 
registry.access.redhat.com/rhe7/etcd
.

You might use short names in situations where using the full path is not practical. For example, if your cluster references multiple internal registries whose DNS changes frequently, you would need to update the fully qualified domain names in your pull specs with each change. In this case, using an image short name might be beneficial.

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 
containerRuntimeSearchRegistries
parameter, when pulling an image with a short name, the container runtime searches those registries.

Warning

Using image short names with public registries is strongly discouraged. You should use image short names with only internal or private registries.

If you list public registries under the 

containerRuntimeSearchRegistries
parameter, you expose your credentials to all the registries on the list and you risk network and registry attacks. You should always use fully-qualified image names with public registries.

The Machine Config Operator (MCO) watches the 

image.config.openshift.io/cluster
resource for any changes to the registries. When the MCO detects a change, it drains the nodes, applies the change, and uncordons the nodes. After the nodes return to the 
Ready
state, if the 
containerRuntimeSearchRegistries
parameter is added, the MCO creates a file in the 
/etc/containers/registries.conf.d
directory on each node with the listed registries. The file overrides the default list of unqualified search registries in the 
/host/etc/containers/registries.conf
file. There is no way to fall back to the default list of unqualified search registries.

The 

containerRuntimeSearchRegistries
parameter works only with the Podman and CRI-O container engines. The registries in the list can be used only in pod specs, not in builds and image streams.

Procedure

  1. 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
    CR: 

    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:
    containerRuntimeSearchRegistries:
    1 
    
    - reg1.io
    - reg2.io
    - reg3.io
    allowedRegistries:
    2 
    
    - example.com
    - quay.io
    - registry.redhat.io
    - reg1.io
    - reg2.io
    - reg3.io
    - image-registry.openshift-image-registry.svc:5000
...
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    1
    Specify registries to use with image short names. You should use image short names with only internal or private registries to reduce possible security risks.
    2
    Ensure that any registries listed under containerRuntimeSearchRegistries are included in the allowedRegistries list.
    Note

    When the 

    allowedRegistries
    parameter is defined, all registries, including the 
    registry.redhat.io
    and 
    quay.io
    registries and the default internal image registry, are blocked unless explicitly listed. If you use this parameter, to prevent pod failure, add all registries including the 
    registry.redhat.io
    and 
    quay.io
    registries and the 
    internalRegistryHostname
    to the 
    allowedRegistries
    list, as they are required by payload images within your environment. For disconnected clusters, mirror registries should also be added.

  2. To check that the registries have been added, when a node returns to the 

    Ready
    state, use the following command on the node: 

    $ cat /host/etc/containers/registries.conf.d/01-image-searchRegistries.conf

    Example output

    unqualified-search-registries = ['reg1.io', 'reg2.io', 'reg3.io']

9.2.5. Configuring additional trust stores for image registry access
Copiar enlace

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 hostname 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

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: |
1 

    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

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.

  1. To configure an additional CA: 

    $ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
     
    $ oc edit image.config.openshift.io cluster
     
    spec:
  additionalTrustedCA:
    name: registry-config

9.2.6. Configuring image registry repository mirroring
Copiar enlace

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 disconnected environments 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.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. 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 disconnected environment.

  • After OpenShift Container Platform installation:

    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.
Note

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-admin
    role.

Procedure

  1. 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 

      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:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
docker://example.io/example/ubi-minimal

      In this example, you have a container image registry that is named 

      example.io
      with an image repository named 
      example
      to which you want to copy the 
      ubi8/ubi-minimal
      image from 
      registry.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.

  2. Log in to your OpenShift Container Platform cluster.

  3. Create an 

    ImageContentSourcePolicy
    file (for example, 
    registryrepomirror.yaml
    ), replacing the source and mirrors with 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-minimal
    1 
    
    source: registry.access.redhat.com/ubi8/ubi-minimal
    2 
    
  - mirrors:
    - example.com/example/ubi-minimal
    source: registry.access.redhat.com/ubi8/ubi-minimal
  - mirrors:
    - mirror.example.com/redhat
    source: registry.redhat.io/openshift4
    3
    1
    Indicates the name of the image registry and repository.
    2
    Indicates the registry and repository containing the content that is mirrored.
    3
    You can configure a namespace inside a registry to use any image in that namespace. If you use a registry domain as a source, the ImageContentSourcePolicy resource is applied to all repositories from the registry.

  4. Create the new 

    ImageContentSourcePolicy
    object: 

    $ oc create -f registryrepomirror.yaml

    After the 

    ImageContentSourcePolicy
    object is created, the new settings are deployed to each node and the cluster starts using the mirrored repository for requests to the source repository.

  5. To check that the mirrored configuration settings, are applied, do the following on one of the nodes.

    1. List your nodes: 

      $ oc get node

      Example output

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.21.0
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.21.0
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.21.0
ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.21.0
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.21.0
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.21.0

      You can see that scheduling on each worker node is disabled as the change is being applied.

    2. Start the debugging process to access the node: 

      $ oc debug node/ip-10-0-147-35.ec2.internal

      Example output

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

    3. Change your root directory to 

      /host
      : 

      sh-4.2# chroot /host

    4. Check the 

      /etc/containers/registries.conf
      file to make sure the changes were made: 

      sh-4.2# cat /etc/containers/registries.conf

      Example output

      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

    5. Pull an image digest to the node from the source and check if it is resolved by the mirror. 

      ImageContentSourcePolicy
      objects support image digests only, not image tags. 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

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 
    Insecure
    flags are used as fallback.
  • The format of the 
    /etc/containers/registries.conf
    file has changed recently. It is now version 2 and in TOML format.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba