Configurer des nœuds pour qu'ils s'authentifient auprès d'un registre privé

Vous pouvez configurer votre cluster Google Distributed Cloud afin que ses nœuds de calcul puissent utiliser des registres privés, y compris Artifact Registry. Les registres privés au niveau des nœuds sont destinés à être utilisés avec vos charges de travail pour vous donner plus de contrôle sur les extractions d'images et la sécurité associée. Lorsque vous configurez un cluster avec les registres privés comme décrit dans ce document, Google Distributed Cloud met à jour la configuration containerd en conséquence. Une fois votre cluster configuré, tous les pods sur les nœuds éligibles peuvent utiliser les registres sans avoir à spécifier imagePullSecrets dans la spécification du pod.

Vous pouvez activer ou désactiver cette fonctionnalité à tout moment au cours du cycle de vie du cluster.

La liste suivante indique la phase de lancement de cette fonctionnalité pour chaque version :

• 1.30 et versions ultérieures : GA
• 1.29: prévisualisation

Prérequis

1.30 et versions ultérieures

Pour utiliser cette fonctionnalité en disponibilité générale, votre cluster doit répondre aux exigences suivantes :

• La version du cluster doit être 1.30 ou ultérieure.
• La version du pool de nœuds doit être 1.29 ou ultérieure (un cluster 1.30 peut avoir des pools de nœuds en version 1.28, mais la fonctionnalité ne fonctionne que pour les pools de nœuds en version 1.29 ou ultérieure).

• Cette fonctionnalité est destinée aux clusters d'utilisateur et aux clusters autogérés (hybrides et autonomes) avec des pools de nœuds de calcul, comme indiqué dans le tableau suivant :

  Modèle de déploiement	Types de cluster compatibles
  Déploiement de clusters d'administrateur et d'utilisateur	Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
  Déploiement de clusters hybrides	Cluster hybride Cluster d'utilisateur 1 Cluster d'utilisateur 2
  Déploiement de clusters autonomes	Cluster autonome

1,29

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour utiliser cette fonctionnalité en preview, votre cluster doit répondre aux exigences suivantes :

• La version du cluster doit être 1.29.
• La version du pool de nœuds doit être 1.29 (tous les pools de nœuds ne doivent pas être en version 1.29, mais la fonctionnalité ne fonctionne que pour les pools de nœuds en version 1.29).
• Le cluster doit comporter l'annotation de fonctionnalité en version bêta preview.baremetal.cluster.gke.io/private-registry: "enable".

• Cette fonctionnalité est destinée aux clusters d'utilisateur et aux clusters autogérés (hybrides et autonomes) avec des pools de nœuds de calcul, comme indiqué dans le tableau suivant :

  Modèle de déploiement	Types de cluster compatibles
  Déploiement de clusters d'administrateur et d'utilisateur	Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
  Déploiement de clusters hybrides	Cluster hybride Cluster d'utilisateur 1 Cluster d'utilisateur 2
  Déploiement de clusters autonomes	Cluster autonome

Configurer un cluster autogéré pour les registres privés

Pour configurer un cluster autonome ou hybride afin qu'il utilise des registres privés au niveau du nœud :

1. Modifiez le fichier de configuration du cluster pour ajouter le bloc privateRegistries dans la section des identifiants :

   ---
   gcrKeyPath: baremetal/gcr.json
   sshPrivateKeyPath: .ssh/id_rsa
   ...
   privateRegistries:
     - host: REGISTRY_HOST
       caCertPath: CA_CERT_PATH
       pullCredentialConfigPath: CREDENTIALS_FILE_PATH
   ...
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-hybrid-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: hybrid-basic
     namespace: cluster-hybrid-basic
     annotations:
       preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only
       ...
   spec:
     type: hybrid
     ...
   

   Remplacez les éléments suivants :

   • REGISTRY_HOST : nom de domaine ou adresse IP du registre privé et du port. Exemple : 10.200.0.2:5007.

   • CA_CERT_PATH : chemin d'accès au fichier de certificat de l'autorité de certification (autorité de certification racine du serveur). Exemple : /root/cert.pem. Si votre registre privé ne nécessite pas de certificat TLS privé, vous pouvez omettre ce champ.

   • CREDENTIALS_FILE_PATH : chemin d'accès au fichier de configuration, config.json (par exemple, $HOME/.docker/config.json). Pour authentifier containerd et lui permettre d'accéder à votre registre privé, config.json doit contenir une version encodée en base64 de vos identifiants dans la section auths du fichier.

     Pour Artifact Registry, authentifiez-vous à l'aide d'une clé JSON de compte de service avec les valeurs suivantes :

     • username : _json_key
     • password : l'intégralité du contenu du fichier de clé JSON du compte de service. Placez le contenu de la clé JSON collée entre guillemets simples (') pour éviter les erreurs d'analyse.

     Pour savoir comment générer ce fichier, consultez Configurer l'authentification pour Docker dans Artifact Registry dans la documentation Artifact Registry.

     Pour les autres registres privés, la chaîne auth encodée en base64 est généralement formée à partir de USERNAME:PASSWORD, à l'aide des identifiants spécifiques de votre registre. Si votre serveur de registre privé ne nécessite pas d'identifiants pour l'authentification, vous pouvez omettre le champ pullCredentialConfigPath.

     Pour protéger les données sensibles, vous pouvez utiliser chown et chmod pour limiter l'accès au fichier de configuration.

2. Appliquez les modifications à votre cluster :

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.

   • CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster autogéré (hybride ou autonome).

