Confiance dans les clusters

Cette page décrit les relations de confiance au sein des clusters Google Kubernetes Engine, y compris la manière dont les maîtres et les nœuds authentifient les requêtes.

Communication au sein d'un cluster

Au sein d'un cluster, de nombreuses connexions interviennent pour la communication entre les composants Kubernetes.

Maître vers nœud
Le maître communique avec un nœud pour gérer les conteneurs. Lorsque le maître envoie une demande au nœud, par exemple "kubectl logs", cette demande est transmise via un tunnel SSH et, de surcroît, est protégée par un protocole TLS non authentifié assurant l'intégrité et le chiffrement. Lorsqu'un nœud envoie une demande au maître, par exemple lorsque kubelet envoie une requête au serveur d'API, cette demande est authentifiée et chiffrée au moyen d'une authentification TLS mutuelle.
Nœud vers nœud
Un nœud peut communiquer avec un autre nœud dans le cadre d'une charge de travail spécifique. Lorsque le nœud envoie une requête à un autre nœud, cette demande est authentifiée et sera chiffrée si la connexion franchit une limite physique contrôlée par Google. Notez qu'aucun composant Kubernetes ne nécessite de communication entre nœuds. Pour en savoir plus, consultez le livre blanc Chiffrement en transit.
Pod vers pod
Un pod peut communiquer avec un autre pod dans le cadre d'une charge de travail spécifique. Lorsque le pod envoie une requête à un autre pod, cette requête n'est ni authentifiée ni chiffrée. Notez qu'aucun composant Kubernetes ne nécessite de communication entre pods. Le trafic entre pods peut être restreint par une règle de réseau et chiffré au moyen d'un maillage de services de type Istio ou la mise en œuvre d'un chiffrement au niveau de la couche d'application.
etcd vers etcd
Une instance de etcd peut communiquer avec une autre instance de etcd pour maintenir à jour l'état. Lorsqu'une instance d'etcd envoie une demande à une autre instance, cette demande est authentifiée et chiffrée par TLS mutuel. Le trafic ne sort jamais d'un réseau appartenant à GKE et protégé par des pare-feu.
Maître vers etcd
Cette communication intervient entièrement sur localhost et n'est ni authentifiée, ni chiffrée.

Racine de confiance

GKE est configuré de telle sorte que :

  • l'autorité de certification racine du cluster (CA) est utilisée pour valider les certificats clients du serveur d'API et des kubelets. Cela signifie que les maîtres et les nœuds ont la même racine de confiance. Tout kubelet au sein du pool de nœuds du cluster peut demander un certificat à cette autorité à travers l'API certificates.k8s.io, en envoyant une demande de signature de certificat ;
  • une autorité de certification etcd distincte par cluster sert à valider les certificats pour etcd.

Serveur d'API et kubelets

Le serveur d'API et les kubelets s'appuient sur l'autorité de certification racine du cluster Kubernetes pour les relations de confiance. Dans GKE, le certificat d'API maître est signé par l'autorité de certification racine du cluster. Chaque cluster exécute sa propre autorité de certification. Par conséquent, si une autorité de certification se trouvait compromise, aucune autre autorité de certification de cluster ne serait affectée.

Un service Google interne gère les clés racine de cette autorité de certification, qui ne peuvent pas être exportées. Ce service accepte les demandes de signature de certificat, y compris celles provenant des kubelets de chaque cluster GKE. Même si le serveur d'API d'un cluster se trouvait compromis, l'autorité de certification ne le serait pas et aucun autre cluster ne serait affecté.

À la création, chaque nœud du cluster reçoit une clé secrète partagée qu'il peut utiliser pour envoyer des demandes de signature de certificat à l'autorité de certification racine du cluster, et obtenir des certificats de client kubelet. Le kubelet utilise ensuite ces certificats pour authentifier ses requêtes auprès du serveur d'API. Notez que les pods ont accès à cette clé secrète partagée, sauf si la dissimulation de métadonnées est activée.

Les certificats du serveur d'API et des kubelets sont valables pour une période de cinq ans, mais vous pouvez les changer manuellement avant ce délai en effectuant une rotation des identifiants.

etcd

etcd s'appuie sur une autorité de certification etcd distincte par cluster pour les relations de confiance dans GKE.

Les clés racine de l'autorité de certification etcd sont distribuées aux métadonnées de chaque VM sur laquelle le maître s'exécute. Tout code s'exécutant sur des VM maîtresses, ou disposant d'un accès pour calculer des métadonnées pour ces VM, peut signer des certificats en tant que cette autorité de certification. Même si l'etcd d'un cluster se trouvait compromis, l'autorité de certification n'est pas partagée entre clusters, de sorte qu'aucun autre cluster ne serait affecté.

Les certificats etcd sont valables cinq ans.

Effectuer une rotation de vos certificats

Pour assurer la rotation de tous les certificats du serveur d'API et des kubelets de votre cluster, effectuez une rotation des identifiants. Il n'y a aucun moyen de déclencher manuellement une rotation des certificats etcd : elle est gérée automatiquement dans GKE.

Étape suivante

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Kubernetes Engine