Utiliser des autorités de certification de cluster personnalisées

Les autorités de certification de cluster émettent et signent des certificats pour permettre l'authentification et le chiffrement sécurisés entre les composants du cluster. Par défaut, dans Google Distributed Cloud, l'API Cluster crée les CA du cluster lorsque vous créez un cluster. Ce document explique comment utiliser vos propres autorités de certification avec Google Distributed Cloud. L'utilisation d'AC de cluster personnalisées vous permet de mieux contrôler l'émission et la gestion des certificats de votre cluster. Vous pouvez également contrôler la confiance, les paramètres de l'algorithme de chiffrement, la profondeur des certificats subordonnés et leur objectif.

Pour utiliser des autorités de certification personnalisées, vous devez fournir des autorités de certification racine, qui se composent d'un fichier de certificat CA et de son fichier de clé privée correspondant. Vous fournissez une paire de fichiers de certificat et de clé d'autorité de certification pour chacune des autorités de certification de cluster requises suivantes :

  • CA etcd : le certificat de l'autorité de certification etcd sécurise la communication du serveur d'API Kubernetes vers les instances dupliquées etcd, ainsi que la communication entre les instances dupliquées etcd.

  • CA du cluster : le certificat de la CA du cluster sécurise la communication entre le serveur d'API Kubernetes et tous les clients internes de l'API Kubernetes. Parmi les clients, on peut citer kubelet, le gestionnaire de contrôleurs et le planificateur.

  • CA de proxy frontal : le certificat de la CA de proxy frontal sécurise la communication avec les API agrégées.

Vous pouvez fournir une paire certificat/clé unique pour chaque CA ou réutiliser une paire certificat/clé pour plusieurs CA.

Vous appliquez les paires certificat-clé lors de la création du cluster (méthode bmctl uniquement) et de la rotation de l'autorité de certification. La fonctionnalité "CA de cluster personnalisée" fonctionne avec tous les types de clusters : administrateur, utilisateur, hybride et autonome.

Prérequis

Vous êtes responsable de la préparation de vos propres autorités de certification racine conformément aux règles suivantes :

  • Les CA personnalisées sont des CA racines, chacune étant constituée d'un fichier de certificat autosigné et d'un fichier de clé privée.

  • Pour votre certificat, nous vous recommandons d'utiliser le format DER (Distinguished Encoding Rules). Pour en savoir plus, consultez la recommandation X.690 sur les règles d'encodage ASN.1. Votre fichier de certificat doit contenir des données encodées en base64 précédées de ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ et suivies de ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

  • Pour la clé privée, nous vous recommandons d'utiliser le format PKCS #1 (Public-Key Cryptography Standards). Votre fichier de clé doit contenir des données encodées en base64 précédées de ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ et suivies de ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

  • Pour minimiser les risques d'interruption du cluster, les autorités de certification personnalisées ne doivent pas expirer avant cinq ans. Nous vous recommandons de définir une période d'expiration plus longue, par exemple de 10 à 30 ans.

  • Assurez-vous que les fichiers de certificat et de clé se trouvent sur la station de travail administrateur sur laquelle vous exécutez les commandes bmctl.

  • L'utilisateur qui exécute les commandes bmctl doit avoir accès au répertoire dans lequel vous stockez les fichiers. Nous vous recommandons de placer les fichiers dans un répertoire existant utilisé pour les certificats et les clés. Par exemple, vous pouvez stocker les fichiers dans ~/baremetal/bmctl-workspace/.sa-keys avec vos clés de compte de service.

  • L'utilisateur qui exécute les commandes bmctl doit disposer d'un accès en lecture aux fichiers.

Utiliser une autorité de certification personnalisée lors de la création d'un cluster

