Qu'est-ce que la sécurité Kubernetes ?

L'importance de la sécurité de Kubernetes

En tant que principale plateforme d'orchestration d'applications conteneurisées dans des environnements de clouds publics et privés, Kubernetes est devenu une cible majeure pour les cybercriminels. Kubernetes est au cœur des flux de travail modernes de DevOps, permettant aux équipes d'automatiser et de faire évoluer application déploiement sans se soucier de l'infrastructure sous-jacente ou de la complexité de la gestion des ressources. 

Cependant, la complexité de Kubernetessignifie également qu'il est facile d'introduire et d'ignorer des vulnérabilités ou des configurations erronées qui pourraient exposer des applications critiques pour l'entreprise. Si Kubernetes n'est pas correctement sécurisé, les attaquants peuvent compromettre les charges de travail critiques, exfiltrer des données sensibles, voire mettre hors service des services essentiels.

Par conséquent, les organisations ont besoin de pratiques de sécurité Kubernetes qui protègent la plateforme et ses composants fondamentaux :

• Groupement : L'environnement global qui contient tous les composants de Kubernetes. Il se compose d'un plan de contrôle qui gère la grappe et d'un ensemble de nœuds de travail où les applications sont exécutées.
• Nodes: Machines, virtuelles ou physiques, qui exécutent des charges de travail conteneurisées. Chaque nœud comprend un kubelet qui communique avec le plan de contrôle, un kube-proxy qui gère les règles de mise en réseau et un conteneur d'exécution.
• Cosse : Les nœuds exécutent les charges de travail emballées dans des pods, la plus petite unité déployable de Kubernetes qui encapsule un ou plusieurs conteneurs partageant le stockage, l'espace de noms réseau et la configuration.
• Composants du plan de contrôle : Gère l'état et les opérations du cluster. Ses principaux composants sont le serveur API et un planificateur qui affecte les pods aux nœuds.

Également connue sous le nom de k8s Security, la sécurité de Kubernetes englobe un large éventail de mesures de sécurité conçues pour protéger ces composants. Pour y parvenir, les organisations doivent adopter une stratégie de sécurité proactive et multicouche afin de surveiller en permanence les menaces du site Kubernetes, d'atténuer les attaques et de garantir la conformité aux normes réglementaires. Le site Kubernetes devenant la base de la plupart des infrastructures en nuage, il est indispensable de garantir sa sécurité pour assurer la continuité et la réussite de l'entreprise.

Kubernetes Sécurité pour chaque phase du cycle de vie de l'application

Pour garantir une sécurité robuste des k8s, il est essentiel d'aborder les problèmes de sécurité à chaque phase du cycle de vie de l'application. La sécurité n'est pas seulement une considération post-déploiement ; elle doit être intégrée à chaque étape du processus de développement. 

Vous trouverez ci-dessous les mesures de sécurité essentielles pour chaque phase :

#1. Phase de développement

La phase de développement et de conception est la première ligne de défense en matière de sécurité Kubernetes. À ce stade, les développeurs doivent se concentrer sur la création d'une application et d'une architecture sûres, capables de résister à des attaques potentielles. Cela implique de protéger l'intégrité de l'environnement de développement, de concevoir l'application en gardant la sécurité à l'esprit dès le départ et de mettre en œuvre des pratiques de codage sécurisées. 

Les principales mesures de sécurité à prendre en compte sont les suivantes :

• Adopter une architecture de confiance zéro pour valider chaque demande d'accès.
• Développez un processus d'examen du code et assurez-vous que le code de application est exempt de vulnérabilité.
• Appliquez des processus de gestion des secrets sécurisés pour traiter les données sensibles (mots de passe, clés API, jetons OAuth, etc.) de manière appropriée.

#2. Phase de distribution

Au cours de la phase de distribution, vous devez examiner la chaîne d'approvisionnement du site applicationet vous assurer que les images et les autres composants sont sécurisés et mis à jour, sans vulnérabilité connue. 

To achieve this, you should:

• Analysez toutes les images des conteneurs pour vérifier la vulnérabilité.
• Restreignez l'accès aux images des conteneurs afin d'empêcher tout accès et toute manipulation non autorisés.
• Mettez à jour toutes les dépendances et développez des processus de gestion des correctifs pour obtenir les nouvelles mises à jour le plus rapidement possible.

