Sécurité

Cette page décrit les fonctionnalités de sécurité incluses dans GKE sur AWS, y compris chaque couche de son infrastructure, et explique comment les configurer suivant vos besoins.

Présentation

GKE sur AWS offre plusieurs fonctionnalités permettant de sécuriser vos charges de travail, y compris le contenu de votre image de conteneur, l'environnement d'exécution du conteneur, le réseau du cluster et l'accès au serveur d'API du cluster.

Il est préférable d'adopter une approche multicouche pour protéger vos clusters et vos charges de travail. Vous pouvez appliquer le principe du moindre privilège au niveau d'accès que vous accordez à vos utilisateurs et à vos charges de travail. Vous devrez peut-être faire des compromis pour offrir le bon niveau de flexibilité et de sécurité.

Responsabilités partagées

Lorsque vous utilisez GKE sur AWS, vous acceptez de prendre certaines responsabilités pour vos clusters. Pour en savoir plus, consultez la page Responsabilités partagées des clusters GKE.

Authentification et autorisation

Vous pouvez vous authentifier auprès d'un cluster d'utilisateur GKE sur AWS à l'aide des méthodes suivantes :

Pour configurer un accès plus précis aux ressources Kubernetes au niveau du cluster ou dans les espaces de noms Kubernetes, utilisez le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. Le contrôle RBAC vous permet de créer des stratégies détaillées qui définissent les opérations et les ressources auxquelles les utilisateurs et les comptes de service peuvent accéder. Avec RBAC, vous pouvez contrôler l'accès pour toute identité validée fournie.

Pour simplifier et rationaliser davantage votre stratégie d'authentification et d'autorisation pour Kubernetes Engine, GKE sur AWS désactive l'ancien contrôle d'accès basé sur les attributs (ABAC).

Chiffrement

Par défaut, GKE sur AWS chiffre les données dans etcd au repos, les volumes EBS, les secrets Kubernetes et les composants du plan de contrôle avec le service de gestion des clés AWS (KMS).

Pour chiffrer des données sensibles dans vos clusters d'utilisateurs, vous pouvez utiliser l'une des méthodes suivantes :

Secrets Kubernetes

Les ressources Secrets Kubernetes servent à stocker, au sein de vos clusters, des données sensibles telles que les mots de passe, les jetons OAuth et les clés SSH. Le stockage des données sensibles dans des secrets est plus sécurisé que le stockage sous format texte brut dans ConfigMaps ou dans les spécifications d'un pod. L'utilisation de secrets vous permet de contrôler l'utilisation des données sensibles et réduit le risque d'exposition des données à des utilisateurs non autorisés.

HashiCorp Vault

GKE sur AWS peut utiliser HashiCorp Vault pour sécuriser des secrets sur vos clusters d'utilisateur. Pour en savoir plus, consultez la section Utiliser HashiCorp Vault sur GKE sur AWS.

Sécurité du plan de contrôle

Les composants du plan de contrôle incluent le service de gestion, le serveur d'API Kubernetes, le programmeur, les contrôleurs et la base de données etcd du cluster d'utilisateur. Dans GKE sur AWS, les administrateurs locaux gèrent les composants du plan de contrôle.

Dans GKE sur AWS, les composants du plan de contrôle s'exécutent sur AWS. Vous pouvez protéger GKE sur le serveur d'API AWS à l'aide de groupes de sécurité AWS et de LCA réseau.

Toutes les communications dans GKE sur AWS sont effectuées via des canaux Transport Layer Security (TLS), régis par les autorités de certification suivantes :

  • L'autorité de certification etcd sécurise la communication du serveur d'API vers les instances dupliquées etcd, ainsi que le trafic entre les instances dupliquées etcd. Cette autorité de certification est autosignée.
  • L'autorité de certification du cluster d'utilisateur sécurise la communication entre le serveur d'API et tous les clients internes de l'API Kubernetes (kubelets, contrôleurs, programmeurs). Cette autorité de certification est chiffrée par KMS.
  • L'autorité de certification du service de gestion est chiffrée par AWS KMS. Elle est créée lorsque vous exécutez anthos-gke init et stockée dans votre espace de travail Terraform. Lorsque vous utilisez terraform apply pour créer le service de gestion, la clé de l'autorité de certification est transmise en tant qu'informations sur l'utilisateur AWS EC2 et déchiffrée par AWS KMS au démarrage du cluster.

