Sécurité

Cette page décrit les fonctionnalités de sécurité incluses dans les clusters Anthos sur AWS (GKE On-Prem), y compris chaque couche de son infrastructure, et explique comment les configurer en fonction de vos besoins.

Présentation

Les clusters Anthos sur AWS offrent 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 des clusters Anthos sur AWS, vous acceptez de prendre certaines responsabilités pour vos clusters. Pour plus d'informations, consultez la page Responsabilités partagées des clusters Anthos.

Authentification et autorisation

Vous vous authentifiez auprès d'un cluster utilisateur Anthos sur AWS via l'une 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 optimiser davantage votre stratégie d'authentification et d'autorisation pour Kubernetes Engine, les clusters Anthos sur AWS désactivent l'ancien contrôle d'accès basé sur les attributs (ABAC).

Chiffrement

Par défaut, les clusters Anthos sur AWS chiffrent 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. Il est plus sûr de stocker des données sensibles dans des secrets que dans des ConfigMaps en texte brut ou dans des spécifications de 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

Les clusters Anthos sur AWS peuvent utiliser Hashicorp Vault pour sécuriser les secrets sur vos clusters d'utilisateurs. Pour en savoir plus, consultez la section Utiliser HashiCorp Vault sur les clusters Anthos 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 les clusters Anthos sur AWS, les administrateurs locaux gèrent les composants du plan de contrôle.

Dans les clusters Anthos sur AWS, les composants du plan de contrôle s'exécutent sur AWS. Vous pouvez protéger les clusters Anthos sur le serveur d'API AWS en utilisant des groupes de sécurité AWS et des LCA réseau.

Toutes les communications dans les clusters Anthos 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 les clusters Anthos sur AWS est gérée par des certificats et des 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

Les clusters Anthos sur AWS déploient 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 les clusters Anthos sur AWS.

Ubuntu

Les clusters Anthos sur AWS utilisent 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 les clusters Anthos sur AWS mettent 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 des clusters Anthos 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.

Étapes suivantes