#3. Phase de déploiement

La phase de déploiement est celle où l'application est introduite dans le cluster Kubernetes. Garantir la sécurité au cours de cette phase implique de configurer l'environnement Kubernetes de manière sécurisée et de gérer le processus de déploiement afin de minimiser le risque d'exposition à la vulnérabilité. 

Les pratiques de déploiement en toute sécurité à prendre en compte sont les suivantes

• Restreindre application déploiement à des utilisateurs et des environnements spécifiques.
• Analyse des images de conteneurs pour vérifier l'identité cryptographique afin de s'assurer que la signature est valide, qu'elle provient d'un éditeur de confiance et que l'artefact n'a pas été modifié.
• Déployez l'application et le cluster dans des espaces de noms distincts.

#4. Phase d'exécution

Sécurité de l’exécution Kubernetes se concentre sur la phase opérationnelle, où l'application fonctionne au sein du cluster. La phase d'exécution nécessite une surveillance continue et des capacités de réponse aux incidents afin de limiter l'impact des incidents de sécurité, ainsi que des mises à jour permanentes pour maintenir l'environnement sécurisé. 

Il peut être divisé en trois domaines principaux :

• Accès : Protéger l'API Kubernetes avec un contrôle d'accès robuste, des processus d'authentification et le chiffrement de tout le trafic de l'API.
• Calculer : Choisissez un moteur d'exécution de conteneur qui offre un haut niveau de sécurité et trouve un équilibre entre l'isolation de l'application et son exécution sur le même hôte.
• Stockage : Cryptez les clusters et les objets API au repos, authentifiez les connexions entre les clusters et le stockage, et utilisez les sauvegardes de manière à pouvoir les restaurer en cas de besoin.

Les 4C de la sécurité Kubernetes

Pour sécuriser efficacement Kubernetes contre les menaces, abordez la sécurité sous l'angle du modèle des 4C. Le modèle des 4C ( code, conteneur, cluster et sécurité du nuage ) est une feuille de route pour répondre aux problèmes de sécurité au sein de l'architecture Kubernetes.

Sécurité des programmes codés

Le code fait référence à l'application exécutée par les conteneurs. Le code présente une surface d'attaque importante dans les environnements Kubernetes, non seulement en raison de l'introduction involontaire de bogues entraînant une vulnérabilité, mais aussi en raison de bibliothèques tierces potentiellement vulnérables.

Pour sécuriser le code s'exécutant sur la plateforme Kubernetes, commencez par empêcher l'accès non autorisé au code avec une sécurité réseau de base et des contrôles d'accès comme première ligne de défense. Mettez en œuvre des pratiques de codage sécurisées, effectuez des analyses et des tests réguliers à l'aide d'outils spécialisés et respectez les directives de codage de l'OWASP.

Sécurité des conteneurs

Les conteneurs contiennent des images, elles-mêmes constituées de l'image de base, du système d'exploitation, de la configuration du conteneur, des dépendances et du temps d'exécution nécessaires à l'exécution du code de l'application.

Les conteneurs exécutés dans des pods doivent utiliser des images de base et des environnements d'exécution dignes de confiance, chacun pouvant être ciblé par des acteurs malveillants. Vérifiez que le référentiel d'images d'origine est sécurisé, réduisez la base de code pour limiter le nombre de bibliothèques tierces utilisées, analysez les images des conteneurs pour détecter les vulnérabilités et sécurisez les pods avec des contrôles d'accès et des politiques de réseau pour restreindre la communication entre les pods.

Sécurité des clusters

L'architecture Kubernetes est organisée en clusters. Les clusters Kubernetes sont constitués de pods, et chaque pod contient un ou plusieurs conteneurs fonctionnant sur le même réseau local. La conception de la sécurité des clusters repose sur une conception minutieuse des politiques d'accès et des configurations de sécurité.

La sécurité des clusters implique de sécuriser les conteneurs et les applications qui s'y exécutent, le plan de contrôle ( API, le planificateur, le magasin de données et les contrôleurs) et le réseau plus large dans lequel le cluster s'exécute.

Sécurité du cloud

