Sécuriser Kubernetes : Pod Security Admission, NetworkPolicies, OPA Gatekeeper et Runtime-Scanning

Sécuriser Kubernetes commence par une priorisation claire : séparation des réseaux, contrôle d’entrée lors des déploiements et détection continue des anomalies. Dans cet article, j’explique de manière pragmatique comment combiner Pod Security Admission (un Admission Controller Kubernetes pour l’application de profils de sécurité de Pods), NetworkPolicies (segmentation réseau dans le cluster), OPA Gatekeeper (moteur de politiques pour le contrôle d’admission) et le Runtime‑Scanning (détection en quasi-temps réel des attaques et comportements anormaux). Le public visé comprend les administrateurs, les ingénieurs systèmes et les pRESTataires techniques responsables de l’exploitation, des migrations et de la sécurisation.

Sécuriser Kubernetes : éléments clés et stratégie de sécurité

Une approche structurée réduit les risques et la charge opérationnelle. Commencez par un modèle de protection simple et progressif :

• Renforcement de l’exécution des Pods (Pod Security Admission) – règles pour les permissions, les accès à l’hôte, les capabilities.
• Isolation réseau (NetworkPolicies) – surface d’accès minimale entre services.
• Contrôle d’admission par des policies (OPA Gatekeeper) – règles d’entreprise applicables avant persistance.
• Détection et forensique en runtime – agents comme Falco ou outils eBPF capturent les comportements déviants.

Ces couches se complètent : PSA empêche les Pods risqués, les NetworkPolicies limitent les mouvements latéraux, Gatekeeper applique les règles organisationnelles, et les scanners runtime détectent les attaques actives ou les erreurs de configuration.

Modèle de menace et hypothèses opérationnelles

Avant toute mesure technique, il faut clarifier les risques à adresser. Scénarios typiques :

• Images de conteneurs défectueuses avec droits root.
• Mouvement latéral entre Pods via des règles réseau de cluster ouvertes.
• Mauvaises configurations dans les déploiements (hostNetwork, hostPath, privileged).
• Exploit ciblant des processus runtime, exécutant des shells dans des conteneurs.

Préconditions pour les mesures suivantes : vous disposez des droits d’admin du cluster, votre CNI prend en charge les NetworkPolicies (p. ex. Calico, Cilium, Weave), et vous avez accès au CI/CD ou aux scans de registry d’images.

Pod Security Admission : ce que c’est, comment ça fonctionne, pièges typiques

Pod Security Admission (PSA) est un Admission Controller intégré depuis Kubernetes 1.22+, qui applique des profils de sécurité de Pods via des labels de Namespace. Les profils sont des politiques prédéfinies comme „privileged“, „baseline“ et „RESTricted“. PSA intervient lors de la création/modification d’un PodSpec : il bloque ou signale les violations.

Warum PSA wirkt

PSA intervient tôt dans le cycle de vie d’une ressource (admission), donc avant la persistance du Pod dans etcd. Il est simple à configurer et ne nécessite pas de composants externes. PSA réduit les champs à risque tels que hostPath, les containers privileged, certaines capabilities ou l’utilisateur root du conteneur.

Prérequis et risques

PSA est indispensable si vous souhaitez imposer des droits minimaux cohérents. Risques : des profils mal configurés peuvent casser des déploiements. Par conséquent, appliquez la mise en application de façon progressive (audit → warn → enforce) et prévoyez une stratégie de rollback.

Liste de contrôle avant activation

• Identifiez les namespaces critiques et les namespaces de démarrage.
• Testez les profils dans un cluster de staging ou en mode „warn“.
• Documentez les règles d’exception pour les workloads spéciaux (p. ex. agents de nœud).

Exemple : Namespace Label für „RESTricted“ (enforce)

Un label sur le namespace définit le profil. „enforce“ bloque les violations.

kubectl label ns finance pod-security.kubernetes.io/enforce=RESTricted

Vous pouvez d’abord observer via „audit“ :

kubectl label ns staging pod-security.kubernetes.io/audit=baseline

Scénarios d’erreurs typiques

Des pièges fréquents concernent les configurations pour DaemonSets/NodeAgents qui nécessitent hostPath ou CAP_SYS_ADMIN. Le pragmatisme aide : placez les systèmes d’exception dans des namespaces séparés, documentez les raisons et consolidez ainsi la surface d’attaque.

NetworkPolicies : segmentation dans Kubernetes

Les NetworkPolicies définissent quel Pod peut atteindre quel autre Pod. Important : les NetworkPolicies ne fonctionnent que si le CNI les prend en charge. Sans NetworkPolicy, le trafic intra‑cluster est par défaut libre (Allow all).

Principes

