Comprendre les standards de sécurité des pods Kubernetes

Kubernetes a « franchi le cap de l’adoption » en 2021, après que 5,6 millions de développeurs l’ont utilisé pour orchestrer leurs conteneurs, selon la Cloud Native Computing Foundation (CNCF). L’enquête annuelle de la CNCF a révélé que pas moins de 96 % des entreprises envisageaient d’utiliser Kubernetes ou l’utilisaient déjà.

Cependant, à mesure que Kubernetes gagne en popularité, il attire davantage les pirates et les acteurs malveillants. Alors que les développeurs adoptent Kubernetes comme plateforme d’orchestration de conteneurs de référence, ils doivent également veiller à l’utiliser de manière sécurisée.

Les standards de sécurité des pods Kubernetes sont essentiels pour préserver la sécurité de Kubernetes. Ils comprennent trois politiques cumulatives, allant de mesures de sécurité très strictes à des mesures plutôt souples. Découvrons en détail les standards de sécurité des pods Kubernetes, examinons comment le contrôleur d’admission Pod Security les applique et explorons les cas d’usage de chaque politique.

Que sont les standards de sécurité des pods Kubernetes ?

Les standards de sécurité des pods Kubernetes sont des politiques et des recommandations destinées à préserver la sécurité et l’intégrité des conteneurs dans les clusters Kubernetes. Ils définissent trois profils assortis de différents niveaux de restriction afin de protéger les charges de travail conteneurisées contre les escalades de privilèges connues et de respecter les bonnes pratiques actuelles de renforcement des pods :

• Privilégié : politique sans aucune restriction.

• De base : garde-fous minimaux qui empêchent les escalades de privilèges connues.

• Restreint : respecte les bonnes pratiques actuelles de renforcement des pods, mais peut limiter la compatibilité.

Le respect de ces standards contribue à garantir que les applications conteneurisées satisfont aux exigences de sécurité conformes aux normes du secteur dans les environnements Kubernetes. Pour cela, Kubernetes propose un contrôleur d’admission Pod Security intégré, qui vérifie le niveau d’isolation des pods par rapport à ces standards de sécurité.

Dans les versions précédentes de Kubernetes, cette tâche incombait à PodSecurityPolicy. Toutefois, Kubernetes a rendu cette fonctionnalité obsolète dans la version 1.21, puis l’a entièrement supprimée dans la version 1.25. Dans un article de blog, le groupe SIG Security de Kubernetes a expliqué que le contrôleur d’admission d’origine présentait de « graves problèmes d’ergonomie ». PodSecurityPolicy prêtait à confusion, risquait d’accorder par inadvertance des permissions plus larges que prévu et compliquait l’identification des permissions applicables dans une situation donnée. Adapter PodSecurityPolicy pour résoudre ces problèmes aurait constitué un projet complexe, susceptible de compromettre d’autres fonctionnalités. C’est pourquoi cette fonctionnalité a été abandonnée et remplacée. 

Les standards de sécurité des pods reprennent les niveaux standard de PodSecurityPolicy, désormais obsolète, ce qui simplifie la transition des systèmes existants qui l’utilisent. Le contrôleur d’admission Pod Security intégré applique ces standards aux clusters ou aux espaces de noms.

Utiliser le contrôleur d’admission Pod Security

Une fois le contrôleur d’admission Pod Security activé et le webhook installé, nous pouvons configurer le mode de contrôle d’admission dans nos espaces de noms :

• Enforcement : rejette les pods qui enfreignent la politique.

• Audit : autorise les pods qui enfreignent la politique, mais ajoute une annotation d’audit à l’enregistrement de l’événement dans le journal d’audit.

• Avertissement : autorise les pods qui enfreignent la politique, mais avertit les utilisateurs.

La configuration du contrôleur d’admission Pod Security implique de définir deux étiquettes :

• Niveau : privilégié, de base ou restreint.

• Mode : enforcement, audit ou avertissement.

De même, nous pouvons définir plusieurs contrôles de sécurité pour n’importe quel espace de noms. Nous pouvons également préciser la version et effectuer le contrôle en fonction de la politique fournie avec cette version mineure de Kubernetes.

Par exemple, pour vérifier si l’espace de noms « my-namespace » ne respecte pas la dernière version du niveau de base des standards de sécurité des pods, nous pouvons configurer cet avertissement :

1kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/warn=baseline \
3   pod-security.kubernetes.io/warn-version=latest

Et si nous voulons appliquer le niveau de sécurité « de base », tout en recevant des notifications dans les journaux pour auditer le niveau de sécurité et vérifier si nous pouvons respecter le niveau restreint, nous pouvons le configurer ainsi :

1 kubectl label --overwrite ns my-namespace \
2   pod-security.kubernetes.io/enforce=baseline \
3   pod-security.kubernetes.io/enforce-version=latest
4   pod-security.kubernetes.io/audit=restricted \
5   pod-security.kubernetes.io/audit-version=latest

Utiliser le profil de sécurité privilégié

Comme le profil de sécurité privilégié autorise des escalades de privilèges connues, nous devrions le réserver à des cas d’usage précis, où seuls des utilisateurs de confiance exécutent des charges de travail d’infrastructure critiques. 

Le profil de politique privilégié des standards de sécurité des pods Kubernetes accorde les permissions nécessaires à la gestion de charges de travail sensibles, sans restriction, et offre la flexibilité requise pour effectuer des tâches complexes dans des systèmes critiques. Imaginons, par exemple, une entreprise qui gère des informations financières sensibles. Dans ce cas, des utilisateurs privilégiés et de confiance doivent gérer les charges de travail système et d’infrastructure de l’entreprise afin d’en garantir la sécurité.

