La sécurité est l’un des principaux défis de Kubernetes en raison de la complexité et de la vulnérabilité de sa configuration. Les services de conteneurs gérés tels que Google Kubernetes Engine (GKE) offrent de nombreuses fonctionnalités de protection, mais ne vous déchargent pas de toutes les responsabilités connexes. Lisez la suite pour en savoir plus sur la sécurité de GKE et les bonnes pratiques pour sécuriser votre cluster.
Présentation de base de la sécurité GKE
GKE protège votre charge de travail sur plusieurs couches, notamment votre image de conteneur, son environnement d’exécution, le réseau du cluster et l’accès au serveur d’API du cluster.
C’est pourquoi Google recommande une approche en couches pour protéger vos clusters et vos charges de travail. Permettre au bon niveau de flexibilité et de sécurité pour votre organisation de déployer et de maintenir des charges de travail peut nécessiter différents compromis, car certains paramètres peuvent être trop contraignants.
Les aspects les plus critiques de la sécurité de GKE impliquent les éléments suivants :
- Authentification et autorisation;
- Sécurité du plan de contrôle, y compris les composants et la configuration ;
- Sécurité des nœuds ;
- Sécurité Internet.
Ces éléments sont également reflétés dans les Benchmarks CIS, qui aident à structurer le travail autour des configurations de sécurité pour Kubernetes.
Pourquoi les benchmarks CIS sont-ils cruciaux pour la sécurité GKE ?
La gestion de la configuration de sécurité de K8 n’est pas exactement une promenade dans le parc.
L’état de Kubernetes et de la sécurité des conteneurs de Red Hat 2022 a révélé que près d’un problème grave sur quatre était une vulnérabilité pouvant être corrigée. Près de 70 % des incidents sont dus à des erreurs de configuration.
Depuis leur publication par le Center of Internet Security (CIS), les Benchmarks sont devenus les meilleures pratiques mondialement reconnues pour la mise en œuvre et la gestion des mécanismes de cybersécurité.
Le CIS Kubernetes Benchmark implique des recommandations pour la configuration de K8 qui prennent en charge une posture de sécurité solide. Écrit pour la distribution open-source Kubernetes, il vise à être aussi universellement applicable que possible.
Analyse comparative CIS GKE en pratique
Avec un service géré tel que GKE, tous les éléments du benchmark CIS ne sont pas sous votre contrôle.
C’est pourquoi il existe des recommandations que vous ne pouvez pas vérifier ou modifier directement par vous-même. Celles-ci impliquent :
- Le plan de contrôle ;
- La distribution Kubernetes ;
- Le système d’exploitation des nœuds.
Cependant, vous devez toujours vous occuper de la mise à niveau des nœuds qui exécutent vos charges de travail et, bien sûr, des charges de travail elles-mêmes. Vous devez auditer et corriger toutes les recommandations concernant ces composants.
Vous pouvez le faire manuellement ou utiliser un outil qui gère l’analyse comparative CIS. Avec le module de sécurité des conteneurs de CAST AI, par exemple, vous pouvez obtenir un aperçu des écarts de référence quelques minutes après la connexion de votre cluster.
La plate-forme hiérarchise également les problèmes qu’elle identifie, afin que vous sachiez quels éléments doivent être corrigés en premier. Lors de l’analyse de votre cluster, vous le comparez également aux bonnes pratiques du secteur, afin de mieux évaluer votre état de sécurité global et de planifier un renforcement supplémentaire de GKE.
Les 10 meilleures stratégies pour garantir la sécurité de GKE
1. Appliquer le principe du moindre privilège
Ce principe de sécurité de base consiste à n’accorder à un compte d’utilisateur que les privilèges essentiels pour exécuter la fonction prévue.
Il vient dans CIS GKE Benchmark 6.2.1 : Préfère ne pas exécuter les clusters GKE à l’aide du compte de service par défaut de Compute Engine.
Par défaut, vos nœuds ont accès au compte de service Compute Engine. Son large accès le rend utile pour plusieurs applications, mais il dispose également de plus d’autorisations que nécessaire pour exécuter votre cluster GKE. C’est pourquoi vous devez créer et utiliser un compte de service à privilèges minimaux au lieu de celui par défaut – et faire de même dans d’autres contextes également.
2. Utiliser RBAC pour renforcer l’authentification et l’autorisation
GKE prend en charge plusieurs options pour gérer l’accès à vos clusters avec le contrôle d’accès basé sur les rôles (RBAC).
RBAC permet un accès plus granulaire aux ressources Kubernetes au niveau du cluster et de l’espace de noms, mais il vous permet également de créer des politiques d’autorisation détaillées.
CIS GKE Benchmark 6.8.4 souligne la nécessité de privilégier le RBAC par rapport à l’ancien contrôle d’accès basé sur les attributs (ABAC).
Un autre benchmark CIS GKE (6.8.3) recommande d’utiliser des groupes pour gérer les utilisateurs, car cela simplifie le contrôle des identités et des autorisations. Il supprime également la nécessité de mettre à jour la configuration RBAC chaque fois que des utilisateurs sont ajoutés ou supprimés du groupe.
3. Améliorez la sécurité de votre plan de contrôle
Dans le cadre du modèle de responsabilité partagée, Google gère pour vous les composants du plan de contrôle GKE. Cependant, vous restez responsable de la sécurisation de vos nœuds, conteneurs et pods.
Par défaut, le serveur d’API Kubernetes utilise une adresse IP publique. Vous pouvez le protéger en utilisant des réseaux autorisés et des clusters privés, qui vous permettent d’attribuer une adresse IP privée.
Vous pouvez également améliorer la sécurité de votre plan de contrôle en effectuant une rotation régulière des informations d’identification. Lorsque vous lancez le processus, les certificats TLS et l’autorité de certification du cluster sont automatiquement alternés.
4. Mettez régulièrement à niveau votre infrastructure GKE
Kubernetes publie fréquemment de nouvelles fonctionnalités de sécurité et de nouveaux correctifs. Par conséquent, la mise à jour de vos K8 est l’un des moyens les plus simples d’améliorer votre posture de sécurité.
GKE corrige et met automatiquement à niveau les plans de contrôle pour vous. La mise à niveau automatique des nœuds met également automatiquement à niveau les nœuds de votre cluster. CIS GKE Benchmark 6.5.3 recommande de conserver ce paramètre activé.
Si, pour une raison quelconque, vous devez désactiver la mise à niveau automatique, Google vous conseille d’effectuer des mises à niveau tous les mois et de suivre les bulletins de sécurité GKE pour les correctifs critiques.
5. Protégez les métadonnées des nœuds
Les benchmarks CIS GKE 6.4.1 et 6.4.2 font référence à deux facteurs critiques compromettant la sécurité de votre nœud, qui relève toujours de votre responsabilité.
Les points de terminaison du serveur de métadonnées Compute Engine v0.1 et v1beta1 ont été obsolètes et arrêtés en 2020, car ils n’appliquaient pas les en-têtes de requête de métadonnées.
Certaines attaques contre Kubernetes reposent sur l’accès au serveur de métadonnées de la machine virtuelle pour extraire les informations d’identification. Vous pouvez empêcher ces attaques avec l’identité de la charge de travail ou la dissimulation des métadonnées.
6. Désactiver le tableau de bord Kubernetes
Il y a quelques années, le monde a été électrifié par la nouvelle d’attaquants accédant aux ressources cloud de Tesla et les utilisant pour exploiter la crypto-monnaie. Le vecteur d’attaque, dans ce cas, était un tableau de bord Kubernetes, qui était exposé au public sans authentification ni privilèges élevés.
Il est recommandé de se conformer à CIS GKE Benchmark 6.10.1 si vous souhaitez éviter de suivre le sort de Tesla. Cette norme indique clairement que vous devez désactiver l’interface utilisateur Web Kubernetes lors de l’exécution sur GKE.
Par défaut, GKE 1.10 et versions ultérieures désactivent le tableau de bord K8. Vous pouvez également utiliser le code suivant :
gcloud container clusters update CLUSTER_NAME \
--update-addons=KubernetesDashboard=DISABLED7. Suivez le cadre NSA-CISA
CIS Kubernetes Benchmark vous offre une base solide pour créer un environnement d’exploitation sécurisé. Mais si vous voulez aller plus loin, faites de la place pour NSA-CISA Kubernetes Hardening Guidance dans vos procédures de sécurité.
Le rapport NSA-CISA décrit les vulnérabilités au sein d’un écosystème Kubernetes et recommande les meilleures pratiques pour configurer votre cluster pour la sécurité.
Il présente des recommandations sur l’analyse des vulnérabilités, l’identification des erreurs de configuration, l’audit des journaux et l’authentification, vous aidant à vous assurer que vous répondez de manière appropriée aux défis de sécurité courants.
8. Améliorez la sécurité de votre réseau
La plupart des charges de travail exécutées dans GKE doivent communiquer avec d’autres services exécutés à l’intérieur et à l’extérieur du cluster. Cependant, vous pouvez contrôler le trafic autorisé à transiter par vos clusters.
Tout d’abord, vous pouvez utiliser des stratégies réseau pour limiter la communication pod à pod. Par défaut, tous les pods de cluster sont accessibles sur le réseau via leur adresse IP de pod. Vous pouvez verrouiller la connexion dans un espace de noms en définissant le trafic passant par vos pods et en l’arrêtant pour ceux qui ne correspondent pas aux étiquettes configurées.
Deuxièmement, vous pouvez équilibrer vos pods Kubernetes avec un équilibreur de charge réseau. Pour ce faire, vous créez un service LoadBalancer correspondant aux libellés de votre pod. Vous disposerez d’un mappage IP externe vers les ports de vos pods Kubernetes et vous pourrez filtrer le trafic autorisé au niveau du nœud avec kube-proxy.
9. Sécuriser l’accès des pods aux ressources Google Cloud
Vos conteneurs et pods peuvent avoir besoin d’accéder à d’autres ressources dans Google Cloud. Il existe trois façons de procéder : avec l’identité de la charge de travail, le compte de service de nœud et la clé JSON du compte de service.
L’option la plus simple et la plus sécurisée pour accéder aux ressources Google Cloud consiste à utiliser Workload Identity. Cette méthode permet à vos pods exécutés sur GKE d’obtenir des autorisations sur le compte de service Google Cloud.
Vous devez utiliser des comptes de service Google Cloud spécifiques aux applications pour fournir des informations d’identification afin que les applications disposent des autorisations nécessaires minimales que vous pouvez révoquer en cas de compromission.
10. Obtenez un gestionnaire de secrets configuré par GKE
Benchmark CIS GKE 6.3.1. recommande de chiffrer les secrets Kubernetes à l’aide de clés gérées dans Cloud KMS.
Google Kubernetes Engine vous propose plusieurs options de gestion des secrets. Vous pouvez utiliser les secrets Kubernetes de manière native dans GKE, mais vous pouvez également les protéger au niveau d’une couche d’application avec une clé que vous gérez et un chiffrement secret au niveau de la couche d’application.
Il existe également des gestionnaires de secrets comme Hashicorp Vault, qui offrent un moyen cohérent et prêt pour la production de gérer les secrets dans GKE. Assurez-vous de vérifier vos options et de choisir une solution optimale.
Évaluer la sécurité de GKE en quelques minutes
L’écosystème Kubernetes ne cesse de croître, mais ses défis de configuration de la sécurité le sont également. Si vous souhaitez maîtriser la sécurité des conteneurs GKE, vous devez être en mesure d’identifier les menaces potentielles et de les suivre efficacement.
Les rapports de sécurité Kubernetes vous permettent d’analyser votre cluster GKE par rapport au benchmark CIS, au framework NSA-CISA et à d’autres bonnes pratiques de sécurité des conteneurs pour identifier les vulnérabilités, repérer les erreurs de configuration et les hiérarchiser. Il ne faut que quelques minutes pour obtenir un aperçu complet de la posture de sécurité de votre cluster.