Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Pod Security Standards

cloud

Définition

Les Pod Security Standards (PSS) sont le mécanisme standardisé de Kubernetes pour définir des niveaux de sécurité des pods, remplaçant les Pod Security Policies (PSP) dépréciées dans Kubernetes 1.21 et supprimées dans Kubernetes 1.25. Ils définissent trois profils de sécurité applicables via l'Admission Controller Pod Security Admission (PSA). Les trois profils PSS sont : Privileged (aucune restriction, équivalent à l'absence de politique - à utiliser uniquement pour les workloads système de confiance), Baseline (prévient les configurations manifestement dangereuses : conteneurs privilégiés, hostPath sensibles, ports d'hôte - convient aux applications générales), et Restricted (profil le plus strict, exigeant : conteneurs non-root, filesystem read-only, seccomp runtime, capabilities drop ALL - pour les applications sensibles). L'application des PSS se fait via des labels sur les namespaces. Par exemple : pod-security.kubernetes.io/enforce=restricted applique le profil restricted (pods non conformes sont rejetés), pod-security.kubernetes.io/warn=restricted génère des avertissements sans bloquer, et pod-security.kubernetes.io/audit=restricted enregistre les violations dans les audit logs. Ces trois modes peuvent être combinés avec des niveaux différents pour une migration progressive. Les Pod Security Standards constituent une protection par défaut mais ne remplacent pas des solutions plus granulaires. OPA/Gatekeeper et Kyverno offrent une flexibilité supérieure pour des politiques complexes (par exemple, n'autoriser que des images provenant d'un registre spécifique, ou exiger des labels spécifiques sur tous les pods). La combinaison PSS (pour les baselines) + Kyverno (pour les règles métier spécifiques) est un pattern recommandé. La migration depuis les PSP vers les PSS nécessite une analyse préalable des PSP existantes et leur mapping vers les profils PSS. Des outils comme psp-util et kubectl-convert facilitent cette migration, mais une validation manuelle est toujours recommandée pour les configurations non standard.

Application des PSS dans les namespaces

Appliquez baseline sur tous les namespaces applicatifs par défaut (label au niveau de la namespace par défaut avec un MutatingWebhookConfiguration ou via un Kyverno ClusterPolicy). Appliquez restricted sur les namespaces des applications critiques. Pour kube-system et les namespaces d'infrastructure, laissez privileged (les agents CNI, Falco, etc. nécessitent des permissions étendues). Utilisez le mode warn avant enforce pour identifier les pods non conformes sans interruption de service.

Profil Restricted : ce qu'il exige

Le profil Restricted exige : runAsNonRoot: true (ou runAsUser > 0), allowPrivilegeEscalation: false, readOnlyRootFilesystem: true (fortement recommandé), capabilities.drop: ["ALL"] avec ajout minimal de capabilities, et seccompProfile de type RuntimeDefault ou Localhost. Ces exigences peuvent nécessiter des adaptations dans les Dockerfiles des applications (utilisation d'un utilisateur non-root) et dans les configurations des Deployments.

PSS vs OPA/Gatekeeper vs Kyverno

PSS est intégré nativement dans Kubernetes et couvre les cas d'usage les plus communs sans déploiement supplémentaire. OPA/Gatekeeper offre une flexibilité maximale via Rego (langage spécifique à la politique) pour des règles complexes. Kyverno utilise YAML natif Kubernetes, plus accessible aux équipes DevOps. La recommandation actuelle de la communauté est Kyverno pour sa simplicité ou OPA pour les organisations déjà familières avec Rego.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis