9.2. Configuration des paramètres du registre des images

Vous pouvez configurer les paramètres du registre d'images en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. Lorsque les modifications apportées au registre sont appliquées à la CR image.config.openshift.io/cluster, l'opérateur de configuration de la machine (MCO) effectue les actions séquentielles suivantes :

  1. Cordons du nœud
  2. Applique les modifications en redémarrant CRI-O
  3. Uncordons le nœud

    Note

    Le MCO ne redémarre pas les nœuds lorsqu'il détecte des changements.

Procédure

  1. Modifiez la ressource personnalisée image.config.openshift.io/cluster:

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

    Voici un exemple de 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: Contient des informations à l'échelle du cluster sur la manière de gérer les images. Le nom canonique, et le seul valide, est cluster.
    2
    allowedRegistriesForImport: Limite les registres d'images de conteneurs à partir desquels les utilisateurs normaux peuvent importer des images. Définissez cette liste en fonction des registres dont vous pensez qu'ils contiennent des images valides et à partir desquels vous souhaitez que les applications puissent importer des images. Les utilisateurs autorisés à créer des images ou ImageStreamMappings à partir de l'API ne sont pas concernés par cette politique. En général, seuls les administrateurs de clusters disposent des autorisations appropriées.
    3
    additionalTrustedCA: Une référence à une carte de configuration contenant des autorités de certification (AC) supplémentaires qui sont approuvées lors de l'importation de flux d'images, de l'extraction d'images de pods, de l'extraction de openshift-image-registry et des constructions. L'espace de noms pour cette carte de configuration est openshift-config. Le format de la carte de configuration consiste à utiliser le nom d'hôte du registre comme clé et le certificat PEM comme valeur, pour chaque autorité de certification de registre supplémentaire à laquelle il faut faire confiance.
    4
    registrySources: Contient la configuration qui détermine si le runtime du conteneur autorise ou bloque les registres individuels lors de l'accès aux images pour les builds et les pods. Le paramètre allowedRegistries ou le paramètre blockedRegistries peut être défini, mais pas les deux. Vous pouvez également définir s'il faut ou non autoriser l'accès aux registres non sécurisés ou aux registres qui autorisent les registres utilisant des noms courts d'images. Cet exemple utilise le paramètre allowedRegistries, qui définit les registres dont l'utilisation est autorisée. Le registre non sécurisé insecure.com est également autorisé. Le paramètre registrySources ne contient pas de configuration pour le registre interne du cluster.
    Note

    Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement répertoriés. Si vous utilisez ce paramètre, pour éviter une défaillance du pod, vous devez ajouter les registres registry.redhat.io et quay.io et la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. N'ajoutez pas les registres registry.redhat.io et quay.io à la liste blockedRegistries.

    En utilisant les paramètres allowedRegistries, blockedRegistries ou insecureRegistries, vous pouvez spécifier un référentiel individuel au sein d'un registre. Par exemple : reg1.io/myrepo/myapp:latest.

    Les registres externes non sécurisés doivent être évités afin de réduire les risques éventuels pour la sécurité.

  2. Pour vérifier que les modifications ont été appliquées, dressez la liste de vos nœuds :

    $ oc get nodes

    Exemple de sortie

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

9.2.1. Ajout de registres spécifiques

Vous pouvez ajouter une liste de registres, et éventuellement un référentiel individuel au sein d'un registre, qui sont autorisés pour les actions de traction et de poussée d'image en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre allowedRegistries, le moteur d'exécution du conteneur ne recherche que ces registres. Les registres qui ne figurent pas dans la liste sont bloqués.

Avertissement

Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement listés. Si vous utilisez ce paramètre, pour éviter l'échec d'un pod, ajoutez les registres registry.redhat.io et quay.io et la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. Pour les clusters déconnectés, des registres miroirs doivent également être ajoutés.