Lorsque vous créez un cluster avec bmctl, vous mettez d'abord à jour le fichier de configuration du cluster pour décrire les fonctionnalités et les paramètres de votre cluster. Pour utiliser la fonctionnalité d'autorité de certification de cluster personnalisée lors de la création du cluster, vous disposez de deux options pour spécifier les autorités de certification de cluster personnalisées dans le fichier de configuration du cluster:

  • Spécifiez les chemins d'accès aux fichiers de certificat de l'autorité de certification et aux fichiers de clé privée.
  • Spécifiez uniquement les chemins d'accès aux fichiers de clé privée.

Lorsque vous spécifiez uniquement les clés privées, bmctl recherche les fichiers de certificat CA correspondants dans le même répertoire. Les fichiers de certificat doivent porter le même nom que les fichiers de clé privée correspondants et avoir l'extension de fichier .crt. Par exemple, si le chemin d'accès à la clé privée est /custom-ca/cluster_ca.key, bmctl s'attend à ce que le chemin d'accès au certificat soit /custom-ca/cluster_ca.crt.

Dans les deux cas, les chemins d'accès sont spécifiés dans la section "credentials" (identifiants) du fichier de configuration, comme indiqué dans les exemples suivants.

Exemple 1 : Spécifier les chemins d'accès au certificat et à la clé

L'extrait suivant d'un fichier de configuration de cluster montre comment spécifier les chemins d'accès aux fichiers de certificat et de clé pour chaque CA de cluster. Dans cet exemple, les fichiers de clé et de certificat de l'autorité de certification se trouvent dans le même répertoire que les fichiers de clé JSON du compte de service.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Exemple 2 : Spécifier uniquement les chemins d'accès des clés privées

L'extrait suivant d'un fichier de configuration de cluster montre comment spécifier uniquement les chemins d'accès aux fichiers de clés. Dans cet exemple, les fichiers de clé privée de l'autorité de certification se trouvent dans le même répertoire que les fichiers de clé JSON du compte de service. Les fichiers de certificat de l'autorité de certification correspondants doivent également se trouver dans le répertoire /.sa-keys. Les fichiers de certificat ont le même nom que les fichiers de clé, mais avec l'extension .crt. Le fichier de certificat de l'autorité de certification etcd est donc nommé etcd_ca.crt.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Exemple 3 : Réutiliser une seule paire de fichiers de clé et de certificat CA

L'extrait suivant d'un fichier de configuration de cluster montre comment spécifier uniquement les chemins d'accès aux fichiers de clés. Dans cet exemple, une seule paire certificat/clé est utilisée pour toutes les CA de cluster. Les fichiers de certificat et de clé privée de l'autorité de certification se trouvent tous les deux dans le répertoire /custom-ca. En suivant la convention d'attribution de noms, le nom de fichier du certificat de l'autorité de certification est custom_ca.crt.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Utiliser une autorité de certification personnalisée lors de la rotation des autorités de certification

Lorsque vous effectuez une rotation des autorités de certification, vous pouvez spécifier les chemins d'accès à vos fichiers de certificat et de clé privée d'autorité de certification de cluster personnalisée. Les options dont vous disposez sont semblables à celles permettant de spécifier des autorités de certification de cluster personnalisées lors de la création du cluster. Lorsque vous exécutez la commande bmctl update credentials certificate-authorities rotate, vous disposez des options suivantes :

  • Spécifiez les chemins d'accès aux fichiers de certificat CA personnalisés et aux fichiers de clé privée.
  • Spécifiez uniquement les chemins d'accès aux fichiers de clé privée de l'autorité de certification personnalisée. Le fichier de certificat d'autorité de certification correspondant doit se trouver dans le même répertoire, porter le même nom que le fichier de clé et avoir l'extension .crt.
  • Réutilisez une paire certificat-clé d'autorité de certification en spécifiant les mêmes chemins d'accès au certificat et à la clé pour plusieurs autorités de certification de cluster.
  • Omettez les arguments pour les chemins d'autorité de certification personnalisés. Si vous ne spécifiez pas de chemins d'autorité de certification personnalisés lorsque vous faites pivoter les autorités de certification, Google Distributed Cloud crée et utilise l'autorité de certification de cluster standard.

