Cette page décrit les relations de confiance au sein des clusters Google Kubernetes Engine (GKE), y compris la manière dont les plans de contrôle 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.
- Communication entre le plan de contrôle et le nœud
Le plan de contrôle communique avec un nœud pour la gestion des conteneurs. Lorsque le plan de contrôle envoie une requête (par exemple
kubectl logs) aux nœuds situés dans des clusters publics, la requête est envoyée via un tunnel proxy Konnectivity. Les requêtes adressées aux nœuds des clusters privés sont envoyées via l'appairage de VPC. Les requêtes envoyées par le plan de contrôle sont protégées par TLS qui garantit l'authentification, l'intégrité et le chiffrement. Lorsqu'un nœud envoie une requête au plan de contrôle, par exemple lorsque kubelet envoie une requête au serveur d'API, cette requête est authentifiée et chiffrée au moyen d'une authentification TLS mutuelle.Tous les clusters nouveaux et mis à jour utilisent TLS 1.3 pour les communications entre le plan de contrôle et le nœud. TLS 1.2 est la version minimale compatible pour la communication entre le plan de contrôle et la nœud.
- Communication entre nœuds
Les nœuds sont des VM Compute Engine pour lesquelles les connexions au sein du réseau de production de Google sont authentifiées et chiffrées. Pour en savoir plus, consultez la section VM à VM du livre blanc Chiffrement en transit.
- Communication entre pods
Lorsqu'un pod envoie une requête à un autre pod, ce trafic n'est pas authentifié par défaut. GKE chiffre le trafic entre les pods sur différents nœuds au niveau de la couche réseau. Le trafic entre les pods d'un même nœud n'est pas chiffré par défaut. Pour en savoir plus sur le chiffrement de la couche réseau, consultez la page Chiffrement et authentification du réseau virtuel Google Cloud.
Vous pouvez limiter le trafic entre pods avec une Règle de réseau. Vous pouvez également chiffrer tout le trafic entre pods, y compris le trafic sur le même nœud, à l'aide d'un maillage de services tel queAnthos Service Mesh ou une autre méthode de chiffrement de la couche d'application.
- Communication entre etcd
Une instance de etcd peut communiquer avec une autre instance de etcd pour maintenir à jour l'état. Lorsqu'une instance de etcd envoie une requête à une autre instance, cette requête est authentifiée et chiffrée au moyen d'une authentification TLS mutuelle. Le trafic ne sort jamais d'un réseau appartenant à GKE et protégé par des pare-feu.
- Communication entre le plan de contrôle et l'etcd
Dans GKE 1.23.6-gke.1100 et versions ultérieures, cette communication est chiffrée à l'aide du protocole TLS mutuel.
Racine de confiance
GKE présente la configuration suivante :
- L'autorité de certification racine du cluster est utilisée pour valider les certificats clients du serveur d'API et des kubelets. Cela signifie que les plans de contrôle 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.ioen envoyant une requête de signature de certificat ; L'autorité de certification racine a une durée de vie limitée, comme décrit dans la section Durée de vie de l'autorité de certification racine du cluster. - Une autorité de certification etcd distincte par cluster soit utilisée pour 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 pour les relations de confiance. Dans GKE, le certificat d'API du plan de contrôle 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 trouve compromise, aucune autre autorité de certification de cluster n'est 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. Ce secret partagé est accessible par les pods du nœud, sauf si vous activez les nœuds GKE protégés, la fédération d'identité de charge de travail pour GKE ou la dissimulation des métadonnées.
Durée de vie de l'autorité de certification racine du cluster
L'autorité de certification racine du cluster a une durée de vie limitée, après quoi les certificats signés par l'autorité de certification arrivée à expiration ne sont plus valides. Vérifiez la date d'expiration approximative de l'autorité de certification de votre cluster en suivant les instructions de la section Vérifier la durée de vie des identifiants.
Vous devez effectuer une rotation manuelle de vos identifiants avant l'expiration de votre autorité de certification racine existante. Si l'autorité de certification expire et que vous ne procédez pas à la rotation de vos identifiants, votre cluster risque d'entrer dans un état irrécupérable. GKE dispose des mécanismes suivants pour tenter d'éviter les clusters irrécupérables :
- Votre cluster passe à l'état
DEGRADEDsept jours avant l'expiration de l'autorité de certification GKE tente d'effectuer une rotation automatique des identifiants 30 jours avant l'expiration de l'autorité de certification. Cette rotation automatique ignore les intervalles de maintenance et peut entraîner des interruptions lorsque GKE recrée les nœuds pour utiliser de nouveaux identifiants. Les clients externes, tels que kubectl dans les environnements locaux, ne fonctionneront pas tant que vous ne les aurez pas mis à jour pour utiliser les nouveaux identifiants.
Pour savoir comment effectuer une rotation, consultez la section Effectuer une rotation des identifiants de cluster.
etcd
Dans GKE, etcd s'appuie sur une autorité de certification etcd distincte par cluster pour les relations de confiance.
Les clés racine de l'autorité de certification etcd sont distribuées aux métadonnées de chaque machine virtuelle (VM) sur laquelle le plan de contrôle s'exécute. Tout code s'exécutant sur des VM du plan de contrôle 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'étant pas partagée entre clusters, 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.