Pod Security Standards (PSS) : sécuriser les workloads Kubernetes

Les Pod Security Standards (PSS) définissent 3 niveaux de restrictions de sécurité pour vos pods Kubernetes : Privileged (aucune restriction), Baseline (bloque les escalades évidentes), et Restricted (hardening maximal). Ce guide vous explique quand utiliser chaque niveau et comment les appliquer sans casser vos applications.

Domaine CKS

Les Pod Security Standards font partie du domaine Minimize Microservice Vulnerabilities (20%) de la certification CKS.

Qu’est-ce que Pod Security Standards ?

Pod Security Standards (PSS) est le standard officiel Kubernetes pour définir les niveaux de sécurité des pods. Pensez-y comme à des “profils de sécurité prédéfinis” que vous pouvez appliquer à vos namespaces.

Pourquoi c’est important ?

Par défaut, Kubernetes autorise des configurations dangereuses. Sans restriction explicite, un développeur peut déployer un pod qui a un accès complet au nœud hôte — ce qui est exactement ce qu’un attaquant recherche.

Voici ce qui est autorisé si vous ne configurez rien :

Configuration par défaut	Risque
Pod en root (UID 0)	Escalade de privilèges si le conteneur est compromis
privileged: true autorisé	Accès complet à l’hôte
Montage de / possible	Lecture/écriture du système hôte
hostNetwork: true autorisé	Écoute sur les ports de l’hôte

Glissez pour voir

Scénario d’attaque : Un attaquant compromet une application vulnérable dans un pod. Si le pod tourne en root avec privileged: true, l’attaquant peut s’échapper du conteneur, accéder au nœud, puis pivoter vers d’autres nœuds du cluster. Les PSS empêchent ce scénario en bloquant ces configurations dès le déploiement.

Les PSS bloquent ces configurations selon leur niveau de restriction.

Les 3 niveaux PSS

Privileged

Niveau Privileged

Aucune restriction — Ce niveau autorise tout, y compris les configurations les plus dangereuses.

Quand l’utiliser :

• Namespaces système (kube-system)
• Outils d’infrastructure (monitoring agents, CNI, CSI drivers)
• Jamais pour des applications métier

# Ce pod est autorisé en Privileged
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: debug
    image: ubuntu
    securityContext:
      privileged: true      # Accès root complet à l'hôte
      runAsUser: 0          # Exécution en root

Attention

Le niveau Privileged doit être réservé aux composants système. Ne l’appliquez jamais aux namespaces applicatifs.

Baseline

Niveau Baseline

Restrictions minimales — Bloque les escalades de privilèges les plus dangereuses tout en restant compatible avec la majorité des workloads.

Ce qui est bloqué :

Configuration	Pourquoi c’est bloqué
privileged: true	Accès complet à l’hôte
hostPID: true	Voir les processus de l’hôte
hostIPC: true	Accès à la mémoire partagée de l’hôte
hostNetwork: true	Écoute sur les ports de l’hôte
Capabilities dangereuses	SYS_ADMIN, NET_RAW, etc.

Glissez pour voir

Quand l’utiliser :

• Applications legacy ne supportant pas Restricted
• Première étape de migration depuis Privileged
• Environnements de développement

# Ce pod est compatible Baseline
apiVersion: v1
kind: Pod
metadata:
  name: baseline-pod
spec:
  containers:
  - name: app
    image: nginx:1.25
    securityContext:
      runAsUser: 1000       # Non-root recommandé
      allowPrivilegeEscalation: false

Restricted

Niveau Restricted

Hardening maximal — Applique les meilleures pratiques de sécurité. C’est le niveau recommandé pour la production.

Ce qui est exigé :

Exigence	Valeur requise
runAsNonRoot	true
allowPrivilegeEscalation	false
seccompProfile	RuntimeDefault ou Localhost
capabilities.drop	ALL
Volumes autorisés	Seulement configMap, secret, emptyDir, persistentVolumeClaim, projected

Glissez pour voir

Quand l’utiliser :

• Applications de production
• Workloads manipulant des données sensibles
• Préparation à la certification CKS

# Ce pod est conforme Restricted
apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx:1.25-alpine
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Comment appliquer PSS ?

Kubernetes applique les Pod Security Standards via Pod Security Admission (PSA), un admission controller intégré depuis la version 1.25.

Les 3 modes d’application

PSA offre trois manières d’appliquer un niveau PSS à un namespace. Ces modes peuvent être combinés pour une migration progressive et sécurisée.

Mode	Comportement	Usage
enforce	Bloque les pods non conformes	Production
audit	Enregistre dans les audit logs	Migration
warn	Affiche un warning à l’utilisateur	Développement

Glissez pour voir

Stratégie de migration recommandée :

1. D’abord warn + audit : Les développeurs voient les warnings, les violations sont loggées, mais rien n’est bloqué. Cela vous donne le temps de corriger les manifests.
2. Ensuite enforce : Une fois tous les pods conformes, activez le blocage. Toute tentative de déploiement non conforme sera refusée.

Cette approche évite de casser la production du jour au lendemain.

Appliquer PSS à un namespace

Méthode 1 : Labels sur le namespace

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Applique Restricted en mode enforce
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

    # Audit les violations Restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

    # Avertit pour Restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

Méthode 2 : kubectl label

# Appliquer Restricted sur un namespace existant
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

# Vérifier les labels
kubectl get namespace production -o yaml | grep pod-security

Migrer vers Restricted sans casser vos applications

1. Audit d’abord : identifiez les violations

   Appliquez d’abord en mode audit + warn pour voir ce qui casserait :

   kubectl label namespace monapp \
     pod-security.kubernetes.io/audit=restricted \
     pod-security.kubernetes.io/warn=restricted

   Créez un pod de test et observez les warnings :

   kubectl run test --image=nginx -n monapp
   # Warning: would violate "restricted:latest"...

2. Corrigez vos Deployments

   Pour chaque violation identifiée, mettez à jour le securityContext :

   spec:
     securityContext:
       runAsNonRoot: true
       seccompProfile:
         type: RuntimeDefault
     containers:
     - name: app
       securityContext:
         allowPrivilegeEscalation: false
         readOnlyRootFilesystem: true
         runAsUser: 1000
         capabilities:
           drop: ["ALL"]

3. Testez en staging

   Déployez avec les nouveaux securityContext et validez que l’application fonctionne.

4. Appliquez Restricted en enforce

   Une fois tous les pods conformes :

   kubectl label namespace production \
     pod-security.kubernetes.io/enforce=restricted \
     --overwrite

Images non-root

Certaines images Docker s’exécutent en root par défaut (nginx, redis, postgres). Utilisez les variantes non-root :

• nginx:1.25-alpine → nginxinc/nginx-unprivileged:1.25
• redis:7 → bitnami/redis:7.2

Erreurs fréquentes et solutions

Erreur 1 : “container has runAsNonRoot and image will run as root”

Cause : L’image utilise root mais vous avez runAsNonRoot: true.

Solution :

securityContext:
  runAsUser: 1000      # Forcer un UID non-root
  runAsGroup: 1000
  runAsNonRoot: true

Erreur 2 : “seccompProfile is required”

Cause : Le niveau Restricted exige un profil seccomp.

Solution :

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Erreur 3 : “unrestricted capabilities”

Cause : Vous n’avez pas droppé toutes les capabilities.

Solution :

containers:
- name: app
  securityContext:
    capabilities:
      drop: ["ALL"]
      # Si vraiment nécessaire, ajoutez explicitement :
      # add: ["NET_BIND_SERVICE"]

Comparatif des 3 niveaux

Ce tableau résume ce qui est autorisé ou bloqué à chaque niveau. Utilisez-le comme référence rapide lors de vos audits de sécurité.

Configuration	Privileged	Baseline	Restricted
privileged: true	✅	❌	❌
hostNetwork/PID/IPC	✅	❌	❌
hostPath volumes	✅	✅	❌
Root (UID 0)	✅	✅	❌
allowPrivilegeEscalation	✅	✅	❌
Capabilities dangereuses	✅	❌	❌
Seccomp requis	❌	❌	✅

Glissez pour voir

Comment lire ce tableau ?

• Baseline bloque les vulnérabilités critiques (privileged, hostNetwork) mais autorise encore des pratiques risquées (hostPath, root).
• Restricted va plus loin : il exige un profil seccomp, interdit root, et limite les volumes montés. C’est la posture “zéro confiance” pour vos workloads.
• Attention à hostPath : Même en Baseline, un attaquant peut monter /etc/shadow s’il contrôle le manifest du pod. C’est pourquoi Restricted est recommandé en production.

À retenir

• 3 niveaux : Privileged (tout autorisé), Baseline (bloque le pire), Restricted (hardening maximal)
• Production = Restricted : C’est le niveau recommandé par la documentation Kubernetes
• Migration progressive : Utilisez audit et warn avant enforce
• Pod Security Admission : L’admission controller natif qui applique les PSS via des labels
• CKS : Les PSS représentent 20% du domaine “Minimize Microservice Vulnerabilities”

Prochaines étapes

Admission Controllers Vue d'ensemble des contrôleurs d'admission Kubernetes

Préparation CKS Parcours complet vers la certification

×

📖 Voir la documentation →