Même si ce type d’accès est parfois nécessaire, l’entreprise ne devrait l’accorder qu’aux utilisateurs qui en ont strictement besoin dans le cadre de leurs fonctions. Avec une approche plus permissive, comme le profil privilégié, il est essentiel de limiter la portée des permissions. 

Lorsqu’on utilise un profil de sécurité privilégié, il est également important d’activer les modes avertissement et audit du niveau restreint du contrôleur d’admission Pod Security. Cette approche informe activement les utilisateurs de l’état de chaque action et ajoute des annotations d’audit aux entrées concernées dans tous les journaux d’événements.

Enfin, il est essentiel d’appliquer d’autres bonnes pratiques qui ne se limitent pas aux pods. Vous pouvez, par exemple, exiger une authentification multifacteur (MFA) afin de réduire les risques liés à l’octroi de permissions étendues.

Utiliser le profil de sécurité de base

La politique de base convient parfaitement aux responsables d’applications et aux développeurs d’applications non critiques qui souhaitent sécuriser leur environnement sans le rendre trop complexe. Elle leur permet de gérer les charges de travail conteneurisées courantes tout en se protégeant contre les escalades de privilèges connues. 

Imaginons, par exemple, que notre entreprise fictive exécute plusieurs microservices non critiques sur son infrastructure pour soutenir ses activités. Le profil de politique de base contribue à sécuriser ces charges de travail sans imposer d’efforts supplémentaires importants aux responsables d’applications ou aux développeurs. En appliquant cette mesure de sécurité peu restrictive, l’entreprise limite les risques potentiels et empêche les attaquants malveillants d’obtenir des privilèges élevés en exploitant des vulnérabilités dans des images de conteneurs ou d’autres vecteurs d’attaque. 

Supposons que l’entreprise fictive utilise le service d’un fournisseur tiers qui nécessite un accès en lecture seule aux données stockées dans des clusters Kubernetes. La politique de sécurité des pods de base limite l’accès privilégié au strict nécessaire pour le fournisseur et bloque toute tentative non autorisée de sa part (ou de toute autre personne) visant à élever son niveau de permission au-delà des exigences de base.

Le profil de sécurité de base offre également une certaine flexibilité aux entreprises qui utilisent des charges de travail standard, notamment des API et des applications Web. Elles n’auront pas besoin de mesures de configuration supplémentaires, sauf si des tests et analyses plus poussés révèlent qu’elles sont nécessaires.

Il est important de noter que le profil de sécurité de base est volontairement générique afin de couvrir un large éventail de charges de travail. Il comprend donc souvent des restrictions peu adaptées à un cas d’usage particulier. Plutôt que d’utiliser par défaut le profil privilégié, qui accorderait un accès root généralisé et non sécurisé, vous devrez probablement configurer des contrôles propres à votre application en fonction de votre cas d’usage.

Utiliser le profil de sécurité restreint

Le profil de politique restreint est le plus sécurisé des trois, car il applique les bonnes pratiques actuelles de renforcement des pods. 

Imaginons que notre entreprise fictive déploie plusieurs charges de travail conteneurisées pour traiter des transactions financières sensibles. Elle possède également des systèmes hérités exécutant des applications non conteneurisées qui ne respectent pas les normes de sécurité modernes. La politique de sécurité des pods restreinte garantit que tous les conteneurs respectent les bonnes pratiques, notamment en matière d’isolation, de restriction des comptes utilisateurs et de contrôle des privilèges réseau.

Grâce au profil de sécurité restreint, les responsables d’applications et les développeurs d’applications critiques pour la sécurité s’assurent, entre autres, que : 

• Tous les conteneurs exécutés dans un pod sont en lecture seule.

• Les capacités Linux sont limitées à celles dont le conteneur a besoin pour fonctionner.

• Le nom d’hôte de chaque conteneur est défini explicitement à l’aide d’une variable d’environnement.

• L’utilisation des ressources, comme le processeur et la mémoire, par processus dans un conteneur doit être spécifiée lors de la création des pods.

Le profil de politique restreint, plus sécurisé, offre une meilleure visibilité sur les surfaces d’attaque potentielles, en particulier aux entreprises qui gèrent des charges de travail vulnérables. Cette politique applique les bonnes pratiques actuelles de renforcement des pods afin de contribuer à prévenir les escalades de privilèges et d’autres activités malveillantes. 

Vous pouvez renforcer la sécurité en superposant des mécanismes de protection à différents niveaux, notamment en supprimant les fonctionnalités applicatives superflues qui ne sont pas essentielles et en utilisant des capacités avancées d’atténuation des menaces.

Utiliser les standards de sécurité des pods

Les standards de sécurité des pods Kubernetes aident les développeurs à sécuriser leurs applications conteneurisées dans l’environnement Kubernetes. Les trois profils de sécurité — privilégié, de base et restreint — imposent des restrictions différentes selon les besoins des utilisateurs. Le contrôleur d’admission Pod Security active ces standards dans les clusters ou les espaces de noms en appliquant les règles, en réalisant des audits ou en émettant des avertissements, selon le niveau choisi. Il permet également de préciser une version, si nécessaire.

Les entreprises peuvent utiliser les standards de sécurité des pods pour respecter les exigences de sécurité conformes aux normes du secteur, tout en se protégeant contre les escalades de privilèges potentielles et d’autres activités malveillantes. En définitive, l’application des standards de sécurité des pods par l’intermédiaire du contrôleur d’admission Pod Security simplifie le processus de développement tout en protégeant les charges de travail exécutées dans les clusters Kubernetes. 

Une fois les standards de sécurité des pods configurés dans Kubernetes, découvrez comment Snyk Container détecte et corrige les vulnérabilités des conteneurs tout au long du processus de développement, et vous fournit des informations et des recommandations pour les sécuriser.