Sécurité du plan de contrôle

Cette page explique comment Google Kubernetes Engine (GKE) sécurise les composants de votre plan de contrôle Découvrez les fonctionnalités de sécurité intégrées à GKE, qui incluent un OS renforcé, une architecture et une isolation robustes, un accès sécurisé au plan de contrôle, la sécurité de la base de données d'état du cluster basée sur etcd ou Spanner, l'autorité de certification et la confiance du cluster, ainsi que la gestion des failles et des correctifs.

Cette page s'adresse aux spécialistes de la sécurité qui souhaitent comprendre comment Google gère les composants du plan de contrôle GKE et les mesures de sécurité mises en place pour évaluer efficacement les risques et assurer la sécurité de vos déploiements 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.

Dans le modèle de responsabilité partagée, Google gère pour vous les composants du plan de contrôle GKE, qui inclut le serveur d'API Kubernetes, le stockage d'objets de l'API Kubernetes et d'autres contrôleurs. Google est responsable de la sécurisation du plan de contrôle, mais vous pouvez toutefois configurer certaines options en fonction de vos besoins. Vous êtes responsable de la sécurisation de vos nœuds, conteneurs et pods.

Système d'exploitation renforcé

Les composants du plan de contrôle GKE s'exécutent sur Container-Optimized OS, un système d'exploitation à sécurité renforcée conçu par Google. Pour obtenir une description détaillée des fonctionnalités de sécurité y étant intégrées, consultez la présentation des fonctionnalités de sécurité de Container-Optimized OS.

Architecture et isolement

Dans un cluster GKE, les composants du plan de contrôle s'exécutent sur des instances Compute Engine appartenant à Google, dans un projet géré par Google. Chaque instance exécute ces composants pour un seul client.

Pour en savoir plus sur la manière dont les composants de cluster s'authentifient entre eux, consultez la page Confiance dans les clusters.

Accès du plan de contrôle à votre projet

GKE utilise un agent de service nommé "Agent de service Kubernetes Engine" pour activer les ressources du cluster en votre nom, telles que les nœuds, les disques et les équilibreurs de charge. Le compte de service se voit automatiquement attribuer le rôle d'agent de service Kubernetes Engine (roles/container.serviceAgent) sur votre projet.

L'agent de service Kubernetes Engine possède l'adresse e-mail suivante :

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

Dans cette adresse e-mail, PROJECT_NUMBER est votre numéro de projet.

Accès administrateur au cluster

Les sessions SSH des ingénieurs en fiabilité des sites (SRE, Site Reliability Engineers) de Google sont enregistrées dans le journal d'audit interne à travers l'infrastructure d'audit interne de Google, qui est disponible pour les analyses judiciaires et les interventions en matière de sécurité. Pour en savoir plus, consultez la section Accès administrateur dans le livre blanc sur la sécurité de Google.

Sécurité de la base de données d'état du cluster

Dans Google Cloud, le contenu client est chiffré au niveau de la couche du système de fichiers par défaut. Ce chiffrement inclut l'infrastructure qui héberge la base de données basée sur etcd ou Spanner qui stocke l'état des objets d'API Kubernetes dans votre cluster. Pour en savoir plus sur la base de données d'état du cluster, consultez la page Architecture d'un cluster GKE.

La base de données d'état du cluster stocke la configuration de chaque objet d'API Kubernetes de votre cluster sous forme de paires clé-valeur. GKE utilise des ports TCP spécifiques sur les VM du plan de contrôle pour les types de communication suivants avec la base de données d'état du cluster:

  • Clients de l'API etcd: GKE diffuse l'API etcd sur chaque VM du plan de contrôle. Les clients de l'API etcd dans le plan de contrôle, comme le serveur d'API Kubernetes, utilisent l'un des ports suivants:

    • Port 2379: ce port est utilisé lorsque GKE stocke l'état du cluster dans des instances de base de données etcd exécutées dans chaque VM de plan de contrôle.
    • Port 3379: ce port est utilisé lorsque GKE stocke l'état du cluster dans une base de données Spanner distincte du plan de contrôle.

    Le port utilisé par les clients de l'API etcd est lié à l'interface réseau de bouclage local et n'est accessible que depuis la VM du plan de contrôle qui exécute le serveur d'API Kubernetes.

  • Instances de base de données etcd: si les VM du plan de contrôle exécutent des instances de base de données etcd, les serveurs d'API etcd de chaque VM utilisent le port 2380 pour communiquer entre eux. Le trafic sur le port 2380 entre les instances de base de données etcd sur plusieurs VM de plan de contrôle (par exemple, dans des clusters régionaux) est chiffré par TLS mutuel. Avec le TLS mutuel, chaque serveur doit prouver son identité à l'autre.

    Le port 2380 n'est pas utilisé dans les clusters qui stockent l'état du cluster dans une base de données Spanner, car la base de données ne s'exécute pas dans les VM du plan de contrôle.

Autorité de certification et approbation de cluster

Chaque cluster dispose de sa propre autorité de certification racine, dont les clés racine sont gérées par un service interne de Google. et les clés racines de cette autorité de certification sont distribuées aux métadonnées des machines virtuelles qui exécutent le serveur d'API Kubernetes. La communication entre les nœuds et le serveur d'API Kubernetes est protégée par TLS. Chaque cluster comporte également sa propre autorité de certification pour l'API etcd et, si le cluster exécute des instances de base de données etcd, pour le trafic entre les instances etcd. Pour en savoir plus, consultez la section Approbation de cluster.

