Sécurité du plan de contrôle

Ce document explique comment Google Kubernetes Engine (GKE) sécurise les composants de votre plan de contrôle

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 etcd 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 compte de service géré par Google nommé l'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 etcd

Dans Google Cloud, le contenu client est chiffré au niveau de la couche du système de fichiers par défaut. Ainsi, les disques qui hébergent le stockage etcd pour les clusters GKE sont chiffrés de la même manière. Pour en savoir plus, consultez la page Chiffrement au repos.

etcd écoute deux ports TCP. Le port 2379 est destiné aux clients etcd, comme le serveur d'API Kubernetes. Ce port est lié à l'interface réseau de bouclage local, il n'est donc accessible que depuis la machine virtuelle qui exécute le serveur d'API Kubernetes. Le port 2380 est, quant à lui, destiné à la communication entre serveurs. Le trafic sur ce port est chiffré par TLS mutuel. Autrement dit, chaque serveur doit prouver son identité à l'autre. Dans un cluster régional, la communication entre les serveurs etcd pour établir un quorum est chiffrée par TLS mutuel.

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. Chaque cluster comporte également sa propre autorité de certification pour etcd et les clés racines de cette dernière 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. Pour en savoir plus, consultez la page Confiance dans les clusters.

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.

Les journaux d'audit sont activés par défaut pour les clusters créés depuis la version 1.8.3 de GKE Ils fournissent un enregistrement détaillé, disponible dans Google Cloud Observability, des appels passés au serveur d'API Kubernetes. Vous pouvez afficher les entrées de journal dans l'explorateur de journaux de Google Cloud Console. Vous pouvez également afficher et analyser ces journaux à l'aide de BigQuery.

Éléments configurables

Par défaut, le serveur d'API Kubernetes utilise une adresse IP publique. Vous pouvez protéger le serveur d'API Kubernetes à l'aide des réseaux autorisés et des clusters privés, qui vous permettent d'attribuer une adresse IP privée au serveur d'API Kubernetes et de désactiver l'accès à l'adresse IP publique.

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 pour les clusters créés avec GKE 1.12 et versions ultérieures.

Vous pouvez améliorer la sécurité de votre plan de contrôle en effectuant régulièrement une rotation des identifiants. Lorsque la rotation des identifiants est lancée, les certificats TLS et l'autorité de certification du cluster font automatiquement l'objet d'une rotation. GKE effectue également une rotation de l'adresse IP de votre serveur d'API Kubernetes. Pour en savoir plus, consultez les pages Contrôle d'accès basé sur les rôles (RBAC) et Rotation des identifiants.