Procédure

  1. Modifier le CR image.config.openshift.io/cluster:

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

    Voici un exemple de image.config.openshift.io/cluster CR avec une liste autorisée :

    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
    Contient des configurations qui déterminent comment le runtime du conteneur doit traiter les registres individuels lors de l'accès aux images pour les builds et les pods. Il ne contient pas de configuration pour le registre interne du cluster.
    2
    Spécifier les registres, et éventuellement un dépôt dans ce registre, à utiliser pour les actions d'extraction et de poussée d'images. Tous les autres registres sont bloqués.
    Note

    Le paramètre allowedRegistries ou le paramètre blockedRegistries peut être défini, mais pas les deux.

    L'opérateur de configuration de la machine (MCO) surveille la ressource image.config.openshift.io/cluster pour détecter toute modification des registres. Lorsque le MCO détecte une modification, il vide les nœuds, applique la modification et déconnecte les nœuds. Une fois que les nœuds sont revenus à l'état Ready, la liste des registres autorisés est utilisée pour mettre à jour la stratégie de signature d'image dans le fichier /host/etc/containers/policy.json de chaque nœud.

  2. Pour vérifier que les registres ont été ajoutés au fichier de stratégie, utilisez la commande suivante sur un nœud :

    $ cat /host/etc/containers/policy.json

    La politique suivante indique que seules les images provenant des registres example.com, quay.io et registry.redhat.io sont autorisées pour les extractions et les extractions d'images :

    Exemple 9.1. Exemple de fichier de politique de signature d'image

    {
       "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

Si votre cluster utilise le paramètre registrySources.insecureRegistries, assurez-vous que tous les registres non sécurisés sont inclus dans la liste autorisée.

Par exemple :

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. Blocage de registres spécifiques

Vous pouvez bloquer n'importe quel registre, et éventuellement un référentiel individuel au sein d'un registre, en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre blockedRegistries, le moteur d'exécution du conteneur ne recherche pas ces registres. Tous les autres registres sont autorisés.

Avertissement

Pour éviter un échec du pod, n'ajoutez pas les registres registry.redhat.io et quay.io à la liste blockedRegistries, car ils sont requis par les images de charge utile dans votre environnement.

Procédure

  1. Modifier le CR image.config.openshift.io/cluster:

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

    Voici un exemple de image.config.openshift.io/cluster CR avec une liste de blocage :

    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
    Contient des configurations qui déterminent comment le runtime du conteneur doit traiter les registres individuels lors de l'accès aux images pour les builds et les pods. Il ne contient pas de configuration pour le registre interne du cluster.
    2
    Spécifier les registres, et éventuellement un dépôt dans ce registre, qui ne doivent pas être utilisés pour les actions d'extraction et de poussée d'images. Tous les autres registres sont autorisés.
    Note

    Le registre blockedRegistries ou le registre allowedRegistries peut être défini, mais pas les deux.

    L'opérateur de configuration de la machine (MCO) surveille la ressource image.config.openshift.io/cluster pour détecter toute modification des registres. Lorsque le MCO détecte une modification, il draine les nœuds, applique la modification et désenregistre les nœuds. Une fois que les nœuds sont revenus à l'état Ready, les modifications apportées aux registres bloqués apparaissent dans le fichier /etc/containers/registries.conf de chaque nœud.

  2. Pour vérifier que les registres ont été ajoutés au fichier de stratégie, utilisez la commande suivante sur un nœud :

    $ cat /host/etc/containers/registries.conf

    L'exemple suivant indique que les images du registre untrusted.com ne sont pas autorisées pour les extractions et les extractions d'images :

    Exemple de sortie

    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
    [[registry]]
      prefix = ""
      location = "untrusted.com"
      blocked = true

9.2.2.1. Blocage d'un registre de charges utiles

Dans une configuration de mise en miroir, vous pouvez bloquer les registres de charge utile en amont dans un environnement déconnecté à l'aide d'un objet ImageContentSourcePolicy (ICSP). L'exemple de procédure suivant montre comment bloquer le registre de charge utile quay.io/openshift-payload.

Procédure

  1. Créez la configuration miroir à l'aide d'un objet ImageContentSourcePolicy (ICSP) pour mettre en miroir la charge utile dans un registre de votre instance. L'exemple de fichier ICSP suivant met en miroir la charge utile 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
  2. Une fois l'objet déployé sur vos nœuds, vérifiez que la configuration du miroir est définie en consultant le fichier /etc/containers/registries.conf:

    Exemple de sortie

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

  3. Utilisez la commande suivante pour modifier le fichier de ressources personnalisées image.config.openshift.io:

    $ oc edit image.config.openshift.io cluster
  4. Pour bloquer le registre des charges utiles, ajoutez la configuration suivante au fichier de ressources personnalisées image.config.openshift.io:

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

Vérification

  • Vérifiez que le registre des charges utiles en amont est bloqué en consultant le fichier /etc/containers/registries.conf sur le nœud.

    Exemple de sortie

    [[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. Autoriser les registres non sécurisés

Vous pouvez ajouter des registres non sécurisés, et éventuellement un référentiel individuel au sein d'un registre, en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Les registres qui n'utilisent pas de certificats SSL valides ou qui n'exigent pas de connexions HTTPS sont considérés comme non sécurisés.

Avertissement

Les registres externes non sécurisés doivent être évités afin de réduire les risques éventuels pour la sécurité.

Procédure

  1. Modifier le CR image.config.openshift.io/cluster:

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

    Voici un exemple de image.config.openshift.io/cluster CR avec une liste de registres non sécurisés :

    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
    Contient des configurations qui déterminent comment le runtime du conteneur doit traiter les registres individuels lors de l'accès aux images pour les builds et les pods. Il ne contient pas de configuration pour le registre interne du cluster.
    2
    Spécifiez un registre non sécurisé. Vous pouvez spécifier un référentiel dans ce registre.
    3
    Veiller à ce que les registres non sécurisés soient inclus dans la liste allowedRegistries.
    Note

    Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement listés. Si vous utilisez ce paramètre, pour éviter une défaillance du pod, ajoutez tous les registres, y compris les registres registry.redhat.io et quay.io, ainsi que la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. Pour les clusters déconnectés, les registres miroirs doivent également être ajoutés.

    L'opérateur de configuration de la machine (MCO) surveille le CR image.config.openshift.io/cluster pour détecter toute modification des registres, puis draine et débloque les nœuds lorsqu'il détecte des changements. Une fois que les nœuds sont revenus à l'état Ready, les modifications apportées aux registres non sécurisés et bloqués apparaissent dans le fichier /etc/containers/registries.conf de chaque nœud.

  2. Pour vérifier que les registres ont été ajoutés au fichier de stratégie, utilisez la commande suivante sur un nœud :

    $ cat /host/etc/containers/registries.conf

    L'exemple suivant indique que les images provenant du registre insecure.com ne sont pas sûres et qu'elles sont autorisées pour les extractions et les extractions d'images.

    Exemple de sortie

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

9.2.4. Ajout de registres autorisant les noms courts d'images

Vous pouvez ajouter des registres pour rechercher un nom court d'image en modifiant la ressource personnalisée (CR) image.config.openshift.io/cluster. OpenShift Container Platform applique les modifications de cette CR à tous les nœuds du cluster.

Un nom court d'image vous permet de rechercher des images sans inclure le nom de domaine complet dans la spécification d'extraction. Par exemple, vous pouvez utiliser rhel7/etcd au lieu de registry.access.redhat.com/rhe7/etcd.

Vous pouvez utiliser des noms courts dans des situations où l'utilisation du chemin complet n'est pas pratique. Par exemple, si votre cluster fait référence à plusieurs registres internes dont le DNS change fréquemment, vous devrez mettre à jour les noms de domaine pleinement qualifiés dans vos spécifications d'extraction à chaque changement. Dans ce cas, l'utilisation d'un nom court d'image peut s'avérer utile.

Lors de l'extraction ou de l'importation d'images, le moteur d'exécution du conteneur recherche les registres répertoriés sous le paramètre registrySources dans le CR image.config.openshift.io/cluster. Si vous avez créé une liste de registres sous le paramètre containerRuntimeSearchRegistries, lors de l'extraction d'une image avec un nom court, le moteur d'exécution du conteneur recherche ces registres.

Avertissement

L'utilisation de noms courts d'images avec les registres publics est fortement déconseillée car l'image risque de ne pas être déployée si le registre public exige une authentification. Utilisez des noms d'image pleinement qualifiés avec les registres publics.

Les registres internes ou privés de Red Hat prennent généralement en charge l'utilisation de noms courts d'images.

Si vous répertoriez les registres publics sous le paramètre containerRuntimeSearchRegistries, vous exposez vos informations d'identification à tous les registres de la liste et vous vous exposez à des attaques du réseau et du registre.

Vous ne pouvez pas répertorier plusieurs registres publics sous le paramètre containerRuntimeSearchRegistries si chaque registre public nécessite des informations d'identification différentes et si un cluster ne répertorie pas le registre public dans le secret d'extraction global.

Pour un registre public nécessitant une authentification, vous ne pouvez utiliser un nom court d'image que si les informations d'identification du registre sont stockées dans le secret d'extraction global.

L'opérateur de configuration de la machine (MCO) surveille la ressource image.config.openshift.io/cluster pour détecter toute modification des registres. Lorsque le MCO détecte une modification, il vide les nœuds, applique la modification et désenregistre les nœuds. Après le retour des nœuds à l'état Ready, si le paramètre containerRuntimeSearchRegistries est ajouté, le MCO crée un fichier dans le répertoire /etc/containers/registries.conf.d sur chaque nœud avec les registres répertoriés. Ce fichier remplace la liste par défaut des registres de recherche non qualifiés du fichier /host/etc/containers/registries.conf. Il n'existe aucun moyen de revenir à la liste par défaut des registres de recherche non qualifiés.

Le paramètre containerRuntimeSearchRegistries ne fonctionne qu'avec les moteurs de conteneurs Podman et CRI-O. Les registres de la liste ne peuvent être utilisés que dans les spécifications des pods, pas dans les builds et les flux d'images.

Procédure

  1. Modifiez la ressource personnalisée image.config.openshift.io/cluster:

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

    Voici un exemple de 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
    Indiquer les registres à utiliser avec les noms courts d'images. Il est conseillé d'utiliser les noms courts d'images uniquement avec des registres internes ou privés afin de réduire les risques éventuels pour la sécurité.
    2
    Veiller à ce que tous les registres répertoriés sous containerRuntimeSearchRegistries soient inclus dans la liste allowedRegistries.
    Note

    Lorsque le paramètre allowedRegistries est défini, tous les registres, y compris les registres registry.redhat.io et quay.io et le registre d'image OpenShift par défaut, sont bloqués sauf s'ils sont explicitement listés. Si vous utilisez ce paramètre, pour éviter une défaillance du pod, ajoutez tous les registres, y compris les registres registry.redhat.io et quay.io et la liste internalRegistryHostname à allowedRegistries, car ils sont requis par les images de charge utile dans votre environnement. Pour les clusters déconnectés, les registres miroirs doivent également être ajoutés.

  2. Pour vérifier que les registres ont été ajoutés, lorsqu'un nœud revient à l'état Ready, utilisez la commande suivante sur le nœud :

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

    Exemple de sortie

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

9.2.5. Configuration de magasins de confiance supplémentaires pour l'accès au registre d'images

La ressource personnalisée image.config.openshift.io/cluster peut contenir une référence à une carte de configuration qui contient des autorités de certification supplémentaires à approuver lors de l'accès au registre d'images.

Conditions préalables

  • Les autorités de certification (CA) doivent être codées en PEM.

Procédure

Vous pouvez créer une carte de configuration dans l'espace de noms openshift-config et utiliser son nom dans AdditionalTrustedCA dans la ressource personnalisée image.config.openshift.io pour fournir des autorités de certification supplémentaires qui doivent être approuvées lorsqu'elles contactent des registres externes.

La clé de configuration est le nom d'hôte d'un registre avec le port pour lequel cette autorité de certification doit être approuvée, et le contenu du certificat PEM est la valeur, pour chaque autorité de certification de registre supplémentaire à approuver.

Registre d'images Exemple de carte de configuration de l'autorité de certification

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
Si le registre comporte le port, tel que registry-with-port.example.com:5000, : doit être remplacé par ...

Vous pouvez configurer des autorités de certification supplémentaires en suivant la procédure suivante.

  1. Pour configurer une autorité de certification supplémentaire :

    $ 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. Configuration de la mise en miroir du référentiel du registre d'images

La configuration de la mise en miroir du référentiel du registre des conteneurs vous permet d'effectuer les opérations suivantes :

  • Configurez votre cluster OpenShift Container Platform pour rediriger les demandes d'extraction d'images à partir d'un dépôt sur un registre d'images source et les faire résoudre par un dépôt sur un registre d'images miroir.
  • Identifier plusieurs référentiels miroirs pour chaque référentiel cible, afin de s'assurer que si un miroir est en panne, un autre peut être utilisé.

Les attributs de la mise en miroir de référentiel dans OpenShift Container Platform sont les suivants :

  • Les extractions d'images résistent aux interruptions du registre.
  • Les clusters situés dans des environnements déconnectés peuvent extraire des images de sites critiques, tels que quay.io, et demander aux registres situés derrière le pare-feu de l'entreprise de fournir les images demandées.
  • Un ordre particulier de registres est essayé lorsqu'une demande d'extraction d'image est faite, le registre permanent étant généralement le dernier essayé.
  • Les informations sur le miroir que vous saisissez sont ajoutées au fichier /etc/containers/registries.conf sur chaque nœud du cluster OpenShift Container Platform.
  • Lorsqu'un nœud demande une image à partir du référentiel source, il essaie chaque référentiel miroir à tour de rôle jusqu'à ce qu'il trouve le contenu demandé. Si tous les miroirs échouent, le cluster essaie le référentiel source. En cas de succès, l'image est transférée au nœud.

La configuration de la mise en miroir du référentiel peut se faire de la manière suivante :

  • A l'installation d'OpenShift Container Platform :

    En extrayant les images de conteneurs nécessaires à OpenShift Container Platform, puis en amenant ces images derrière le pare-feu de votre entreprise, vous pouvez installer OpenShift Container Platform dans un centre de données qui se trouve dans un environnement déconnecté.

  • Après l'installation d'OpenShift Container Platform :

    Même si vous ne configurez pas la mise en miroir lors de l'installation d'OpenShift Container Platform, vous pouvez le faire plus tard en utilisant l'objet ImageContentSourcePolicy.

La procédure suivante fournit une configuration miroir post-installation, dans laquelle vous créez un objet ImageContentSourcePolicy qui identifie :

  • La source du référentiel d'images de conteneurs que vous souhaitez mettre en miroir.
  • Une entrée distincte pour chaque référentiel miroir dans lequel vous souhaitez proposer le contenu demandé au référentiel source.
Note

Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Configurer les référentiels miroirs, en utilisant l'un ou l'autre :

    • La configuration d'un référentiel miroir avec Red Hat Quay, comme décrit dans Red Hat Quay Repository Mirroring. L'utilisation de Red Hat Quay vous permet de copier des images d'un référentiel vers un autre et de synchroniser automatiquement ces référentiels de manière répétée au fil du temps.
    • Utilisation d'un outil tel que skopeo pour copier manuellement les images du répertoire source vers le référentiel miroir.

      Par exemple, après avoir installé le paquetage RPM skopeo sur un système Red Hat Enterprise Linux (RHEL) 7 ou RHEL 8, utilisez la commande skopeo comme indiqué dans cet exemple :

      $ skopeo copy \
      docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
      docker://example.io/example/ubi-minimal

      Dans cet exemple, vous avez un registre d'images de conteneurs nommé example.io avec un dépôt d'images nommé example dans lequel vous voulez copier l'image ubi8/ubi-minimal à partir de registry.access.redhat.com. Après avoir créé le registre, vous pouvez configurer votre cluster OpenShift Container Platform pour rediriger les requêtes faites sur le dépôt source vers le dépôt miroir.

  2. Connectez-vous à votre cluster OpenShift Container Platform.
  3. Créez un fichier ImageContentSourcePolicy (par exemple, registryrepomirror.yaml), en remplaçant la source et les miroirs par vos propres paires et images de registres et de référentiels :

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: ubi8repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - example.io/example/ubi-minimal 1
        - example.com/example/ubi-minimal 2
        source: registry.access.redhat.com/ubi8/ubi-minimal 3
      - mirrors:
        - mirror.example.com/redhat
        source: registry.redhat.io/openshift4 4
      - mirrors:
        - mirror.example.com
        source: registry.redhat.io 5
      - mirrors:
        - mirror.example.net/image
        source: registry.example.com/example/myimage 6
      - mirrors:
        - mirror.example.net
        source: registry.example.com/example 7
      - mirrors:
        - mirror.example.net/registry-example-com
        source: registry.example.com 8
    1
    Indique le nom du registre d'images et du référentiel.
    2
    Indique plusieurs référentiels miroirs pour chaque référentiel cible. Si un miroir est hors service, le référentiel cible peut utiliser un autre miroir.
    3
    Indique le registre et le référentiel contenant le contenu qui est mis en miroir.
    4
    Vous pouvez configurer un espace de noms à l'intérieur d'un registre pour utiliser n'importe quelle image dans cet espace de noms. Si vous utilisez un domaine de registre comme source, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels du registre.
    5
    Si vous configurez le nom du registre, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels, du registre source au registre miroir.
    6
    Tire l'image mirror.example.net/image@sha256:…​.
    7
    Extrait l'image myimage dans l'espace de noms du registre source à partir du miroir mirror.example.net/myimage@sha256:…​.
    8
    Extrait l'image registry.example.com/example/myimage du registre miroir mirror.example.net/registry-example-com/example/myimage@sha256:…​. La ressource ImageContentSourcePolicy est appliquée à tous les référentiels d'un registre source à un registre miroir mirror.example.net/registry-example-com.
  4. Créer le nouvel objet ImageContentSourcePolicy:

    $ oc create -f registryrepomirror.yaml

    Une fois l'objet ImageContentSourcePolicy créé, les nouveaux paramètres sont déployés sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

  5. Pour vérifier que les paramètres de configuration en miroir sont appliqués, procédez comme suit sur l'un des nœuds.

    1. Dressez la liste de vos nœuds :

      $ oc get node

      Exemple de sortie

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

      La ressource Imagecontentsourcepolicy ne redémarre pas les nœuds.

    2. Lancez le processus de débogage pour accéder au nœud :

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

      Exemple de sortie

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

    3. Changez votre répertoire racine en /host:

      sh-4.2# chroot /host
    4. Vérifiez le fichier /etc/containers/registries.conf pour vous assurer que les changements ont bien été effectués :

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

      Exemple de sortie

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      short-name-mode = ""
      
      [[registry]]
        prefix = ""
        location = "registry.access.redhat.com/ubi8/ubi-minimal"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "example.io/example/ubi-minimal"
      
        [[registry.mirror]]
          location = "example.com/example/ubi-minimal"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/registry-example-com"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example/myimage"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/image"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io/openshift4"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com/redhat"

    5. Transmet un condensé d'image au nœud à partir de la source et vérifie s'il est résolu par le miroir. Les objets ImageContentSourcePolicy ne prennent en charge que les condensés d'image, et non les balises d'image.

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

Dépannage de la mise en miroir du référentiel

Si la procédure de mise en miroir du référentiel ne fonctionne pas comme décrit, utilisez les informations suivantes sur le fonctionnement de la mise en miroir du référentiel pour résoudre le problème.

  • Le premier miroir de travail est utilisé pour fournir l'image tirée.
  • Le registre principal n'est utilisé que si aucun autre miroir ne fonctionne.
  • Dans le contexte du système, les drapeaux Insecure sont utilisés comme solution de repli.
  • Le format du fichier /etc/containers/registries.conf a récemment changé. Il s'agit désormais de la version 2 et du format TOML.

Ressources complémentaires