Version 1.5. Cette version est entièrement compatible avec les derniers correctifs et mises à jour pour corriger les failles et les risques de sécurité ainsi que les problèmes affectant GKE On-Prem. Reportez-vous aux notes de version pour plus de détails. Il ne s'agit pas de la version la plus récente.

Sécurité

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

Présentation

Anthos clusters on VMware offre plusieurs fonctionnalités pour 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é.

Authentification et autorisation

Vous vous authentifiez auprès des clusters Anthos clusters on VMware à l'aide d'OpenID Connect (OIDC) ou d'un jeton de compte de service Kubernetes via Cloud Console

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. RBAC vous permet de créer des stratégies détaillées qui définissent les opérations et les ressources auxquelles vous souhaitez autoriser les utilisateurs et les comptes de service à 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, Anthos clusters on VMware désactive l'ancien contrôle d'accès basé sur les attributs (ABAC).

Pour plus d'informations, consultez la page Préparer un environnement Google Kubernetes Engine pour la production.

Sécurité du plan de contrôle

Les composants du plan de contrôle incluent le serveur d'API Kubernetes, le programmeur, les contrôleurs et la base de données etcd dans laquelle votre configuration Kubernetes est conservée. Alors que dans Kubernetes Engine, les composants du plan de contrôle Kubernetes sont gérés par Google, les administrateurs locaux gèrent les composants du plan de contrôle dans Anthos clusters on VMware.

Dans Anthos clusters on VMware, les composants du plan de contrôle s'exécutent au sein de votre réseau d'entreprise. Vous pouvez protéger le serveur d'API d'Anthos clusters on VMware à l'aide de vos règles de réseau et de pare-feu d'entreprise existantes. Vous pouvez également attribuer une adresse IP privée au serveur d'API et limiter l'accès à l'adresse privée.

Toutes les communications dans Anthos clusters on VMware se font via des canaux TLS, qui sont régis par trois autorités de certification : etcd, cluster et org:

  • 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 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 autosignée.
  • L'autorité de certification "org" est une autorité de certification externe utilisée pour exposer l'API Kubernetes aux utilisateurs externes. Vous gérez cette autorité de certification.

Pour les plans de contrôle d'administrateur, les clés sont stockées sur le nœud du plan de contrôle. Pour les clusters d'utilisateur, les clés sont stockées en tant que secrets Kubernetes dans le plan de contrôle d'administrateur. Le serveur d'API est configuré avec un certificat fourni par l'utilisateur et signé par l'autorité de certification "org". Le serveur d'API utilise l'indication du nom de serveur SNI (Server Name Indication) pour déterminer s'il faut utiliser la clé signée par l'autorité de certification "cluster" ou celle signée par l'autorité de certification "org".

L'authentification par cluster dans Anthos clusters on VMware 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 via OIDC, ou avec le certificat administratif utilisé pour la création de la liaison de rôles initiale ou en cas d'urgence.

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

  • Pour le serveur d'API, les plans de contrôle et les nœuds, des certificats sont créés ou alternés à chaque mise à niveau.
  • Les autorités de certification peuvent faire l'objet d'une rotation, rarement ou à la demande.

Sécurité des nœuds

Anthos clusters on VMware déploie vos charges de travail dans des instances VMware, qui sont associées à vos clusters en tant que nœuds. Les sections suivantes vous expliquent comment exploiter des fonctionnalités de sécurité au niveau du nœud disponibles dans Anthos clusters on VMware.

Ubuntu

Anthos clusters on VMware 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 riche ensemble de fonctionnalités de sécurité modernes, et Anthos clusters on VMware met en œuvre plusieurs fonctionnalités de sécurité pour les clusters, telles que:

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.

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 stratégies que les administrateurs et les utilisateurs peuvent utiliser pour limiter la capacité des conteneurs en cours d'exécution à affecter les autres conteneurs du cluster, les hôtes sur lesquels ils s'exécutent et les services GCP activés dans leur projet.

Limiter les droits de processus en conteneur du pod

Limiter les droits des processus en conteneur est important pour la sécurité globale de votre cluster. Kubernetes Engine vous permet de définir des options liées à la sécurité sur les pods et les conteneurs via le contexte de sécurité. Ces éléments vous permettent de modifier les paramètres de sécurité de vos processus, tels que :

  • Utilisateur et groupe exécutant
  • Capacités Linux disponibles
  • Élévation des privilèges

Le système d'exploitation par défaut du nœud Anthos clusters on VMware, 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 /proc/sys dans des fichiers autres que /proc/sys/kernel/shm*
  • Installer des systèmes de fichiers

Journaux d'audit

La journalisation d'audit Kubernetes offre aux administrateurs un moyen de conserver, d'interroger, de traiter et de notifier les événements qui se produisent dans vos environnements Anthos clusters on VMware. Les administrateurs peuvent utiliser les informations consignées pour effectuer des analyses forensiques, des alertes en temps réel ou pour consigner la manière dont un parc de clusters Kubernetes Engine est utilisé et par qui.

Par défaut, Anthos clusters on VMware consigne l'activité d'administration. Vous pouvez également enregistrer les événements Accès aux données, en fonction des types d'opérations que vous souhaitez inspecter.

L'agent Connect ne communique qu'avec le serveur d'API local qui s'exécute sur site, et chaque cluster doit posséder son propre ensemble de journaux d'audit. Toutes les actions effectuées par les utilisateurs à partir de l'interface utilisateur via Connect sont enregistrées par ce cluster.

Chiffrement

Cloud Key Management Service (Cloud KMS) est un service de gestion de clés hébergé dans le cloud qui vous permet de gérer les clés cryptographiques de vos services. Vous pouvez générer, utiliser, alterner et détruire des clés cryptographiques AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 et EC P384. Cloud KMS est intégré à Cloud IAM (Cloud Identity and Access Management) et Cloud Audit Logging pour vous permettre de gérer les autorisations sur des clés individuelles et de surveiller leur utilisation. Utilisez Cloud KMS pour protéger les secrets et autres données sensibles que vous devez stocker.

Si vos clusters et charges de travail Anthos clusters on VMware se connectent de manière sécurisée aux services Google Cloud via Cloud VPN, vous pouvez utiliser Cloud KMS pour la gestion des clés. Sinon, vous pouvez choisir d'utiliser l'une des alternatives suivantes :

  • Secrets Kubernetes
  • HashiCorp Vault
  • Module de sécurité matérielle (HSM)

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

Module de sécurité matérielle