La couche "nuage" est le centre de données physique ou l'infrastructure "nuage" qui exécute Kubernetes, généralement des plateformes d'infrastructure en tant que code (IaC) ou des services gérés Kubernetes.

Cloud proposent des lignes directrices et des meilleures pratiques de sécurité pour mettre en œuvre des contrôles d'accès appropriés. Réduisez les risques pour l'infrastructure en nuage en mettant en œuvre des procédures de moindre privilège sur les ressources, en recherchant les vulnérabilités ou les mauvaises configurations de l'infrastructure en nuage et en mettant en place des contrôles d'accès pour limiter les utilisateurs qui peuvent interagir avec Kubernetes.

En règle générale, les administrateurs peuvent s'attendre à mettre en œuvre des mesures de sécurité à toutes les étapes du cycle de vie de l'application : du codage et des tests initiaux au déploiement de la production, en passant par les opérations courantes au sein de la grappe.

Principes clés de la sécurité de Kubernetes

Les principes et contre-mesures de sécurité suivants peuvent contribuer à garantir la résilience des applications conteneurisées fonctionnant sur Kubernetes:

Role-Based Access Control (RBAC)

Dans Kubernetes, le RBAC contrôle l'accès aux ressources au sein du cluster et définit les actions qu'un utilisateur ou un groupe est autorisé ou non à effectuer. Le RBAC est utilisé pour isoler l'accès des équipes, restreindre les opérations, contrôler l'accès des administrateurs et gérer les autorisations des comptes de service.

Les rôles sont utilisés pour accorder l'accès aux ressources au sein d'un seul espace de noms, tandis que les rôles de grappes ont une portée plus large et définissent l'accès à travers les espaces de noms. Il est évident que tous les utilisateurs ne doivent pas avoir un accès total et illimité à toutes les ressources. Lors de l'évaluation des rôles et des autorisations Kubernetes, référez-vous au principe du moindre privilège (PoLP) en tant que ligne directrice générale.

Lorsqu'ils utilisent RBAC, les administrateurs devraient avoir tendance à préférer les autorisations spécifiques à l'espace de noms plutôt que les autorisations à l'échelle du cluster, en spécifiant les contrôles d'accès pour chaque objet et espace de noms Kubernetes. N'autorisez l'accès qu'en cas de nécessité pour des tâches spécifiques, et rien de plus.

Application des politiques de réseau

Les conteneurs communiquent avec des services externes et entre eux sur le réseau. Les applications conteneurisées utilisent souvent le réseau de clusters de manière intensive. Pour mieux comprendre comment les applications interagissent avec d'autres systèmes et pour identifier les communications anormales, mettez en place une surveillance du trafic réseau actif et comparez-le au trafic autorisé par la politique réseau de Kubernetes.

Pour sécuriser la connectivité du réseau, les entreprises doivent appliquer des politiques de réseau qui limitent la communication aux services nécessaires, en privilégiant le minimum requis pour que les charges de travail fonctionnent correctement. Cette recommandation s'applique au trafic entrant et sortant vers la grappe, ainsi qu'au trafic à l'intérieur de la grappe.

Crypter le trafic réseau à l'aide de réseaux privés virtuels (VPN) et de TLS. Pour renforcer la sécurité des conteneurs, déployez des pare-feu dans l'environnement afin d'ajouter une couche de protection supplémentaire, et mettez en œuvre la segmentation du réseau et l'isolation des ressources afin de réduire la surface d'attaque et de contenir les brèches.

Appliquer l'admission à la sécurité des pods (PSA)

PSA, le successeur de Pod Security Policy (PSP), applique les politiques de sécurité, connues sous le nom de Pod Security Standards (PSS) au sein de Kubernetes. En tant que fonction intégrée, la PSA élimine le besoin d'outils tiers et simplifie la sécurité en définissant et en respectant un ensemble de normes. Il impose des restrictions aux configurations non sécurisées, réduisant ainsi la surface d'attaque.

Le PSS appliqué par Pod Security Admission définit trois profils de sécurité pour les charges de travail. Le profil Privileged n'impose aucune restriction et ne doit être utilisé qu'en cas d'absolue nécessité. Le profil Baseline fournit un minimum de sécurité pour l'application, tandis que le profil Restricted applique les meilleures pratiques en matière de sécurité.