Exemple 1 : Spécifier les chemins d'accès au certificat et à la clé privée de l'autorité de certification

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster pour lequel vous souhaitez alterner les autorités de certification.
  • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. Pour les clusters autogérés, ce fichier est le fichier kubeconfig du cluster.
  • CLUSTER_CA_CERT_PATH : chemin d'accès au fichier de certificat de l'autorité de certification du cluster.
  • CLUSTER_CA_KEY_PATH : chemin d'accès au fichier de clé privée de l'autorité de certification du cluster.
  • ETCD_CA_CERT_PATH : chemin d'accès au fichier de certificat de l'autorité de certification etcd.
  • ETCD_CA_KEY_PATH : chemin d'accès au fichier de clé privée de l'autorité de certification etcd.
  • FRONT_PROXY_CA_CERT_PATH : chemin d'accès au fichier de certificat du proxy frontal.
  • FRONT_PROXY_CA_KEY_PATH : chemin d'accès au fichier de clé privée du proxy frontal.

Exemple 2 : Spécifier uniquement les chemins d'accès des clés privées

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster pour lequel vous souhaitez alterner les autorités de certification.
  • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. Pour les clusters autogérés, ce fichier est le fichier kubeconfig du cluster.
  • CLUSTER_CA_KEY_PATH : chemin d'accès au fichier de clé privée de l'autorité de certification du cluster.
  • ETCD_CA_KEY_PATH : chemin d'accès au fichier de clé privée de l'autorité de certification etcd.
  • FRONT_PROXY_CA_KEY_PATH : chemin d'accès au fichier de clé privée du proxy frontal.

Autorités de certification intermédiaires

Les clusters de version 1.29 sont compatibles avec l'utilisation d'autorités de certification intermédiaires en tant que fonctionnalité preview. Cette fonctionnalité n'est pas au même stade de lancement pour toutes les versions de produit compatibles :

Comme pour les autorités de certification racine, qui exigent de préparer trois ensembles d'autorités de certification pour utiliser des autorités de certification intermédiaires. Chaque CA se compose d'un fichier de certificat CA et du fichier de clé privée correspondant. Vous fournissez une paire de fichiers de certificat et de clé d'autorité de certification pour chacune des autorités de certification de cluster requises suivantes :

  • CA Etcd
  • CA du cluster
  • CA de proxy frontal

Comme pour les CA racines, vous pouvez fournir une paire certificat/clé unique pour chaque CA ou réutiliser une paire certificat/clé pour plusieurs CA en spécifiant les mêmes chemins d'accès aux fichiers dans la configuration des CA.

Lorsque vous utilisez des autorités de certification intermédiaires, le fichier de certificat CA doit contenir l'intégralité de la chaîne de certificats, y compris les certificats des autorités de certification intermédiaires jusqu'à l'autorité de certification racine. Les certificats sont listés dans l'ordre inverse de leur signature, avec le dernier certificat CA intermédiaire en haut et le certificat CA racine en bas.

Dans l'exemple suivant (en commençant par l'autorité de certification racine en bas), l'ordre indique ce qui suit :

  • L'autorité de certification racine a signé le certificat CA intermédiaire A.
  • L'autorité de certification intermédiaire A a signé le certificat de l'autorité de certification intermédiaire B.
  • La chaîne se poursuit jusqu'au certificat CA intermédiaire Y final, qui a été signé par l'autorité de certification intermédiaire X.
-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE-----

Pour poursuivre avec cet exemple, la clé privée associée au certificat CA Intermediate-Y doit être transmise avec les chaînes de certificats CA de la même manière que dans une autorité de certification personnalisée.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Pour vérifier si le cluster utilise l'autorité de certification intermédiaire, inspectez le nombre de certificats dans le secret de l'autorité de certification du cluster :

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l