Adoptez une posture „deny by default“ par namespace : autorisez uniquement les connexions nécessaires (par ex. Frontend→Backend, Monitoring→Exporters). Cela réduit la mobilité latérale en cas de compromission.

Prérequis

Vérifiez votre CNI :

kubectl get pods -n kube-system -o wide

Recherchez des noms de pods Calico, Cilium ou Weave. Si votre CNI ne prend pas en charge NetworkPolicy, prévoyez un changement de CNI ou l’utilisation d’équipements réseau complémentaires.

Exemple : deny par défaut et autorisation ciblée

Deny par défaut pour le trafic entrant dans le namespace :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: app
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Autoriser seulement depuis les pods frontend vers le service backend :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Vérification et débogage

Testez la connectivité avec un pod temporaire :

kubectl run --rm -it --image=busybox nettest -- /bin/sh
# im Pod
# telnet backend 8080 oder nc -zv backend 8080

Si vous attendez une connectivité et qu’elle est absente : vérifiez les ressources NetworkPolicy, les labels et les logs du CNI. Erreurs fréquentes : labels mal appliqués, namespaces non pris en compte ou policies qui ne gèrent que l’Ingress alors qu’il faut également contrôler l’Egress.

OPA Gatekeeper : gérer centralement les politiques d’admission

Open Policy Agent (OPA) est un moteur de politiques générique ; Gatekeeper est un contrôleur Kubernetes qui intègre OPA comme Admission Controller. Avec Gatekeeper, vous écrivez des règles spécifiques à l’entreprise (Constraints) qui sont évaluées avant la persistance des ressources.

Pourquoi Gatekeeper en complément de PSA et des NetworkPolicies

PSA fournit des profils de sécurité de pod prédéfinis ; Gatekeeper permet des règles flexibles et spécifiques à l’organisation (par ex. „Seules les registries internes autorisées“, „Pas de hostPath pour les équipes non‑Ops“). Gatekeeper peut aussi exécuter des audits sur les ressources existantes.

Installation (en bref)

Gatekeeper peut être installé via Helm ou manifest. Exemple avec Helm :

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install gatekeeper/gatekeeper --name-template gatekeeper --namespace gatekeeper --create-namespace

Exemple : ConstraintTemplate et Constraint (pas un tutoriel Rego complet)

ConstraintTemplate définit le schéma ; Constraint active la règle avec des paramètres. Exemple : interdire privileged: true dans PodSpec.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8snoPrivileged
spec:
  crd:
    spec:
      names:
        kind: K8sNoPrivileged
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8snoPrivileged
      violation[{
        "msg": msg,
        "details": {"container": container_name}
      }] {
        input.review.object.spec.containers[_] as c
        c.securityContext.privileged == true
        container_name := c.name
        msg := sprintf("privileged container %v is not allowed", [container_name])
      }

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoPrivileged
metadata:
  name: disallow-privileged
spec:
  match:
    kinds:
    - apiGroups: ["" ]
      kinds: ["Pod"]

Si Gatekeeper détecte une violation, l’admission est refusée et une erreur explicative est renvoyée à l’utilisateur de l’API.

Pièges courants en exploitation

Des politiques Rego trop RESTrictives peuvent casser les pipelines CI/CD. Procédé : testez les politiques localement dans un cluster de staging, utilisez le Gatekeeper Audit Mode (recherche les objets existants) et déployez les politiques progressivement.

Analyse à l’exécution : détection des menaces en quasi‑temps réel

L’analyse à l’exécution couvre deux volets : les scans statiques d’images avant le déploiement et les agents d’exécution qui surveillent les événements sur l’hôte. Les deux sont importants : les scans d’images (Trivy, Clair) détectent les CVE connues ; les agents d’exécution (Falco, outils eBPF) repèrent les comportements anormaux tels que l’exécution de shells, des connexions réseau inhabituelles ou des écritures sur des chemins sensibles.

Pourquoi la détection à l’exécution est nécessaire

Même des images testées peuvent contenir des vulnérabilités ou être exploitées via des erreurs de configuration. Les agents d’exécution fournissent une détection en temps réel et des alertes riches en contexte pour la gestion des incidents.

Exemple : scan d’image avec Trivy

trivy image --severity HIGH,CRITICAL --ignore-unfixed myregistry.local/myapp:1.2.3

Résultat : utilisez la sortie pour bloquer des builds ou créer des tickets dans le système de ticketing.

Exemple : Falco pour les alertes d’exécution

Falco surveille les appels système et peut être installé dans Kubernetes en tant que DaemonSet. Extrait d’une règle d’exemple (simplifiée) qui alerte sur execve dans les conteneurs :

- rule: Detect Shell in Container
  desc: Shell executed in a container
  condition: evt.type = execve and container.id != host
  output: "Shell or suspicious exec in container (user=%user.name container=%container.name cmd=%proc.cmdline)"
  priority: WARNING

