Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Chapter 7. Image configuration resources

Use the following procedure to configure image registries.

7.1. Image controller configuration parameters
Copiar o link

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.

Expand
ParameterDescription

allowedRegistriesForImport

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 will have the appropriate permissions.

Every element of this list contains a location of the registry specified by the registry domain name. The domain name can include wildcards.

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

additionalTrustedCA: A reference to a ConfigMap containing additional CAs that should be trusted during ImageStream import, pod image pull, openshift-image-registry pullthrough, and builds.

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

registrySources

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.

externalRegistryHostnames

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 ImageStreams. The value must be in hostname[:port] format.

registrySources

Holds cluster-wide information about how to handle the registries config.

insecureRegistries: Registries which do not have a valid TLS certificate or only support HTTP connections.

blockedRegistries: Blacklisted for image pull and push actions. All other registries are allowed.

allowedRegistries: Whitelisted for image pull and push actions. All other registries are blocked.

Only one of blockedRegistries or allowedRegistries may be set

Warning

When the allowedRegistries parameter is defined, all registries including registry.redhat.io and quay.io are blocked unless explicitly listed. If using the parameter, declare source registries registry.redhat.io and quay.io as required by payload images within your environment, to prevent Pod failure. For disconnected clusters, mirror registries should also be added.

The status field of the image.config.openshift.io/cluster resource holds observed values from the cluster.

Expand
ParameterDescription

internalRegistryHostname

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

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 ImageStreams. The values must be in hostname[:port] format.

7.2. Configuring image settings
Copiar o link

You can configure image registry settings by editing the image.config.openshift.io/cluster resource. The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster for any changes to registries and reboots the nodes when it detects changes.

Procedure

  1. Edit the image.config.openshift.io/cluster custom resource: 

    $ oc edit image.config.openshift.io/cluster
    Copy to Clipboard Toggle word wrap

    The following is an example image.config.openshift.io/cluster resource: 

    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 
    
    insecureRegistries:
    5 
    
    - insecure.com
    blockedRegistries:
    6 
    
    - untrusted.com
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap
    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 will have the appropriate permissions.
    3
    additionalTrustedCA: A reference to a ConfigMap containing additional CAs that should be trusted during ImageStream import, pod image pull, openshift-image-registry pullthrough, and builds. The namespace for this ConfigMap is openshift-config. The format of the ConfigMap is to use the registry hostname as the key, and the PEM certificate as the value, for each additional registry CA to trust.
    4
    registrySources: Contains configuration that determines how the container runtime should treat individual registries when accessing images for builds and pods. For instance, whether or not to allow insecure access. It does not contain configuration for the internal cluster registry.
    5
    insecureRegistries: Registries which do not have a valid TLS certificate or only support HTTP connections.
    6
    blockedRegistries: Blacklisted for image pull and push actions. All other registries are allowed.

7.2.1. Configuring additional trust stores for image registry access
Copiar o link

The image.config.openshift.io/cluster resource can contain a reference to a ConfigMap that contains additional certificate authorities to be trusted during image registry access.

Prerequisites

  • The CAs must be PEM-encoded.

Procedure

You can create a ConfigMap in the openshift-config namespace and use its name in AdditionalTrustedCA in the image.config.openshift.io resource to provide additional CAs that should be trusted when contacting external registries.

The ConfigMap key is the host name of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate is the value, for each additional registry CA to trust.

Image registry CA ConfigMap 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-----
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

7.2.2. Importing insecure registries and blocking registries
Copiar o link

You can add insecure registries or block any registry by editing the image.config.openshift.io/cluster custom resource (CR). OpenShift Container Platform applies the changes to this CR to all nodes in the cluster.

Insecure external registries, such as those do not have a valid TLS certificate or only support HTTP connections, should be avoided.

Procedure

  1. Edit the image.config.openshift.io/cluster custom resource: 

    $ oc edit image.config.openshift.io/cluster
    Copy to Clipboard Toggle word wrap

    The following is an example image.config.openshift.io/cluster resource: 

    apiVersion: config.openshift.io/v1
kind: Image
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: "2019-05-17T13:44:26Z"
  generation: 1
  name: cluster
  resourceVersion: "8302"
  selfLink: /apis/config.openshift.io/v1/images/cluster
  uid: e34555da-78a9-11e9-b92b-06d6c7da38dc
spec:
  allowedRegistriesForImport:
    - domainName: quay.io
      insecure: false
  additionalTrustedCA:
    name: myconfigmap
  registrySources:
    insecureRegistries:
    1 
    
    - insecure.com
    blockedRegistries:
    2 
    
    - untrusted.com
    allowedRegistries:
    - quay.io
    3 
    
