Sécurité

Cette page décrit les fonctionnalités de sécurité incluses dans Google Distributed Cloud, y compris chaque couche de son infrastructure, et explique comment les configurer en fonction de vos besoins.

Présentation

GKE sur VMware offre plusieurs fonctionnalités pour vous aider à 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 GKE sur VMware à l'aide d'OpenID Connect (OIDC) ou d'un jeton de compte de service Kubernetes via la console Cloud.

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, GKE sur VMware désactive l'ancien contrôle des accès basé sur les attributs (ABAC).

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 et entretenus par Google, les administrateurs locaux gèrent les composants du plan de contrôle dans GKE sur VMware.

Dans GKE sur 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 de GKE sur VMware en utilisant les règles de réseau et les pare-feu de votre entreprise. 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 GKE sur VMware s'effectuent 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 GKE sur VMware 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 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

GKE sur 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 expliquent comment exploiter les fonctionnalités de sécurité au niveau du nœud disponibles dans GKE sur VMware.

Ubuntu

GKE sur 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 ensemble complet de fonctionnalités de sécurité modernes, et GKE sur VMware met en œuvre plusieurs fonctionnalités de sécurité pour les clusters, y compris:

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 sur lesquelles les administrateurs et les utilisateurs peuvent s'appuyer 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 Google Cloud 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

Ubuntu, le système d'exploitation par défaut du nœud GKE sur VMware, 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 permet aux administrateurs de conserver, d'interroger, de traiter et de alerter les événements qui se produisent dans vos environnements GKE sur 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, GKE sur VMware enregistre 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

Si vos clusters et charges de travail GKE sur VMware se connectent en toute sécurité aux services Google Cloud via Cloud VPN, vous pouvez utiliser Cloud Key Management Service (Cloud KMS) pour gérer les clés. 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. Sinon, vous pouvez choisir d'utiliser l'une des alternatives suivantes :

  • Secrets Kubernetes
  • HashiCorp Vault
  • Module HSM Luna network de Thales
  • Module de sécurité matérielle (HSM) de Google Cloud

Secrets Kubernetes

Les ressources Secrets Kubernetes stockent des données sensibles, telles que les mots de passe, les jetons OAuth et les clés SSH, dans vos clusters. Le stockage des données sensibles dans des secrets est plus sécurisé que le stockage sous forme de 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