Configurer un cluster d'utilisateur pour les registres privés

Avec les clusters d'utilisateur, la configuration du registre privé est spécifiée dans la spécification de ressource du cluster d'utilisateur, qui se trouve dans le cluster d'administrateur. De plus, vous devez stocker les identifiants du registre privé dans un secret, qui se trouve également dans le cluster d'administrateur :

1. Créez un secret Kubernetes de type kubernetes.io/dockerconfigjson pour les identifiants du registre :

   Si vous souhaitez limiter le champ d'application de la ressource Secret à un espace de noms spécifique, ajoutez l'indicateur --namespace à la commande suivante pour spécifier le nom de l'espace de noms. Si la ressource Secret ne se trouve pas dans le même espace de noms que le cluster, ajoutez l'annotation baremetal.cluster.gke.io/mark-source: "true", comme illustré dans l'exemple à la fin de cette étape.

   kubectl create secret docker-registry CREDS_SECRET_NAME \
       --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
       --kubeconfig=ADMIN_KUBECONFIG
   

   Remplacez les éléments suivants :

   • CREDS_SECRET_NAME : nom de votre secret.

   • CREDENTIALS_FILE_PATH : chemin d'accès au fichier de configuration, config.json (par exemple, $HOME/.docker/config.json). Pour authentifier containerd et lui permettre d'accéder à votre registre privé, config.json doit contenir une version encodée en base64 de vos identifiants dans la section auths du fichier.

     Pour Artifact Registry, authentifiez-vous à l'aide d'une clé JSON de compte de service avec les valeurs suivantes :

     • username : _json_key
     • password : l'intégralité du contenu du fichier de clé JSON du compte de service. Placez le contenu de la clé JSON collée entre guillemets simples (') pour éviter les erreurs d'analyse.

     Pour savoir comment générer ce fichier, consultez Configurer l'authentification pour Docker dans Artifact Registry dans la documentation Artifact Registry.

     Pour les autres registres privés, la chaîne auth encodée en base64 est généralement formée à partir de USERNAME:PASSWORD, à l'aide des identifiants spécifiques de votre registre. Si votre serveur de registre privé ne nécessite pas d'identifiants pour l'authentification, vous pouvez omettre le champ pullCredentialSecretRef.

     Pour protéger les données sensibles, vous pouvez utiliser chown et chmod pour limiter l'accès au fichier de configuration.

   Votre secret doit ressembler à l'exemple suivant :

   apiVersion: v1
   data:
     .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ==
   kind: Secret
   metadata:
     creationTimestamp: "2024-04-28T22:06:06Z"
     name: private-registry-secret
     namespace: default
     resourceVersion: "5055821"
     ...
     annotations:
       ...
       baremetal.cluster.gke.io/mark-source: "true"
   type: kubernetes.io/dockerconfigjson
   

2. Le cas échéant, stockez le certificat de l'autorité de certification pour le registre dans un secret.

   Le secret ressemble à ceci :

   apiVersion: v1
   kind: Secret
   metadata:
     annotations:
       baremetal.cluster.gke.io/mark-source: "true"
     name: ca-9dd74fd308bac6df562c7a7b220590b5
     namespace: some-namespace
   type: Opaque
   data:
     ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi
     3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ
     ...
     QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU
     LUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
     ```
   

3. Modifiez le fichier de configuration du cluster d'utilisateur pour activer et configurer le registre privé :

   1. Pour les clusters de la version 1.29 uniquement, ajoutez l'annotation de fonctionnalité Preview preview.baremetal.cluster.gke.io/private-registry: "enable" pour activer la fonctionnalité. Pour les clusters de la version 1.30 et version ultérieures, la fonctionnalité d'enregistrement privé est activée par défaut.

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
        namespace: cluster-user-basic
        resourceVersion: "766027"
        annotations:
          ...
          preview.baremetal.cluster.gke.io/private-registry: "enable"
      ...
      

   2. Dans la section nodeConfig du fichier de configuration du cluster d'utilisateur, ajoutez le bloc privateRegistries :

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
      ...
      spec:
        bypassPreflightCheck: false
      ...
        nodeConfig:
          containerRuntime: containerd
          podDensity:
            maxPodsPerNode: 250
          privateRegistries:
          - caCertSecretRef:
              name: CA_CERT_SECRET_NAME
              namespace: CA_CERT_SECRET_NAMESPACE
            host: REGISTRY_HOST
            pullCredentialSecretRef:
              name: CREDS_SECRET_NAME
              namespace: CREDS_SECRET_NAMESPACE
      

   Remplacez les éléments suivants :

   • CA_CERT_SECRET_NAME : nom du secret que vous avez créé pour stocker le certificat de l'autorité de certification. Si vous n'avez pas créé ce secret, supprimez le bloc caCertSecretRef.

   • CA_CERT_SECRET_NAMESPACE : nom de l'espace de noms pour le secret du certificat d'autorité de certification, si vous l'avez créé.

   • REGISTRY_HOST : nom de domaine ou adresse IP du registre privé et port. Exemple : 10.200.0.2:5007.

   • CREDS_SECRET_NAME : nom du secret de type kubernetes.io/dockerconfigjson pour les identifiants du registre.

   • CREDS_SECRET_NAMESPACE : nom de l'espace de noms du secret pour les identifiants du registre.

4. Appliquez les modifications à votre cluster :

   bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Remplacez les éléments suivants :

   • USER_CLUSTER_NAME : nom du cluster que vous mettez à jour.

   • ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.