status:
  internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard Toggle word wrap
    1
    Specify an insecure registry.
    2
    Specify registries that should be blacklisted for image pull and push actions. All other registries are allowed. Either blockedRegistries or allowedRegistries can be set, but not both.
    3
    Specify registries that should be permitted for image pull and push actions. All other registries are denied. Either blockedRegistries or allowedRegistries can be set, but not both.

    The Machine Config Operator (MCO) watches the image.config.openshift.io/cluster for any changes to registries and reboots the nodes when it detects changes. Changes to the registries appear in the /host/etc/containers/registries.conf file on each node. 

    cat /host/etc/containers/registries.conf
[registries]
  [registries.search]
    registries = ["registry.access.redhat.com", "docker.io"]
  [registries.insecure]
    registries = ["insecure.com"]
  [registries.block]
    registries = ["untrusted.com"]
    Copy to Clipboard Toggle word wrap

7.2.3. Configuring image registry repository mirroring
Copiar o link

Setting up container registry repository mirroring lets you:

  • Configure your OpenShift Container Platform cluster to redirect requests to pull images from a repository on a source image registry and have it resolved by a repository on a mirrored image registry.
  • Identify multiple mirrored repositories for each target repository, to make sure that if one mirror is down, another can be used.

Here are some of the attributes of repository mirroring in OpenShift Container Platform:

  • Image pulls are resilient to registry downtimes
  • Clusters in restricted networks can request to pull images from critical locations (such as quay.io) and have registries behind a company firewall provide the requested images.
  • A particular order of registries is tried when an image pull request is made, with the permanent registry typically being the last one tried.
  • The mirror information you enter is added to the /etc/containers/registries.conf file on every node in the OpenShift Container Platform cluster.
  • When a node makes a request for an image from the source repository, it tries each mirrored repository in turn until it finds the requested content. If all mirrors fail, the cluster tries the source repository. Upon success, the image is pulled to the node.

Setting up repository mirroring can be done in the following ways:

  • At OpenShift Container Platform installation time: By pulling container images needed by OpenShift Container Platform and then bringing those images behind your company’s firewall, you can install OpenShift Container Platform into a datacenter that is in a restricted network. See Mirroring the OpenShift Container Platform image repository for details.
  • After OpenShift Container Platform installation time: Even if you don’t configure mirroring during OpenShift Container Platform installation, you can do so later using the ImageContentSourcePolicy object.

The following procedure provides a post-installation mirror configuration, where you create an ImageContentSourcePolicy object that identifies:

  • The source of the container image repository you want to mirror
  • A separate entry for each mirror repository you want to offer the content requested from the source repository.

Prerequisites

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

Procedure

  1. Configure mirrored repositories. To do that, you can either:

    • Set up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.

    • Use a tool such as skopeo to copy images manually from the source directory to the mirrored repository.

      For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL 7 or RHEL 8) system, use the skopeo command as shown in this example: 

      $ skopeo copy \
   docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
   docker://example.io/ubi8/ubi-minimal
      Copy to Clipboard Toggle word wrap

      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 those of your own registry and repository pairs and images: 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: ubi8repo
spec:
  repositoryDigestMirrors:
  - mirrors:
    - example.io/example/ubi-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
    Copy to Clipboard Toggle word wrap
    1
    Indicates the name of the image registry and repository
    2
    Indicates the registry and repository containing the content that is mirrored

  4. Create the new ImageContentSourcePolicy: 

    $ oc create -f registryrepomirror.yaml
    Copy to Clipboard Toggle word wrap

    After the ImageContentSourcePolicy is created, the new settings are deployed to each node and shortly start using the mirrored repository for requests to the source repository.

  5. To check that the mirrored configuration worked, go to one of your nodes. For example:

    1. List your nodes: 

      $ oc get node
      Copy to Clipboard Toggle word wrap

      Example output

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

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

    2. Start the debugging process: 

      $ oc debug node/ip-10-0-147-35.ec2.internal
      Copy to Clipboard Toggle word wrap

      Example output

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`
      Copy to Clipboard Toggle word wrap

    3. Access the node’s files: 

      sh-4.2# chroot /host
      Copy to Clipboard Toggle word wrap

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

      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
      Copy to Clipboard Toggle word wrap

    5. Pull an image digest to the node from the source and check if it is actually resolved by the mirror. The ImageContentSourcePolicy supports image digests only, not image tags. 

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

Troubleshooting repository mirroring

If the repository mirroring procedure does not work as described, use the following information about how repository mirroring works to help troubleshoot the problem.

  • The first working mirror is used to supply the pulled image.
  • The main registry will only be used if no other mirror works.
  • From the system context, the Insecure flags are used as fallback.
  • The format of the /etc/containers/registries file has changed recently. It is now version 2 and in TOML format.
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat