Sécurité du plan de contrôle

Ce document décrit comment les composants du plan de contrôle de cluster sont sécurisés dans Google Kubernetes Engine.

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, etcd et un certain nombre de 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 de la 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.

L'authentification sur le serveur d'API Kubernetes et sur etcd s'effectue de la même manière que pour les autres services Google Cloud. Ces communications sont protégées par l'Application-layer Transport Security (ALTS).

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é relative à etcd

Dans Google Cloud Platform, le contenu client est chiffré au niveau de la couche du système de fichiers par défaut. Donc, les disques qui hébergent le stockage etcd pour les clusters GKE le sont également. 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 l'analyse des failles de Container Registry 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. De plus, Google fait 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 et fournissent un enregistrement détaillé, disponible dans Stackdriver, des appels passés au serveur d'API Kubernetes. Vous pouvez afficher les entrées de journal sur la page Journaux de la console GCP. 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 maîtres 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 Cloud IAM en tant que fournisseur d'identité. Prenez soin de désactiver l'authentification de base en laissant vides les champs de nom d'utilisateur et de mot de passe pour la configuration de MasterAuth. Dans la même configuration, vous pouvez également désactiver le certificat client, ce qui garantit que vous avez une clé de moins à prendre en compte lors du verrouillage de l'accès à votre cluster.

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 des accès basé sur les rôles et Rotation des identifiants.

Étapes suivantes

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

Envoyer des commentaires concernant…

Documentation Kubernetes Engine