Pod Security Admission : Appliquer des standards de sécurité

Standardiser la sécurité : des politiques cohérentes pour les Pods

Après avoir appris à définir des contextes de sécurité spécifiques pour chaque Pod et conteneur via le `SecurityContext`, une question naturelle se pose : comment s'assurer que des standards de sécurité minimaux sont appliqués de manière cohérente à travers différents namespaces ou même l'ensemble du cluster ? Demander à chaque développeur de configurer parfaitement le `SecurityContext` pour chaque Pod est sujet aux erreurs et aux oublis.

C'est là qu'intervient le contrôle d'admission au niveau du cluster. Historiquement, Kubernetes utilisait les PodSecurityPolicies (PSP) pour cette tâche, mais elles se sont avérées complexes à gérer et ont été dépréciées puis supprimées. Pour les remplacer, Kubernetes a introduit une solution intégrée, plus simple et plus facile à utiliser : le Pod Security Admission (PSA).

PSA est un contrôleur d'admission intégré qui évalue les spécifications des Pods lors de leur création ou mise à jour, et applique des politiques basées sur les Pod Security Standards prédéfinis. Il offre un moyen standardisé d'établir des niveaux de sécurité de base pour les charges de travail, empêchant le déploiement de Pods qui ne respectent pas les exigences de sécurité définies au niveau du Namespace.

Pod Security Standards : les niveaux de sécurité prédéfinis

Au coeur de PSA se trouvent les Pod Security Standards, un ensemble de trois politiques (ou niveaux) de sécurité prédéfinis, allant du plus permissif au plus restrictif :

• privileged :
  - Objectif : Politique intentionnellement ouverte et totalement non restrictive.
  - Description : Ne pose aucune contrainte. Permet les privilèges les plus élevés, y compris les escalades connues. Ce niveau est généralement réservé aux composants système gérés par des administrateurs de confiance et aux charges de travail qui nécessitent un accès de niveau hôte.
  - Contrôles : Aucun.
• baseline :
  - Objectif : Politique visant à prévenir les escalades de privilèges connues, tout en étant relativement facile à adopter pour les applications courantes.
  - Description : Interdit l'utilisation de fonctionnalités dangereuses comme les Pods privilégiés (privileged: true), l'accès aux namespaces de l'hôte (hostNetwork, hostPID, hostIPC), l'utilisation de hostPath pour les volumes, l'ajout de capacités Linux risquées, etc. Elle n'impose pas l'exécution en tant qu'utilisateur non-root mais empêche les escalades.
  - Cas d'usage : Recommandé comme configuration minimale pour la plupart des applications non système.
• restricted :
  - Objectif : Politique très restrictive, suivant les meilleures pratiques actuelles de renforcement (hardening) des Pods.
  - Description : Englobe toutes les restrictions de baseline et ajoute des exigences plus strictes, telles que l'obligation de s'exécuter en tant qu'utilisateur non-root (runAsNonRoot: true doit être effectif), le blocage de l'escalade de privilèges (allowPrivilegeEscalation: false), la suppression de toutes les capacités Linux sauf celles explicitement autorisées (drop: ["ALL"]), et l'application d'un profil Seccomp sécurisé (comme RuntimeDefault ou mieux).
  - Cas d'usage : Idéal pour les applications sensibles à la sécurité et celles qui peuvent fonctionner avec des privilèges très limités. L'adoption de ce niveau peut nécessiter des modifications dans les manifestes de déploiement.

Ces standards sont versionnés (ex: `v1.28`) pour permettre une évolution contrôlée des politiques au fil des versions de Kubernetes.

Activation et configuration via les Labels de Namespace

La configuration de Pod Security Admission se fait principalement en appliquant des labels spécifiques aux Namespaces. Pour chaque Namespace, vous pouvez définir quel niveau de standard de sécurité doit être appliqué et comment il doit être appliqué.

Trois modes d'application peuvent être définis par des labels, chacun associé à un niveau de standard (privileged, baseline, ou restricted) et optionnellement à une version spécifique :

• pod-security.kubernetes.io/enforce: : Mode d'application strict. Si un Pod soumis à ce Namespace ne respecte pas le niveau de standard spécifié, sa création ou sa mise à jour est bloquée par le contrôleur d'admission. Exemple : pod-security.kubernetes.io/enforce: baseline.
• pod-security.kubernetes.io/audit: : Mode d'audit. Si un Pod ne respecte pas le niveau spécifié, il est quand même autorisé, mais une entrée est ajoutée aux logs d'audit du cluster indiquant la violation. Utile pour évaluer l'impact d'une politique avant de l'appliquer strictement. Exemple : pod-security.kubernetes.io/audit: restricted.
• pod-security.kubernetes.io/warn: : Mode d'avertissement. Si un Pod ne respecte pas le niveau spécifié, il est autorisé, mais un avertissement est retourné à l'utilisateur qui a soumis la requête (visible via kubectl par exemple). Utile pour informer les développeurs des non-conformités sans bloquer leurs déploiements. Exemple : pod-security.kubernetes.io/warn: baseline.

