Cette page décrit les fonctionnalités de sécurité incluses dans GKE On-Prem, y compris chaque couche de son infrastructure, et explique comment les configurer suivant vos besoins.
Présentation
GKE On-Prem 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 GKE On-Prem à l'aide d'OpenID Connect (OIDC) (via kubectl) ou du 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 davantage et optimiser votre stratégie d'authentification et d'autorisation pour Kubernetes Engine, GKE On-Prem désactive l'ancien contrôle d'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 maintenus par Google, les administrateurs locaux gèrent les composants du plan de contrôle dans GKE On-Prem.
Dans GKE On-Prem, 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 On-Prem 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 On-Prem sont effectuées via des canaux TLS, qui sont régis par trois autorités de certification (CA) : 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'indicateur de nom de serveur (SNI) 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 On-Prem 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 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 :
- 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 On-Prem 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 tirer parti des fonctionnalités de sécurité au niveau des nœuds disponibles dans GKE On-Prem.
Ubuntu
GKE On-Prem 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 On-Prem met en œuvre plusieurs fonctionnalités de sécurité pour les clusters, notamment :
- Un ensemble de packages optimisé
- Un noyau Linux adapté à Google Cloud
- Des mises à jour de sécurité automatiques du système d'exploitation facultatives.
- 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.
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
Pour modifier ces paramètres au niveau du cluster plutôt qu'au niveau du pod ou du conteneur, vous devez créer une ressource PodSecurityPolicy. Les objets PodSecurityPolicy veillent à ce que tous les pods d'un cluster respectent une règle de référence minimale que vous définissez.
Le système d'exploitation par défaut des nœuds GKE On-Prem, 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 GKE On-Prem. Les administrateurs peuvent utiliser les informations consignées pour effectuer des analyses forensiques, pour générer des alertes en temps réel ou pour répertorier la manière dont un parc de clusters Kubernetes Engine est utilisé et par qui.
Par défaut, GKE On-Prem consigne les activités d'administration. Vous pouvez également enregistrer les événements d'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. Intégrée à Cloud IAM et Cloud Audit Logging, la solution Cloud KMS vous permet de gérer les autorisations de 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 GKE On-Prem se connectent en toute sécurité 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.