Cette page décrit le modèle de confiance dans les clusters Google Kubernetes Engine (GKE), y compris la communication au sein des clusters et la manière dont les requêtes sont authentifiées pour les composants tels que les plans de contrôle.
Ce document s'adresse aux spécialistes de la sécurité qui souhaitent comprendre le modèle de confiance de cluster de GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Avant de lire cette page, assurez-vous de connaître les éléments suivants:
Communication au sein d'un cluster
GKE applique divers mécanismes de sécurité au trafic entre les composants du cluster, comme suit:
Trafic entre le plan de contrôle et les nœuds: le plan de contrôle communique avec un nœud pour gérer les conteneurs. Lorsque le plan de contrôle envoie une requête (par exemple
kubectl logs) aux nœuds, la requête est envoyée via un tunnel proxy Konnectivity. Les requêtes envoyées par le plan de contrôle sont authentifiées et protégées par TLS. Lorsqu'un nœud envoie une requête au plan de contrôle, par exemple du kubelet au serveur d'API, cette requête est authentifiée et chiffrée à l'aide d'une authentification TLS mutuelle (mTLS).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 le nœud.
Trafic entre les nœuds: les nœuds sont des VM Compute Engine. Les connexions entre les nœuds du réseau de production Google Cloud sont authentifiées et chiffrées. Pour en savoir plus, consultez la section VM à VM du livre blanc Chiffrement en transit.
Trafic entre les 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 section Chiffrement et authentification du réseau virtuelGoogle Cloud .
Vous pouvez limiter le trafic entre pods avec une NetworkPolicy. 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 queCloud Service Mesh ou une autre méthode de chiffrement de la couche d'application.
Trafic entre les composants du plan de contrôle: le trafic entre les différents composants exécutés sur le plan de contrôle est authentifié et chiffré à l'aide de TLS. Le trafic ne sort jamais d'un réseau appartenant à Google et protégé par des pare-feu.
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. - Dans les clusters qui exécutent des instances de base de données etcd sur les VM du plan de contrôle, une autorité de certification par paire etcd distincte par cluster est utilisée pour établir une relation de confiance entre les instances etcd.
- Dans tous les clusters GKE, une autorité de certification API etcd distincte est utilisée pour établir une relation de confiance entre le serveur d'API Kubernetes et l'API 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 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 ou la fédération d'identité de charge de travail pour GKE.
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.
Stockage de l'état du cluster
Les clusters GKE stockent l'état des objets de l'API Kubernetes sous forme de paires clé-valeur dans une base de données. Le serveur d'API Kubernetes de votre plan de contrôle interagit avec cette base de données à l'aide de l'API etcd. GKE utilise l'une des technologies suivantes pour exécuter la base de données d'état du cluster:
- etcd: le cluster utilise des instances etcd qui s'exécutent sur les VM du plan de contrôle.
- Spanner: le cluster utilise une base de données Spanner qui s'exécute en dehors des VM du plan de contrôle.
Quelle que soit la technologie de base de données utilisée par un cluster, chaque cluster GKE diffuse l'API etcd dans le plan de contrôle. Pour chiffrer le trafic impliquant la base de données d'état du cluster, GKE utilise une ou plusieurs des autorités de certification par cluster suivantes:
- Autorité de certification de l'API etcd: utilisée pour signer les certificats du trafic vers et depuis les points de terminaison de l'API etcd. Une autorité de certification API etcd s'exécute dans chaque cluster GKE.
- Autorité de certification de paire etcd: utilisée pour signer les certificats du trafic entre les instances de base de données etcd sur le plan de contrôle. Une autorité de certification de paire etcd s'exécute dans n'importe quel cluster qui utilise des bases de données etcd. Les clusters qui utilisent des bases de données Spanner n'utilisent pas l'autorité de certification de paire etcd.
Les clés racine de l'autorité de certification de l'API etcd sont distribuées aux métadonnées de chaque instance Compute Engine sur laquelle le plan de contrôle s'exécute. L'autorité de certification de l'API etcd n'est pas partagée entre les clusters.
Les certificats d'autorité de certification etcd sont valables cinq ans. GKE effectue automatiquement une rotation de ces certificats avant leur expiration.
Rotation des 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.