Startseite
Produkte
OpenShift Container Platform
4.14
Images
Chapter 9. Image configuration resources

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 9. Image configuration resources

Use the following procedure to configure image registries.

9.1. Image controller configuration parameters
Link kopieren

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

Parameter Description

Parameter	Description
`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. If 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. To specify all subdomains, add the asterisk ( `` ) wildcard character as a prefix to the domain name. For example, `.example.com` . 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. To specify all subdomains, add the asterisk ( `` ) wildcard character as a prefix to the domain name. For example, `.example.com` . 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. To specify all subdomains, add the asterisk ( `` ) wildcard character as a prefix to the domain name. For example, `.example.com` . 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.

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. If the registry uses a non-standard

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. To specify all subdomains, add the asterisk (

) wildcard character as a prefix to the domain name. For example,

*.example.com

. 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. To specify all subdomains, add the asterisk (

) wildcard character as a prefix to the domain name. For example,

*.example.com

. 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. To specify all subdomains, add the asterisk (

) wildcard character as a prefix to the domain name. For example,

*.example.com

. 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

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

Parameter Description

Parameter	Description
`internalRegistryHostname`	Set by the Image Registry Operator, which controls the `internalRegistryHostname` . It sets the hostname for the default OpenShift 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.

internalRegistryHostname

Set by the Image Registry Operator, which controls the

internalRegistryHostname

. It sets the hostname for the default OpenShift 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
Link kopieren

You can configure image registry settings by editing the

image.config.openshift.io/cluster

custom resource (CR). When changes to the registry are applied to the

image.config.openshift.io/cluster

CR, the Machine Config Operator (MCO) performs the following sequential actions:

Cordons the node
Applies changes by restarting CRI-O
Uncordons the node
Note
The MCO does not restart 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
```
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 parameter 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 OpenShift 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.

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

$ oc get nodes

Example output

NAME                                         STATUS                     ROLES                  AGE   VERSION
ip-10-0-137-182.us-east-2.compute.internal   Ready,SchedulingDisabled   worker                 65m   v1.27.3
ip-10-0-139-120.us-east-2.compute.internal   Ready,SchedulingDisabled   control-plane          74m   v1.27.3
ip-10-0-176-102.us-east-2.compute.internal   Ready                      control-plane          75m   v1.27.3
ip-10-0-188-96.us-east-2.compute.internal    Ready                      worker                 65m   v1.27.3
ip-10-0-200-59.us-east-2.compute.internal    Ready                      worker                 63m   v1.27.3
ip-10-0-223-123.us-east-2.compute.internal   Ready                      control-plane          73m   v1.27.3

9.2.1. Adding specific registries
Link kopieren

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

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


    allowedRegistries:


    - 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 triggers a rollout on nodes in machine config pool (MCP). The allowed registries list is used to update the image signature policy in the

/etc/containers/policy.json

file on each node. Changes to the

/etc/containers/policy.json

file do not require the node to drain.

Verification

Enter the following command to obtain a list of your nodes:

$ oc get nodes

Example output

NAME               STATUS   ROLES                  AGE   VERSION
<node_name>        Ready    control-plane,master   37m   v1.27.8+4fab27b

Run the following command to enter debug mode on the node:
```
$ oc debug node/<node_name>
```
When prompted, enter
```
chroot /host
```
into the terminal:
```
sh-4.4# chroot /host
```

Enter the following command to check that the registries have been added to the policy file:

sh-5.1# cat /etc/containers/policy.json | jq '.'

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
Link kopieren

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

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 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. During this period, you might experience service unavailability.

Verification

Enter the following command to obtain a list of your nodes:

$ oc get nodes

Example output

NAME                STATUS   ROLES                  AGE   VERSION
<node_name>         Ready    control-plane,master   37m   v1.27.8+4fab27b

Run the following command to enter debug mode on the node:
```
$ oc debug node/<node_name>
```
When prompted, enter
```
chroot /host
```
into the terminal:
```
sh-4.4# chroot /host
```
Enter the following command to check that the registries have been added to the policy file:
```
sh-5.1# cat 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.2.1. Blocking a payload registry
Link kopieren

In a mirroring configuration, you can block upstream payload registries in a disconnected environment using a

ImageContentSourcePolicy

(ICSP) object. The following example procedure demonstrates how to block the

quay.io/openshift-payload

payload registry.

Procedure

Create the mirror configuration using an

ImageContentSourcePolicy

(ICSP) object to mirror the payload to a registry in your instance. The following example ICSP file mirrors the payload

internal-mirror.io/openshift-payload

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: my-icsp
spec:
  repositoryDigestMirrors:
  - mirrors:
    - internal-mirror.io/openshift-payload
    source: quay.io/openshift-payload

After the object deploys onto your nodes, verify that the mirror configuration is set by checking the

/etc/containers/registries.conf

file:

Example output

[[registry]]
  prefix = ""
  location = "quay.io/openshift-payload"
  mirror-by-digest-only = true

[[registry.mirror]]
  location = "internal-mirror.io/openshift-payload"

Use the following command to edit the

image.config.openshift.io

custom resource file:

$ oc edit image.config.openshift.io cluster

To block the payload registry, add the following configuration to the

image.config.openshift.io

custom resource file:

spec:
  registrySources:
    blockedRegistries:
     - quay.io/openshift-payload

Verification

Verify that the upstream payload registry is blocked by checking the

/etc/containers/registries.conf

file on the node.

Example output

[[registry]]
  prefix = ""
  location = "quay.io/openshift-payload"
  blocked = true
  mirror-by-digest-only = true

[[registry.mirror]]
  location = "internal-mirror.io/openshift-payload"

9.2.3. Allowing insecure registries
Link kopieren

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

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

Verification

To check that the registries have been added to the policy file, use the following command on a node:
```
$ cat /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
Link kopieren

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 because the image might not deploy if the public registry requires authentication. Use fully-qualified image names with public registries.

Red Hat internal or private registries typically support the use of image short names.

If you list public registries under the

containerRuntimeSearchRegistries

parameter (including the

registry.redhat.io

docker.io

, and

quay.io

registries), you expose your credentials to all the registries on the list, and you risk network and registry attacks. Because you can only have one pull secret for pulling images, as defined by the global pull secret, that secret is used to authenticate against every registry in that list. Therefore, if you include public registries in the list, you introduce a security risk.

You cannot list multiple public registries under the

containerRuntimeSearchRegistries

parameter if each public registry requires different credentials and a cluster does not list the public registry in the global pull secret.

For a public registry that requires authentication, you can use an image short name only if the registry has its credentials stored in the global pull secret.

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. During this period, you might experience service unavailability. 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

/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

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:


    - reg1.io
    - reg2.io
    - reg3.io
    allowedRegistries:


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

Verification

Enter the following command to obtain a list of your nodes:

$ oc get nodes

Example output

NAME                STATUS   ROLES                  AGE   VERSION
<node_name>         Ready    control-plane,master   37m   v1.27.8+4fab27b

Run the following command to enter debug mode on the node:
```
$ oc debug node/<node_name>
```
When prompted, enter
```
chroot /host
```
into the terminal:
```
sh-4.4# chroot /host
```

Enter the following command to check that the registries have been added to the policy file:

sh-5.1# cat /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
Link kopieren

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 PEM certificate content 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: |


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

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.3. Understanding image registry repository mirroring
Link kopieren

Setting up container registry repository mirroring enables you to perform the following tasks:

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.

Repository mirroring in OpenShift Container Platform includes the following attributes:

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:
If you did not configure mirroring during OpenShift Container Platform installation, you can do so postinstallation by using any of the following custom resource (CR) objects:
- ImageDigestMirrorSet
  (IDMS). This object allows you to pull images from a mirrored registry by using digest specifications. The IDMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails.
- ImageTagMirrorSet
  (ITMS). This object allows you to pull images from a mirrored registry by using image tags. The ITMS CR enables you to set a fall back policy that allows or stops continued attempts to pull from the source registry if the image pull fails.
- ImageContentSourcePolicy
  (ICSP). This object allows you to pull images from a mirrored registry by using digest specifications. An ICSP always falls back to the source registry if the mirrors do not work.
Important
Using an
ImageContentSourcePolicy
(ICSP) object to configure repository mirroring is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. If you have existing YAML files that you used to create
ImageContentSourcePolicy
objects, you can use the
oc adm migrate icsp
command to convert those files to an
ImageDigestMirrorSet
YAML file. For more information, see "Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring" in the following section.

Each of these custom resource objects identify the following information:

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 the following actions and how they affect node drain behavior:

If you create an IDMS or ICSP CR object, the MCO does not drain or reboot the node.
If you create an ITMS CR object, the MCO drains and reboots the node.
If you delete an ITMS, IDMS, or ICSP CR object, the MCO drains and reboots the node.
If you modify an ITMS, IDMS, or ICSP CR object, the MCO drains and reboots the node.
Important
- When the MCO detects any of the following changes, it applies the update without draining or rebooting the node:
  Changes to the SSH key in the
  
  spec.config.passwd.users.sshAuthorizedKeys
  
  parameter of a machine config.
  Changes to the global pull secret or pull secret in the
  
  openshift-config
  
  namespace.
  Automatic rotation of the
  
  /etc/kubernetes/kubelet-ca.crt
  
  certificate authority (CA) by the Kubernetes API Server Operator.
- When the MCO detects changes to the
  
  /etc/containers/registries.conf
  
  file, such as editing an
  
  ImageDigestMirrorSet
  
  ,
  
  ImageTagMirrorSet
  
  , or
  
  ImageContentSourcePolicy
  
  object, it drains the corresponding nodes, applies the changes, and uncordons the nodes. The node drain does not happen for the following changes:
  The addition of a registry with the
  
  pull-from-mirror = "digest-only"
  
  parameter set for each mirror.
  The addition of a mirror with the
  
  pull-from-mirror = "digest-only"
  
  parameter set in a registry.
  The addition of items to the
  
  unqualified-search-registries
  
  list.

For new clusters, you can use IDMS, ITMS, and ICSP CRs objects as desired. However, using IDMS and ITMS is recommended.

If you upgraded a cluster, any existing ICSP objects remain stable, and both IDMS and ICSP objects are supported. Workloads using ICSP objects continue to function as expected. However, if you want to take advantage of the fallback policies introduced in the IDMS CRs, you can migrate current workloads to IDMS objects by using the

oc adm migrate icsp

command as shown in the Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring section that follows. Migrating to IDMS objects does not require a cluster reboot.

Note

If your cluster uses an

ImageDigestMirrorSet

ImageTagMirrorSet

, or

ImageContentSourcePolicy

object to configure repository mirroring, you can use only global pull secrets for mirrored registries. You cannot add a pull secret to a project.

9.3.1. Configuring image registry repository mirroring
Link kopieren

You can create postinstallation mirror configuration custom resources (CR) to redirect image pull requests from a source image registry to a mirrored image registry.

Prerequisites

Access to the cluster as a user with the
```
cluster-admin
```
role.

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
  skopeo
  to copy images manually from the source repository 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/ubi9/ubi-minimal:latest@sha256:5cf... \ 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
  ubi9/ubi-minimal
  image from
  registry.access.redhat.com
  . After you create the mirrored 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 a postinstallation mirror configuration CR, by using one of the following examples:
- Create an
  ImageDigestMirrorSet
  or
  ImageTagMirrorSet
  CR, as needed, replacing the source and mirrors with your own registry and repository pairs and images:
  apiVersion: config.openshift.io/v1
  1
  kind: ImageDigestMirrorSet
  2
  metadata: name: ubi9repo spec: imageDigestMirrors:
  3
  - mirrors: - example.io/example/ubi-minimal
  4
  - example.com/example/ubi-minimal
  5
  source: registry.access.redhat.com/ubi9/ubi-minimal
  6
  mirrorSourcePolicy: AllowContactingSource
  7
  - mirrors: - mirror.example.com/redhat source: registry.redhat.io/openshift4
  8
  mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.com source: registry.redhat.io
  9
  mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/image source: registry.example.com/example/myimage
  10
  mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net source: registry.example.com/example
  11
  mirrorSourcePolicy: AllowContactingSource - mirrors: - mirror.example.net/registry-example-com source: registry.example.com
  12
  mirrorSourcePolicy: AllowContactingSource
  1
  Indicates the API to use with this CR. This must be config.openshift.io/v1.
  2
  Indicates the kind of object according to the pull type:
  
  ImageDigestMirrorSet
  
  : Pulls a digest reference image.
  
  ImageTagMirrorSet
  
  : Pulls a tag reference image.
  3
  Indicates the type of image pull method, either:
  
  imageDigestMirrors
  
  : Use for an
  
  ImageDigestMirrorSet
  
  CR.
  
  imageTagMirrors
  
  : Use for an
  
  ImageTagMirrorSet
  
  CR.
  4
  Indicates the name of the mirrored image registry and repository.
  5
  Optional: Indicates a secondary mirror repository for each target repository. If one mirror is down, the target repository can use another mirror.
  6
  Indicates the registry and repository source, which is the repository that is referred to in image pull specifications.
  7
  Optional: Indicates the fallback policy if the image pull fails:
  
  AllowContactingSource
  
  : Allows continued attempts to pull the image from the source repository. This is the default.
  
  NeverContactSource
  
  : Prevents continued attempts to pull the image from the source repository.
  8
  Optional: Indicates a namespace inside a registry, which allows you to use any image in that namespace. If you use a registry domain as a source, the object is applied to all repositories from the registry.
  9
  Optional: Indicates a registry, which allows you to use any image in that registry. If you specify a registry name, the object is applied to all repositories from a source registry to a mirror registry.
  10
  Pulls the image registry.example.com/example/myimage@sha256:… from the mirror mirror.example.net/image@sha256:...
  11
  Pulls the image registry.example.com/example/image@sha256:… in the source registry namespace from the mirror mirror.example.net/image@sha256:….
  12
  Pulls the image registry.example.com/myimage@sha256 from the mirror registry example.net/registry-example-com/myimage@sha256:….
