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

Les autorités de certification de cluster (CA) émettent et signent des certificats pour permettre l'authentification et le chiffrement sécurisés entre les composants du cluster. Par défaut, dans GKE sur une solution Bare Metal, l'API Cluster crée les autorités de certification de cluster lorsque vous créez un cluster. Ce document explique comment utiliser vos propres autorités de certification avec GKE sur Bare Metal. L'utilisation d'autorités de certification de cluster personnalisées vous permet de mieux contrôler l'émission et la gestion de vos certificats de 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, composées d'un fichier de certificat CA et du fichier de clé privée correspondant. Vous devez fournir une paire certificat CA/clé pour chacune des autorités de certification de cluster requises suivantes:

Autorité de certification etcd: le certificat du certificat CA etcd sécurise la communication du serveur d'API Kubernetes vers les instances répliquées etcd, ainsi que la communication entre les instances répliquées etcd.
autorité de certification du cluster: le certificat de l'autorité de certification du cluster sécurise la communication entre le serveur d'API Kubernetes et tous les clients d'API Kubernetes internes. Les clients incluent le kubelet, le gestionnaire de contrôleurs et le programmeur.
Autorité de certification proxy frontal: le certificat de l'autorité de certification proxy frontal sécurise la communication avec des API agrégées.

Vous pouvez fournir une paire certificat/clé unique pour chaque autorité de certification ou réutiliser une paire certificat/clé pour plusieurs autorités de certification.

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é d'autorité de certification de cluster personnalisé fonctionne avec tous les types de clusters: administrateur, utilisateur, hybride et autonome.

Prérequis

Vous devez préparer vos propres autorités de certification racine conformément aux règles suivantes:

Les autorités de certification personnalisées sont des autorités de certification racine, chacune composée d'un fichier de certificat autosigné et d'un fichier de clé privée.
Les autorités de certification intermédiaires et subordonnées ne sont pas prises en charge.
Pour votre certificat, nous vous recommandons d'utiliser le format DER (Distinguished Encoding Rules) (voir la recommandation X.690 pour 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 Public-Key Cryptography Standards (PKCS #1). 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 perturbations potentielles au niveau des clusters, 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, de 10 à 30 ans, par exemple.
Assurez-vous que les fichiers de certificat et de clé se trouvent sur le poste de travail administrateur où vous exécutez la CLI 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 du cluster

Lorsque vous créez un cluster avec bmctl, vous devez d'abord mettre à 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 d'un 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 CA et aux fichiers de clé privée.
Spécifiez les chemins d'accès aux fichiers de clé privée uniquement

Lorsque vous spécifiez uniquement les clés privées, bmctl recherche les fichiers de certificats CA correspondants dans le même répertoire. Les fichiers de certificat doivent avoir le même nom que les fichiers de clé privée correspondants et l'extension de fichier .crt. Par exemple, si le chemin d'accès de 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 des identifiants du fichier de configuration, comme illustré dans les exemples suivants.

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

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 autorité de certification de cluster. Dans cet exemple, les fichiers de certificat et de clé 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 de 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 CA correspondants doivent également se trouver dans le répertoire /.sa-keys. Les fichiers de certificat portent le même nom que les fichiers de clé, mais avec l'extension .crt. Ainsi, le fichier de certificat CA etcd porte le nom 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 certificat et de clé d'autorité

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 autorités de certification de cluster. Le certificat CA et les fichiers de clé privée se trouvent tous deux dans le répertoire /custom-ca. Conformément à la convention de dénomination, le nom de fichier du certificat CA 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 d'une autorité de certification

Lorsque vous effectuez une rotation des autorités de certification, vous pouvez spécifier les chemins d'accès au certificat d'autorité de certification de cluster personnalisé et aux fichiers de clé privé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 les chemins d'accès aux fichiers de clé privée d'autorité de certification personnalisée uniquement. Le fichier de certificat CA correspondant doit se trouver dans le même répertoire, porter le même nom que le fichier de clé et avoir une extension de fichier .crt.
Réutilisez un certificat CA/une paire de clés en spécifiant le même certificat et les mêmes chemins de clé pour plusieurs autorités de certification de cluster.
Omettez les arguments pour les chemins d'accès des autorités de certification personnalisées. Si vous ne spécifiez pas de chemins d'accès aux autorités de certification personnalisées lors de la rotation des autorités de certification, GKE sur Bare Metal crée et utilise l'autorité de certification de cluster standard.

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

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 effectuer une rotation des 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 CA du cluster.
CLUSTER_CA_KEY_PATH: chemin d'accès au fichier de clé privée de l'autorité de certification de cluster.
ETCD_CA_CERT_PATH: chemin d'accès au fichier de certificat CA 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 de 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 effectuer une rotation des 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 de 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.