Gestion des failles et des correctifs

GKE respecte les normes de Google en matière de test, de qualification et de déploiement progressif des modifications apportées au plan de contrôle. Cela minimise le risque d'indisponibilité d'un composant du plan de contrôle. GKE est soumis à un contrat de niveau de service qui définit de nombreux aspects de la disponibilité.

Les composants du plan de commande GKE sont gérés par une équipe d'ingénieurs de la fiabilité des sites Google et sont tenus à jour avec les derniers correctifs de sécurité. Cela inclut les correctifs du système d'exploitation hôte, des composants Kubernetes et des conteneurs s'exécutant sur les machines virtuelles du plan de contrôle.

GKE applique rapidement les nouveaux correctifs au niveau du noyau, du système d'exploitation et de Kubernetes sur les VM du plan de contrôle. Lorsqu'il s'agit de correctifs concernant des failles connues, des informations complémentaires sont disponibles dans les bulletins de sécurité GKE. GKE analyse tous les conteneurs Kubernetes propres au système et à GKE à la recherche de failles à l'aide de Artifact Analysis pour y appliquer systématiquement les correctifs nécessaires, ce qui s'avère bénéfique pour l'ensemble de l'écosystème Kubernetes.

Les ingénieurs de Google participent à la recherche, la correction et la divulgation des bugs de sécurité liés à Kubernetes. Google fait également appel à des chercheurs externes en sécurité, par le biais du Vulnerability Reward Program déployé à l'échelle de Google pour rechercher des bugs de sécurité. Dans certains cas, comme lors de la faille dnsmasq d'octobre 2017, GKE a pu corriger tous les clusters en cours d'exécution avant que la faille ne devienne publique.

Éléments accessibles

Les fonctions de sécurité décrites précédemment dans cette rubrique sont gérées par Google. Cette section et la suivante traitent de celles que vous pouvez surveiller et configurer.

  • Journaux d'audit: la journalisation d'audit est activée par défaut. Ils fournissent un enregistrement détaillé, disponible dans Google Cloud Observabilité, des appels passés au serveur d'API Kubernetes. Vous pouvez afficher les entrées de journal dans l'explorateur de journaux de la consoleGoogle Cloud . Vous pouvez également afficher et analyser ces journaux à l'aide de BigQuery.

  • Intégrité de l'image de la VM du plan de contrôle: GKE ajoute des journaux détaillés pour la création de VM de nœud et les événements de démarrage dans Cloud Logging. De plus, nous publions sur GitHub des VSA SLSA qui correspondent aux images de machine du plan de contrôle et des nœuds de calcul. Vous pouvez vérifier que vos VM utilisent des images d'OS associées à des VSA et vérifier l'intégrité du démarrage de chaque VM de plan de contrôle.

    Pour effectuer une vérification de l'intégrité des VM, consultez la section Vérifier l'intégrité des VM du plan de contrôle GKE.

Éléments configurables

Bien que GKE gère la plupart du plan de contrôle à votre place, vous pouvez contrôler les éléments suivants:

  • Accès au plan de contrôle: le plan de contrôle comporte deux types de points de terminaison pour l'accès au cluster:

    • Point de terminaison basé sur le DNS
    • Points de terminaison basés sur l'adresse IP

    Par défaut, le serveur d'API Kubernetes utilise une adresse IP externe. Vous pouvez protéger le serveur d'API Kubernetes en activant un point de terminaison basé sur un DNS pour accéder au plan de contrôle. Vous pouvez contrôler qui peut accéder au point de terminaison DNS avec VPC Service Controls, ce qui vous permet de définir un paramètre de sécurité pour toutes les API Google de votre projet. Si vous utilisez des points de terminaison basés sur l'adresse IP pour l'accès au plan de contrôle, nous vous recommandons d'utiliser des réseaux autorisés et de désactiver l'accès sur le point de terminaison externe du plan de contrôle. Pour en savoir plus sur l'isolation réseau, consultez la section À propos de la personnalisation de l'isolation réseau.

  • Authentification: vous pouvez gérer l'authentification du cluster dans GKE en utilisant IAM en tant que fournisseur d'identité. Pour une plus grande sécurité de l'authentification, l'authentification de base et l'émission de certificats clients sont désactivées par défaut.

  • Rotation des identifiants: effectuez régulièrement une rotation des identifiants pour votre autorité de certification (CA) de cluster et vos certificats TLS. GKE effectue également une rotation de l'adresse IP de votre serveur d'API Kubernetes au cours de ce processus. Pour en savoir plus, consultez la section Rotation des identifiants.

De plus, si votre organisation applique des exigences strictes de conformité ou de règles liées au plan de contrôle, la GKE control plane authority est un ensemble de fonctionnalités qui vous offre une visibilité et un contrôle améliorés sur des aspects spécifiques du plan de contrôle, y compris les suivants:

  • Exécutez vos propres autorités de certification et clés pour l'émission d'identités à l'aide de Cloud KMS et du service d'autorité de certification.
  • Chiffrez les disques de démarrage d'etcd et du plan de contrôle à l'aide de vos propres clés dans Cloud KMS.

Pour en savoir plus sur les raisons d'utiliser ces fonctionnalités et sur toutes les fonctionnalités disponibles, consultez la section À propos de l'autorité du plan de contrôle GKE.

Étapes suivantes