- Create an
  ImageContentSourcePolicy
  custom resource, replacing the source and mirrors with your own registry and repository pairs and images:
  apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: mirror-ocp spec: repositoryDigestMirrors: - mirrors: - mirror.registry.com:443/ocp/release
  1
  source: quay.io/openshift-release-dev/ocp-release
  2
  - mirrors: - mirror.registry.com:443/ocp/release source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
  1
  Specifies the name of the mirror image registry and repository.
  2
  Specifies the online registry and repository containing the content that is mirrored.
Create the new object:
```
$ oc create -f registryrepomirror.yaml
```
After the object is created, the Machine Config Operator (MCO) drains the nodes for
```
ImageTagMirrorSet
```
objects only. The MCO does not drain the nodes for
```
ImageDigestMirrorSet
```
and
```
ImageContentSourcePolicy
```
objects.

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

List your nodes:

$ oc get node

Example output

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

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`

Change your root directory to
```
/host
```
:
```
sh-4.2# chroot /host
```

Check the

/etc/containers/registries.conf

file to make sure the changes were made:

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

The following output represents a

registries.conf

file where postinstallation mirror configuration CRs were applied. The final two entries are marked

digest-only

and

tag-only

respectively.

Example output

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

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"



  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"


    pull-from-mirror = "digest-only"



  [[registry.mirror]]
    location = "example.com/example/ubi-minimal"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com"

  [[registry.mirror]]
    location = "mirror.example.net/registry-example-com"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/example"

  [[registry.mirror]]
    location = "mirror.example.net"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.example.com/example/myimage"

  [[registry.mirror]]
    location = "mirror.example.net/image"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.redhat.io"

  [[registry.mirror]]
    location = "mirror.example.com"
    pull-from-mirror = "digest-only"

[[registry]]
  prefix = ""
  location = "registry.redhat.io/openshift4"

  [[registry.mirror]]
    location = "mirror.example.com/redhat"
    pull-from-mirror = "digest-only"
[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi9/ubi-minimal"
  blocked = true



  [[registry.mirror]]
    location = "example.io/example/ubi-minimal-tag"
    pull-from-mirror = "tag-only"

1: Indicates the repository that is referred to in a pull spec.
2: Indicates the mirror for that repository.
3: Indicates that the image pull from the mirror is a digest reference image.
4: Indicates that the NeverContactSource parameter is set for this repository.
5: Indicates that the image pull from the mirror is a tag reference image.

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

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

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.

9.3.2. Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring
Link kopieren

Using an

ImageContentSourcePolicy

(ICSP) object to configure repository mirroring is a deprecated feature. This functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.

ICSP objects are being replaced by

ImageDigestMirrorSet

and

ImageTagMirrorSet

objects to configure repository mirroring. If you have existing YAML files that you used to create

ImageContentSourcePolicy

objects, you can use the

oc adm migrate icsp

command to convert those files to an

ImageDigestMirrorSet

YAML file. The command updates the API to the current version, changes the

kind

value to

ImageDigestMirrorSet

, and changes

spec.repositoryDigestMirrors

spec.imageDigestMirrors

. The rest of the file is not changed.

Because the migration does not change the

registries.conf

file, the cluster does not need to reboot.

For more information about

ImageDigestMirrorSet

ImageTagMirrorSet

objects, see "Configuring image registry repository mirroring" in the previous section.

Prerequisites

Access to the cluster as a user with the
```
cluster-admin
```
role.
Ensure that you have
```
ImageContentSourcePolicy
```
objects on your cluster.

Procedure

Use the following command to convert one or more

ImageContentSourcePolicy

YAML files to an

ImageDigestMirrorSet

YAML file:

$ oc adm migrate icsp <file_name>.yaml <file_name>.yaml <file_name>.yaml --dest-dir <path_to_the_directory>

where:

<file_name>: Specifies the name of the source ImageContentSourcePolicy YAML. You can list multiple file names.
--dest-dir: Optional: Specifies a directory for the output ImageDigestMirrorSet YAML. If unset, the file is written to the current directory.

For example, the following command converts the

icsp.yaml

and

icsp-2.yaml

file and saves the new YAML files to the

idms-files

directory.

$ oc adm migrate icsp icsp.yaml icsp-2.yaml --dest-dir idms-files

Example output

wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi8repo.5911620242173376087.yaml
wrote ImageDigestMirrorSet to idms-files/imagedigestmirrorset_ubi9repo.6456931852378115011.yaml

Create the CR object by running the following command:
```
$ oc create -f <path_to_the_directory>/<file-name>.yaml
```
where:
<path_to_the_directory>
Specifies the path to the directory, if you used the --dest-dir flag.
<file_name>
Specifies the name of the ImageDigestMirrorSet YAML.
Remove the ICSP objects after the IDMS objects are rolled out.

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 9. Image configuration resources

9.1. Image controller configuration parameters
Link kopieren

9.2. Configuring image registry settings
Link kopieren

9.2.1. Adding specific registries
Link kopieren

9.2.2. Blocking specific registries
Link kopieren

9.2.2.1. Blocking a payload registry
Link kopieren

9.2.3. Allowing insecure registries
Link kopieren

9.2.4. Adding registries that allow image short names
Link kopieren

9.2.5. Configuring additional trust stores for image registry access
Link kopieren

9.3. Understanding image registry repository mirroring
Link kopieren

9.3.1. Configuring image registry repository mirroring
Link kopieren

9.3.2. Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring
Link kopieren

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 9. Image configuration resources

9.1. Image controller configuration parametersLink kopierenLink in die Zwischenablage kopiert!

9.2. Configuring image registry settingsLink kopierenLink in die Zwischenablage kopiert!

9.2.1. Adding specific registriesLink kopierenLink in die Zwischenablage kopiert!

9.2.2. Blocking specific registriesLink kopierenLink in die Zwischenablage kopiert!

9.2.2.1. Blocking a payload registryLink kopierenLink in die Zwischenablage kopiert!

9.2.3. Allowing insecure registriesLink kopierenLink in die Zwischenablage kopiert!

9.2.4. Adding registries that allow image short namesLink kopierenLink in die Zwischenablage kopiert!

9.2.5. Configuring additional trust stores for image registry accessLink kopierenLink in die Zwischenablage kopiert!

9.3. Understanding image registry repository mirroringLink kopierenLink in die Zwischenablage kopiert!

9.3.1. Configuring image registry repository mirroringLink kopierenLink in die Zwischenablage kopiert!

9.3.2. Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroringLink kopierenLink in die Zwischenablage kopiert!

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

9.1. Image controller configuration parameters
Link kopieren

9.2. Configuring image registry settings
Link kopieren

9.2.1. Adding specific registries
Link kopieren

9.2.2. Blocking specific registries
Link kopieren

9.2.2.1. Blocking a payload registry
Link kopieren

9.2.3. Allowing insecure registries
Link kopieren

9.2.4. Adding registries that allow image short names
Link kopieren

9.2.5. Configuring additional trust stores for image registry access
Link kopieren

9.3. Understanding image registry repository mirroring
Link kopieren

9.3.1. Configuring image registry repository mirroring
Link kopieren

9.3.2. Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring
Link kopieren