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

Vous pouvez configurer votre cluster Google Distributed Cloud pour que ses nœuds de travail puissent utiliser des registres privés. Les registres privés au niveau du nœud 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 qualifiés peuvent utiliser les registres sans avoir à spécifier imagePullSecrets dans les spécifications du pod.

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

La liste suivante indique l'état de lancement de cette fonctionnalité par version:

Prérequis

1.30 et versions ultérieures

Pour utiliser cette fonctionnalité GA, 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 la version 1.29 ou ultérieure (un cluster 1.30 peut avoir des pools de nœuds en version 1.28, mais cette 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'utilisateurs 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

Pour utiliser cette fonctionnalité Preview (Aperçu), votre cluster doit remplir les conditions suivantes:

  • La version du cluster doit être 1.29.
  • La version du pool de nœuds doit être la version 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é Preview preview.baremetal.cluster.gke.io/private-registry: "enable".

  • Cette fonctionnalité est destinée aux clusters d'utilisateurs 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 pour 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é, ainsi que le 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 Docker, config.json (par exemple, $HOME/.docker/config.json). Pour authentifier Docker pour accéder à votre registre privé, config.json doit contenir une version encodée en base64 de vos identifiants dans la section auths du fichier. Vous pouvez suivre les instructions de la section Clé de compte de service de la documentation du registre d'artefacts pour renseigner correctement la section auths. Pour protéger les données sensibles, vous pouvez utiliser chown et chmod pour restreindre l'accès au fichier de configuration Docker s'il contient des identifiants.

      Si votre serveur de registre privé ne nécessite pas d'identifiants pour l'authentification, vous pouvez omettre le champ pullCredentialConfigPath.

  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'utilisateurs, la configuration du registre privé est spécifiée dans la spécification de ressources du cluster d'utilisateur, qui se trouve dans le cluster d'administration. De plus, vous devez stocker les identifiants du registre privé dans un secret, qui se trouve également dans le cluster d'administration:

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

    Si vous souhaitez limiter le champ d'application du 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 le 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 Docker, config.json (par exemple, $HOME/.docker/config.json). Pour authentifier Docker pour accéder à votre registre privé, config.json doit contenir une version encodée en base64 de vos identifiants dans la section auths du fichier. Vous pouvez suivre les instructions de la section Clé de compte de service de la documentation du registre d'artefacts pour renseigner correctement la section auths. Pour protéger les données sensibles, vous pouvez utiliser chown et chmod pour restreindre l'accès au fichier de configuration Docker s'il contient des identifiants.

      Si votre serveur de registre privé ne nécessite pas d'identifiants pour l'authentification, vous pouvez omettre le champ pullCredentialConfigPath.

    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 d'autorité de certification du 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 (Aperçu) 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 d'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 du secret du certificat d'autorité de certification, si vous l'avez créé.

    • REGISTRY_HOST: nom de domaine ou adresse IP du registre privé, ainsi que le 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.