La PSA vérifie que les pods sont configurés conformément à ces profils, ce qui renforce la conformité. En général, les administrateurs doivent définir la politique Baseline ou Restricted pour les pods afin de garantir la sécurité du cluster.

Sécuriser le plan de contrôle

Le plan de contrôle Kubernetes est responsable du contrôle du cluster. Il gère l'état, la santé et les données de configuration du cluster, en veillant à ce que les conteneurs fonctionnent avec toutes les ressources nécessaires. En raison de son importance et de sa complexité, le plan de contrôle est considéré comme quelque peu difficile à configurer et est donc devenu une cible privilégiée pour les attaquants.

Le plan de contrôle se compose des éléments suivants :

• etcd : La base de données clé-valeur etcd stocke les informations de configuration et les données relatives à l'état de la grappe. Assurez-vous que le chiffrement est activé dans etcd, que la communication est limitée au serveur API sauf en cas d'absolue nécessité et que les clients utilisent une authentification basée sur un certificat.
• kube-controller-manager : Le démon Controller Manager exécute les clusters et contrôle leurs fonctions. La sécurisation du Controller Manager implique de restreindre l'accès au réseau, d'implémenter TLS pour tout le trafic API, de limiter l'utilisation des ressources sur le cluster et de minimiser les privilèges utilisés par les conteneurs.
• kube-scheduler : Le Scheduler gère et approvisionne les nouveaux conteneurs. Les mesures de sécurité comprennent la désactivation de sa capacité de profilage afin de réduire sa surface d'attaque, et la vérification que l'adresse IP de l'ordonnanceur n'est pas liée à une IP non sécurisée.
• kube-apiserver : Le serveur API joue le rôle d'interface et traite les demandes internes et externes. En bref, sécurisez le serveur API en limitant l'accès par des IPS externes, en appliquant des mécanismes d'authentification forte et en appliquant le chiffrement TLS. Reportez-vous à la section "Sécuriser l'API Kubernetes" ci-dessous pour plus de détails.

Sécurisez le serveur API Kubernetes

Les utilisateurs externes accèdent au plan de contrôle de Kubernetes via l'API, il est donc extrêmement important de garantir sa sécurité et de limiter l'accès aux utilisateurs non autorisés.

Pour sécuriser l'API Kubernetes, commencez par réguler les demandes ciblant le serveur afin de vous assurer que les demandes d'API non autorisées ne parviennent pas à accéder au cluster. Envisagez d'utiliser des fournisseurs d'authentification tiers, qui permettront une authentification multi-facteurs (MFA). Utilisez des connecteurs OAuth 2.0 ou des fournisseurs OpenID Connect (OIDC) pour sécuriser l'accès au cluster.

Limitez l'accès au réseau public et mettez en place un chiffrement TLS (Transport Layer Security) pour les données qui transitent par le serveur API. Confirmez également que le magasin de données Kubernetes, etcd, qui communique directement avec le serveur API, est lui-même sécurisé de manière appropriée.

Analyse de la sécurité des images

Les images constituent la base des clusters et des pods créés. Ces images doivent être régulièrement analysées pour vérifier leur vulnérabilité, afin de s'assurer que les conteneurs créés à partir des images n'héritent pas des failles de sécurité de l'image.

Les outils d'analyse d'images peuvent être utilisés pour identifier la vulnérabilité de l'image de base sur laquelle les conteneurs sont construits, et l'application pour les bibliothèques incluses dans les images de conteneurs. Pour ce faire, l'image de base et tous les paquets sont comparés à une base de données de vulnérabilité.

Veillez à ce que l'accès aux registres d'images soit limité afin d'empêcher toute falsification, et analysez toutes les images tout au long des étapes du pipeline d'intégration continue/déploiement continu (CI/CD). L'ajout de l'analyse dans le pipeline CI/CD permet de s'assurer que les conteneurs sont correctement configurés, mis à jour et exempts de logiciels malveillants.

Chiffrer les secrets et les communications

Les secrets sont une forme d'information sensible. Dans Kubernetes, les secrets les plus courants sont généralement des mots de passe, des jetons OAuth, des clés SSH ou d'autres informations d'identification. Les secrets stockés en clair - dans des fichiers de configuration YAML, des images de conteneurs ou des documents sur des conteneurs - représentent un risque critique et mettent en péril la sécurité de l'ensemble du cluster.

