Sécurité Kubernetes : RBAC, politiques réseau et sécurité des pods

Kubernetes orchestre des charges de travail conteneurisées à grande échelle, mais sa complexité crée une vaste surface d’attaque. Les principaux composants à sécuriser sont les suivants : le serveur d’API (le plan de contrôle central ; sa compromission permet de contrôler l’ensemble du cluster), etcd (la base de données d’état du cluster ; elle stocke les secrets en base64 et ceux-ci doivent être chiffrés au repos), le kubelet (l’agent du nœud ; l’API kubelet non authentifiée permet d’exécuter arbitrairement des pods), l’environnement d’exécution des conteneurs (Docker/containerd) et le réseau qui relie tous les pods. Les candidats à Security+ doivent comprendre que les mauvaises configurations de Kubernetes figurent parmi les problèmes de sécurité du cloud les plus courants.

Le RBAC (Role-Based Access Control) de Kubernetes contrôle les utilisateurs, les comptes de service et les processus autorisés à effectuer certaines actions sur certaines ressources de l’API. Le modèle comprend quatre objets : Role (autorisations limitées à un espace de noms), ClusterRole (autorisations à l’échelle du cluster), RoleBinding (accorde un Role à un sujet au sein d’un espace de noms) et ClusterRoleBinding (accorde un ClusterRole à un sujet à l’échelle du cluster). Chaque commande kubectl est transformée en appel d’API vérifié par rapport aux règles RBAC. Si RBAC n’est pas configuré, tout utilisateur authentifié (ou compte de service) peut disposer d’un accès administratif.

Chaque pod Kubernetes s’exécute sous un compte de service, une identité utilisée pour l’authentification auprès de l’API. Par défaut, les pods utilisent le compte de service default de leur espace de noms, qui peut disposer d’autorisations étendues. Le principe du moindre privilège exige la création de comptes de service dédiés pour chaque application, avec uniquement les autorisations dont elle a besoin. De plus, la définition de automountServiceAccountToken: false sur les pods qui n’ont pas besoin d’accéder à l’API empêche le montage du jeton du compte de service dans le système de fichiers du pod, où une application compromise pourrait l’utiliser pour effectuer des appels d’API.

Par défaut, dans Kubernetes, tous les pods peuvent communiquer avec tous les autres pods, quel que soit leur espace de noms. Un pod compromis peut immédiatement tenter d’atteindre des bases de données, des API internes et d’autres microservices. Les ressources Kubernetes NetworkPolicy définissent des règles qui limitent le trafic entre pods en fonction des étiquettes, des espaces de noms et des ports. L’approche recommandée consiste à appliquer une politique réseau « refus de tout par défaut » dans chaque espace de noms, puis à ajouter des règles d’autorisation explicites pour les chemins de communication nécessaires. Notez que NetworkPolicy nécessite un plugin CNI qui le prend en charge (Calico, Cilium, Weave) : Kubernetes standard ignore NetworkPolicy sans CNI compatible.

Les Pod Security Standards (PSS), introduites dans Kubernetes 1.23 et stabilisées dans la version 1.25, remplacent la Pod Security Policy (PSP), obsolète, par trois profils intégrés appliqués au niveau de l’espace de noms : Privileged (sans restriction, pour les composants système), Baseline (empêche les escalades de privilèges connues, comme les conteneurs privilégiés et l’accès au réseau de l’hôte) et Restricted (renforcé, exige des utilisateurs non root, supprime toutes les capacités et impose des systèmes de fichiers root en lecture seule). Les espaces de noms sont étiquetés pour imposer un niveau de politique, et les pods qui l’enfreignent sont rejetés lors de l’admission.

Les Secrets Kubernetes stockent des données sensibles telles que des mots de passe, des jetons et des certificats TLS. Par défaut, les Secrets sont stockés dans etcd sous forme de valeurs encodées en base64, et non chiffrées. Toute personne pouvant lire etcd ou disposant d’autorisations RBAC suffisantes peut les décoder très facilement. Les bonnes pratiques incluent : l’activation du chiffrement au repos pour etcd à l’aide d’AES-GCM avec une clé stockée dans un KMS (AWS KMS, GCP KMS), l’intégration avec un gestionnaire de secrets externe comme HashiCorp Vault ou AWS Secrets Manager via le pilote Secrets Store CSI, ainsi que la restriction de l’accès aux Secrets par RBAC afin que seuls les comptes de service qui en ont besoin puissent les lire.

Les contrôleurs d’admission sont des modules du serveur d’API Kubernetes qui interceptent les requêtes d’API après l’authentification et l’autorisation, mais avant la persistance de l’objet, afin de pouvoir valider, modifier ou rejeter ces requêtes. Les contrôleurs d’admission importants pour la sécurité incluent : PodSecurity (impose les Pod Security Standards), ImagePolicyWebhook (permet une vérification externe de la signature des images), AlwaysPullImages (force le téléchargement de nouvelles images afin d’empêcher l’utilisation d’images malveillantes mises en cache localement) et OPA/Gatekeeper (Open Policy Agent ; la solution la plus flexible, qui permet d’exprimer des politiques personnalisées dans le langage Rego afin d’imposer toute règle de sécurité de l’organisation).

Le renforcement de la sécurité des composants du plan de contrôle Kubernetes est essentiel : le serveur d’API doit utiliser --anonymous-auth=false pour désactiver l’accès non authentifié, être configuré avec --audit-log-path afin de consigner toute l’activité de l’API et utiliser TLS pour toutes les connexions. Le kubelet doit utiliser --authorization-mode=Webhook (et non AlwaysAllow), et l’authentification anonyme doit être désactivée. etcd doit utiliser le chiffrement TLS entre pairs et côté client, un accès réseau restreint (il ne doit être accessible que par le serveur d’API) et le chiffrement des données au repos. Le CIS Kubernetes Benchmark fournit une liste de contrôle complète pour les paramètres de tous les composants.

Les espaces de noms Kubernetes assurent une séparation logique des ressources, mais ne constituent pas à eux seuls une frontière de sécurité solide : ils fournissent principalement une isolation organisationnelle. Pour une véritable isolation mutualisée (par exemple, pour les charges de travail de différents clients), des contrôles supplémentaires sont nécessaires : des politiques réseau pour bloquer le trafic entre espaces de noms, des quotas de ressources pour empêcher les attaques par déni de service dues à un voisin bruyant, des groupes de nœuds distincts pour les clients nécessitant une isolation forte ou des clusters dédiés par client. De nombreuses organisations utilisent les Hierarchical Namespaces ou des solutions commerciales comme vCluster pour renforcer la mutualisation au sein d’un même cluster.

Kubernetes journalise les audits en enregistrant chaque requête d’API : son auteur, son origine, l’action demandée et la ressource ciblée. Les journaux d’audit sont essentiels aux investigations judiciaires après un incident de sécurité ainsi qu’à la détection de comportements anormaux, comme des associations de rôles inhabituelles, l’accès à des secrets ou l’exécution de commandes dans des pods de production. Les journaux d’audit doivent être transmis à un SIEM centralisé. Falco assure la surveillance du comportement des conteneurs en cours d’exécution, tandis que les services Kubernetes gérés par les fournisseurs cloud (EKS, GKE, AKS) assurent l’intégration native des journaux d’audit à leurs plateformes de journalisation respectives.

La sécurité de la chaîne d’approvisionnement de Kubernetes garantit que seules des images fiables et vérifiées atteignent la production. Les recommandations de la CNCF en matière de sécurité de la chaîne d’approvisionnement incluent : vérifier les signatures des images avec Cosign avant le déploiement (mesure appliquée par l’intermédiaire des contrôleurs d’admission), générer et vérifier des nomenclatures logicielles pour toutes les images de conteneurs afin d’assurer la traçabilité de la provenance des composants, épingler les images sur des empreintes (myimage@sha256:abc123) plutôt que sur des balises modifiables, et analyser tous les graphiques Helm tiers pour détecter les erreurs de configuration et les vulnérabilités avant le déploiement.

Évaluez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : le RBAC de Kubernetes contrôle l’accès aux API au moyen de rôles, de ClusterRoles et de liaisons — appliquez toujours le principe du moindre privilège aux comptes de service ; les configurations NetworkPolicy avec refus par défaut empêchent les déplacements latéraux entre les pods et les espaces de noms ; et les normes de sécurité des pods imposent le renforcement des conteneurs au niveau de l’espace de noms, en bloquant les conteneurs privilégiés, l’accès au réseau de l’hôte et l’exécution en tant que root. Nous allons maintenant étudier la sécurité de l’informatique sans serveur et les surfaces d’attaque au niveau des fonctions.