Pour le service de gestion, les clés du plan de contrôle sont stockées sur le nœud du plan de contrôle [nodes]{:.external}. Pour les clusters d'utilisateur, les clés sont stockées en tant que secrets Kubernetes dans le plan de contrôle du service de gestion.

L'authentification par cluster dans GKE sur AWS est gérée par les certificats et les jetons de support de compte de service. En tant qu'administrateur, vous vous authentifiez auprès du plan de contrôle à l'aide du certificat d'administration du service de gestion, que vous utilisez pour la création initiale de la liaison de rôles ou en cas d'urgence.

La rotation des certificats s'effectue de la manière suivante :

Sécurité des nœuds

GKE sur AWS déploie vos charges de travail sur des pools de nœuds des instances AWS EC2. Les sections suivantes expliquent comment utiliser les fonctionnalités de sécurité au niveau du nœud dans GKE sur AWS.

Ubuntu

GKE sur AWS utilise une version optimisée d'Ubuntu comme système d'exploitation sur lequel exécuter le plan de contrôle et les nœuds Kubernetes. Ubuntu inclut un ensemble complet de fonctionnalités de sécurité modernes, et GKE sur AWS met en œuvre plusieurs fonctionnalités de sécurité pour les clusters, y compris les suivantes :

  • Un ensemble de packages optimisé.
  • Un noyau Linux adapté à Google Cloud
  • Des comptes utilisateur limités et une connexion racine désactivée

Des guides de sécurité supplémentaires sont disponibles pour Ubuntu, tels que :

Mises à niveau de nœuds

Vous devez mettre à niveau vos nœuds régulièrement. De temps en temps, des problèmes de sécurité liés à l'exécution du conteneur, à Kubernetes lui-même ou au système d'exploitation du nœud peuvent vous obliger à mettre à niveau vos nœuds plus rapidement. Lorsque vous mettez à niveau votre cluster d'utilisateur, la dernière version du logiciel de chaque nœud est également installée. En outre, la mise à niveau des nœuds alterne les identifiants de chiffrement.

Sécuriser vos charges de travail

Kubernetes permet aux utilisateurs de provisionner, mettre à l'échelle et mettre à jour rapidement des charges de travail basées sur des conteneurs. Cette section décrit les tactiques que vous pouvez utiliser pour limiter les effets secondaires de l'exécution de conteneurs sur un cluster et les services Google Cloud.

Limiter les droits de processus en conteneur du pod

Limiter les droits des processus en conteneur est important pour la sécurité de votre cluster. Vous pouvez définir des options relatives à la sécurité avec le contexte de sécurité des pods et des conteneurs. Ces paramètres vous permettent de modifier les paramètres de sécurité de vos processus, tels que :

  • l'utilisateur et le groupe exécutant le processus ;
  • les capacités Linux disponibles ;
  • Élévation des privilèges

Le système d'exploitation par défaut du nœud GKE sur AWS, Ubuntu, applique les règles de sécurité Docker AppArmor par défaut à tous les conteneurs démarrés par Kubernetes. Vous pouvez consulter le modèle du profil sur GitHub. Entre autres choses, le profil refuse les capacités suivantes aux conteneurs :

  • Écrire dans des fichiers directement dans un répertoire d'ID de processus (/proc/)
  • Écrire dans des fichiers qui ne se trouvent pas dans /proc/
  • Écrire dans des fichiers dans /proc/sys autres que /proc/sys/kernel/shm*
  • Installer des systèmes de fichiers.

Étape suivante