Kubernetes propose un objet intégré, le Kubernetes Secret, pour stocker ces données en toute sécurité. Grâce aux objets secrets, les administrateurs peuvent séparer les informations confidentielles du code de l'application.

Comme les Secrets Kubernetes manipulent des informations privilégiées, ils sont fréquemment ciblés par les pirates informatiques. Les secrets doivent être cryptés au repos et leur accès doit être limité aux seuls composants et utilisateurs qui en ont besoin. Mettre en œuvre des pratiques ou des systèmes d'analyse des secrets afin d'identifier et de remédier à l'exposition accidentelle de secrets.

Limiter l'exposition des nœuds

Les nœuds Kubernetes se présentent sous deux formes principales : les nœuds maîtres et les nœuds travailleurs. Les nœuds maîtres exécutent les services de base du cluster, notamment le serveur API, le planificateur, le contrôleur et le magasin de données etcd. Les nœuds de travail exécutent l'application au sein de la grappe.

Kubernetes Les grappes sont composées de nœuds qui exécutent des systèmes d'exploitation (OS) Linux ou Windows. De nombreuses techniques de renforcement qui s'appliquent généralement au renforcement de ces systèmes d'exploitation sont valables dans le contexte des nœuds Kubernetes:

• N'installez que l'application et les bibliothèques nécessaires au bon fonctionnement du cluster, et rien de plus.
• Restreignez l'accès aux comptes administratifs/racines et ne les utilisez qu'en cas de nécessité.
• Déployez des outils de surveillance en temps réel pour détecter les failles de sécurité en cours.
• Les nœuds Linux peuvent être renforcés à l'aide d'outils tels que SELinux ou AppArmor.

En outre, le Center for Internet Security (CIS) fournit un ensemble de critères de sécurité pour les nœuds maîtres et les nœuds travailleurs. À l'aide d'un outil comme Kube-bench, les administrateurs peuvent analyser leurs clusters et les évaluer par rapport à des critères de référence CIS. Ces analyses fournissent généralement des recommandations pour remédier aux configurations qui ne sont pas conformes aux meilleures pratiques du SID.

Activer les journaux d'audit

Les journaux d'audit sont importants pour maintenir les opérations et la sécurité. Ces journaux offrent des informations exploitables sur l'activité des clusters et permettent de détecter rapidement les activités anormales. Bien que Kubernetes intègre des fonctionnalités de journalisation d'audit, celles-ci ne sont pas activées par défaut. Dès l'activation, toutes les actions sont enregistrées au sein du cluster.

Les administrateurs de clusters doivent configurer une politique d'audit qui définit les événements à enregistrer, ainsi que des outils externes pour le stockage, la gestion et l'analyse de ces enregistrements. Les problèmes de sécurité sont ainsi rapidement détectés, tout en fournissant les informations nécessaires aux équipes de réponse aux incidents (RI) pour enquêter sur les violations qui se produisent.

Exécuter des charges de travail avec un minimum de privilèges

Les charges de travail Kubernetes peuvent être complexes et difficiles à sécuriser de manière adéquate. Les charges de travail sont dynamiques et passent d'un environnement sur site à un environnement en nuage, chacun ayant ses propres contrôles de sécurité. De plus, les processus automatisés CI/CD déploient fréquemment de nouveaux services ou de nouvelles versions sur les nœuds du cluster, ce qui intensifie la complexité.

En règle générale, les administrateurs ne doivent jamais faire confiance aux charges de travail. Appliquez des stratégies de sécurité fines pour limiter la communication entre les charges de travail et les applications tierces. Cela réduit la probabilité d'un déplacement latéral des menaces et contribue à maintenir la conformité.

Les définitions de sécurité du réseau doivent être intégrées dans les charges de travail, de sorte qu'elles soient transférables entre les distributions Kubernetes et les centres de données. Ainsi, quel que soit l'endroit où la charge de travail s'exécute, elle transmet les définitions de sécurité.

Enfin, configurez les outils de sécurité périmétrique pour surveiller en permanence les adresses IP et les ports utilisés par les charges de travail, ce qui permet d'identifier en temps réel les comportements suspects.