Vous pouvez spécifier une version du standard en ajoutant : au label, par exemple pod-security.kubernetes.io/enforce: restricted:v1.28. Utiliser :latest applique la dernière version supportée par l'API Server.

Exemple : Appliquer le niveau `baseline` et auditer le niveau `restricted` pour un namespace :

kubectl label namespace my-app-ns pod-security.kubernetes.io/enforce=baseline pod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/warn=baseline --overwrite

Dans cet exemple, les Pods dans `my-app-ns` doivent respecter le niveau `baseline` pour être créés. S'ils ne respectent pas `restricted`, une entrée d'audit sera générée. S'ils ne respectent pas `baseline`, un avertissement sera également affiché à l'utilisateur (en plus du blocage).

Configuration globale et exemptions

Au-delà des labels par Namespace, il est possible de configurer des politiques par défaut et des exemptions au niveau du cluster via le fichier de configuration du contrôleur d'admission Pod Security (passé en argument à l'API Server).

Cette configuration permet de définir les niveaux (`enforce`, `audit`, `warn`) qui s'appliqueront par défaut à tous les Namespaces qui n'ont pas de labels spécifiques. C'est utile pour établir une politique de sécurité minimale à l'échelle du cluster.

La configuration permet également de définir des exemptions. Les exemptions permettent à certains Pods de contourner les vérifications de PSA, même s'ils sont dans un Namespace où une politique est appliquée. Les exemptions peuvent être basées sur :

• Les Usernames : Permettre à certains utilisateurs (souvent des administrateurs) de créer des Pods non conformes.
• Les RuntimeClassNames : Exempter les Pods utilisant des runtimes spécifiques (comme les conteneurs Kata ou gVisor qui fournissent leur propre isolation).
• Les Namespaces : Exempter complètement certains Namespaces (typiquement les Namespaces système comme `kube-system`) des vérifications PSA. C'est essentiel car les composants système s'exécutent souvent avec des privilèges élevés (niveau `privileged`).

La configuration des exemptions est cruciale pour éviter de bloquer le fonctionnement normal des composants système du cluster lors de l'application de politiques restrictives.

Avantages par rapport aux PodSecurityPolicies (PSP)

Pod Security Admission a été conçu pour pallier les défauts des PodSecurityPolicies (PSP) :

• Simplicité : PSA est beaucoup plus simple à comprendre et à configurer, avec seulement trois niveaux prédéfinis et une configuration basée sur les labels de Namespace. PSP nécessitait la création d'objets PSP complexes et une gestion fine des liaisons RBAC pour autoriser leur utilisation.
• Intégré : PSA est un contrôleur d'admission intégré et activé par défaut dans les versions récentes de Kubernetes, ne nécessitant pas d'installation séparée.
• Facilité d'adoption : Les modes `warn` et `audit` permettent une adoption progressive et une évaluation de l'impact avant l'application stricte (`enforce`).
• Centré sur le Namespace : L'application des politiques au niveau du Namespace est plus intuitive que le modèle PSP qui était lié aux ServiceAccounts ou aux utilisateurs créant le Pod.

PSA offre une approche standardisée et pragmatique pour améliorer la sécurité des Pods dans Kubernetes, la rendant accessible et gérable même dans de grands clusters.

Bonnes pratiques pour utiliser PSA

• Commencez par Auditer/Avertir : Avant d'appliquer un niveau `enforce`, utilisez les modes `audit` et `warn` pendant un certain temps pour identifier les charges de travail non conformes et donner le temps aux équipes de les corriger sans bloquer les déploiements.
• Appliquez `baseline` largement : Le niveau `baseline` est un bon objectif par défaut pour la plupart des Namespaces applicatifs.
• Utilisez `restricted` pour les workloads sensibles : Visez le niveau `restricted` pour les applications critiques ou celles manipulant des données sensibles, mais assurez-vous que les applications sont compatibles (exécution non-root, etc.).
• Exemptez les Namespaces Système : Assurez-vous que `kube-system` et potentiellement d'autres Namespaces contenant des opérateurs ou agents système sont exemptés pour éviter de perturber le fonctionnement du cluster.
• Documentez vos politiques : Communiquez clairement les niveaux de sécurité appliqués à chaque Namespace aux équipes de développement.
• Combinez avec `SecurityContext` : PSA valide les Pods, mais c'est toujours via les `SecurityContext` que les configurations de sécurité sont effectivement appliquées. Les deux fonctionnent ensemble.

Pod Security Admission constitue une avancée majeure pour la sécurité par défaut dans Kubernetes, offrant un moyen efficace et gérable d'appliquer des standards de sécurité essentiels à vos charges de travail.