Installation via Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --namespace falco --create-namespace

Intégration à la supervision et à la gestion des incidents

Envoyez les alertes Falco vers SIEM/Alertmanager/Slack. Définissez des playbooks pour les alertes typiques (par ex. „exécution dans un conteneur de production“) : arrêter la tâche du conteneur, isoler le Pod (modifier la NetworkPolicy), prendre un snapshot et sauvegarder les données de forensique.

Séquence de mise en œuvre concrète et plan de vérification

Ordre recommandé pour l’introduction en production :

1. Analyse de la ligne de base: inventaire de tous les Namespaces, Workloads, type de CNI.
2. Activer initialement Pod Security Admission en mode audit. Recueillez les violations.
3. Intégrer le scan d’images dans le CI (Trivy) et marquer les builds échoués.
4. Déployer progressivement les NetworkPolicies selon le principe du moindre privilège (démarrer par les namespaces non critiques).
5. Développer des politiques Gatekeeper et les exécuter en mode audit.
6. Déployer Falco ou un agent runtime équivalent en tant que DaemonSet, intégrer les alertes dans le SIEM.
7. Stabiliser l’application (PSA enforce, NetworkPolicies active deny, Gatekeeper enforce) et le monitoring.

Étapes de vérification typiques

Effectuez ces vérifications avant d’activer l’enforcement :

• Liste des pods avec des paramètres risqués (privileged, hostPath) :

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | {ns:.metadata.namespace, pod:.metadata.name}'

• Vérifiez que les NetworkPolicies autorisent les connexions souhaitées : pods de test temporaires pour les vérifications de connectivité.
• Audit Gatekeeper : vérifiez les CR de violation que Gatekeeper crée.

Stratégie de rollback et d’urgence

Les systèmes de sécurité peuvent perturber l’exploitation. Prévoyez les chemins de repli suivants :

• PSA : la suppression du label de namespace désactive l’enforcement pour ce namespace.
• NetworkPolicies : un default‑deny peut être supprimé via kubectl delete ; prévoyez une policy temporaire „allow all“.
• Gatekeeper : utilisez kubectl patch/scale pour désactiver temporairement Gatekeeper si nécessaire (mais uniquement en dernier recours).
• Agent runtime : désactivez temporairement les alertes si elles génèrent des faux positifs massifs, mais conservez les logs.

Runbook d’urgence (résumé)

1. En cas de blocages massifs, examinez les logs d’audit récents (PSA/Gatekeeper) et identifiez la policy.
2. Si un job critique est stoppé : supprimez le label du namespace ou désactivez temporairement des objets Constraint individuels.
3. Communication : informez les équipes concernées, effectuez un deploy‑hotfix et documentez la cause.
4. Post‑mortem : ajuster la policy, étendre les tests, effectuer le contrôle de changement.

Connaissances opérationnelles, dépannage et bonnes pratiques

Conseils pragmatiques issus de l’exploitation :

• Versioning : gérez les policies (Gatekeeper ConstraintTemplates, fichiers YAML NetworkPolicy) comme du code dans Git et validez‑les via CI.
• Tests : testez les policies automatiquement contre des workloads de référence (namespace canary).
• Observability : centralisez et corrélez les audit‑logs, les logs CNI, les alertes Falco et kube‑audit.
• Principe du moindre privilège : commencez avec des paramètres par défaut plus RESTrictifs pour les nouveaux namespaces ; traitez les services anciens comme du legacy avec des exceptions documentées.
• Documentation : les chemins d’urgence, qui retire les labels ou désactive Gatekeeper, et l’approbation des changements sont des exigences opérationnelles.

Aspects de performance et de scalabilité

La mise en sécurité a un coût. PSA lui‑même génère peu de latence, car il effectue des vérifications légères. En revanche, Gatekeeper exécute des évaluations Rego à chaque admission ; sous un taux de déploiement élevé, cela peut engendrer de la latence ou une charge CPU dans le chemin API. Prévoyez donc des requests/limits de ressources pour Gatekeeper et surveillez la latence du serveur API (métrique kube‑apiserver : apiserver_request_duration_seconds).

NetworkPolicies werden vom CNI umgesetzt: Calico kann iptables/ipsets oder eBPF nutzen; Cilium arbeitet nativ mit eBPF. eBPF‑basierte Enforcement‑Mechanismen haben in der Regel geringere Latenz und bessere Skalierung, kosten aber Kernel‑Unterstützung und eine aktuelle Distribution. Prüfen Sie CPU‑/Netz‑Performance vor und nach Rollout mit Lasttests auf Test‑Cluster.

Handling von False‑Positives und Regeln optimieren

False‑Positives sind ein Betriebsrisiko. Vorgehen:

1. Policy im Audit‑Mode laufen lassen und Violations sammeln.
2. Analysieren Sie Context (Pod, Benutzer, Image) und entscheiden dann: Regel anpassen oder explizite Ausnahme dokumentieren.
3. Regeländerungen testen in Staging, dann schrittweise promoten.

Beispiele zur Analyse von Falco‑Alerts: Ermitteln Sie das auslösende syscall‑Pattern, prüfen Sie die Prozess‑Kette mit kubectl logs und exec und ergänzen Sie die Falco‑Regel um Ausnahmekriterien statt Regeln global zu deaktivieren.

Host‑ und Hardware‑Betrieb: Kernel, eBPF und Ressourcen

Bei Runtime‑Schutz ist der Host wichtig: eBPF‑Tools benötigen Kernel‑Support (4.9+ mit eBPF‑Backports oder neuere Distributionen). Prüfen Sie Kernel‑Versionen und Module. Auf Hosts mit hoher Containerd‑Dichte sollten Sie auf I/O‑Limits achten, denn Forensik‑Snapshots können leistungsintensiv werden.

Praktischer Check: Kernel‑Version prüfen und eBPF‑Support validieren:

uname -r
# eBPF: prüfen ob bpftool vorhanden
bpftool version || echo "bpftool not installed"

Wenn eBPF fehlen sollte, planen Sie Kernel‑Updates oder alternative Agenten wie Falco im syscall‑Mode ein. Dokumentieren Sie die nötigen Host‑Packages und führen Sie Rolling‑Kernel‑Upgrades mit Live‑Kernel‑Strategie durch, um Ausfallzeiten zu vermeiden.

Audit‑Logging und Forensik: Was gesammelt werden sollte

Sammeln Sie folgende Artefakte für schnelle Reaktion und Post‑Mortem:

• kube‑apiserver Audit Logs (Audit‑Policy konfiguriert).
• CNI Logs und Netflow‑Spuren für laterale Bewegungen.
• Falco/Zabbix/Prometheus Alerts und vollständige Events mit Zeitstempel.
• Container Logs und ein Snapshot des betroffenen Filesystems.

Snapshot Beispiel: Erstellen Sie kontrolliert ein tar‑Archiv für Forensik (nur wenn Sie Speicher und I/O beachten):

kubectl exec -n ns pod -- tar -czf /tmp/fs-snapshot.tar.gz -C / --exclude=/proc --exclude=/sys --exclude=/dev
kubectl cp ns/pod:/tmp/fs-snapshot.tar.gz ./fs-snapshot.tar.gz

Bewahren Sie Snapshots sicher auf, signieren Sie Metadaten und halten Sie Korrelationen mit Timestamps bereit.

Kompatibilitäten und Integrationen

Wichtige Integrationspunkte, die Sie planen sollten:

• CI/CD: Image‑Scanning (Trivy) als Build‑Gate, Gatekeeper als Pre‑Apply Gate.
• Registries: Signierte Images und erlaubte Registry‑Listen via Gatekeeper erzwingen.
• Monitoring/SIEM: Falco → Alertmanager/SIEM, CNI‑Logs → Elastic/Kafka.
• Secrets‑Management: Vermeiden Sie direkte Secrets in Manifests; integrieren Sie ExternalSecrets/Vault.

Fazit: Pragmatismus vor Perfektion

La sécurisation de Kubernetes est un processus multicouches : Pod Security Admission, NetworkPolicies, OPA Gatekeeper et Runtime‑Scanning se complètent. Il est important de procéder par étapes avec des phases d’audit, des tests automatisés et des règles de rollback claires. Priorisez les mesures selon la surface d’attaque et le coût opérationnel : de petits investissements dans la PSA et les NetworkPolicies apportent souvent une réduction de risque immédiatement perceptible ; Gatekeeper et les Runtime‑Scanner améliorent sur le long terme la gouvernance et la détection.

L’opérationnalisation est décisive : des policies versionnées, des playbooks pour les incidents et des zones de test surveillées évitent que les mesures de sécurité n’affectent l’exploitation. Planifiez des tests de performance et des contrôles hôtes (kernel, eBPF) avant d’activer en production des fonctionnalités dépendantes d’eBPF.

Contrôles complémentaires (liste courte à emporter)

• Kubectl : vérifiez la présence de conteneurs privilégiés, hostPath, hostNetwork.
• CNI : confirmez le support de NetworkPolicy.
• CI : intégrer un scanner d’images dans la pipeline.
• Gatekeeper : exécuter les policies en mode audit, vérifier les violations.
• Runtime : déployer Falco ou un agent eBPF et router les alertes vers le SIEM.

Le Runtime‑Scanning est également important pour ce sujet. L’article remet ces aspects en contexte de façon claire et montre ce qui compte au quotidien.