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.

capDrop Kubernetes

cloud

Définition

capDrop est une directive Kubernetes dans le securityContext permettant de supprimer des Linux Capabilities spécifiques des conteneurs. Les Linux Capabilities décomposent les privilèges root en unités distinctes (NET_RAW, SYS_PTRACE, NET_ADMIN, etc.). La bonne pratique est capabilities.drop: ["ALL"] combinée avec capabilities.add pour les seules capabilities strictement nécessaires. Les capabilities dangereuses à éviter dans les conteneurs : SYS_ADMIN (la capability fourre-tout permettant potentiellement l'évasion de conteneur), NET_ADMIN (modification des règles réseau et interfaces), NET_RAW (raw sockets permettant les attaques ARP spoofing et le sniffing), et SYS_PTRACE (injection de code dans des processus d'autres namespaces). La configuration du securityContext recommandée par les Pod Security Standards Restricted impose capabilities.drop: ["ALL"], runAsNonRoot: true, readOnlyRootFilesystem: true, et allowPrivilegeEscalation: false. Cette configuration forme le baseline de sécurité que tout conteneur de production devrait respecter. Les capability sets dans les conteneurs incluent le set permis (Permitted), le set effectif (Effective), et le set héritable (Inheritable). Docker accorde par défaut un sous-ensemble de capabilities incluant NET_RAW, CHOWN, et MKNOD qui représentent une surface d'attaque inutile pour les applications web standard. L'audit des capabilities en production peut se faire avec kubectl-cap ou directement via kubectl get pods -o jsonpath inspecant les securityContext. Des outils CSPM comme Wiz, Orca, et Prisma Cloud auditent automatiquement les capabilities et alertent sur les pods utilisant SYS_ADMIN ou NET_ADMIN, capabilities souvent présentes dans les clusters par erreur de configuration.

Configuration capDrop ALL recommandée

Configuration securityContext standard pour tous les pods non-privilegiés : capabilities.drop: ["ALL"], runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false. Ajoutez capabilities.add: [NET_BIND_SERVICE] uniquement pour les serveurs web non-root écoutant sur le port 80/443. Imposez cette configuration via Kyverno ClusterPolicy mutation pour tous les pods sans securityContext explicite.

Capabilities dangereuses et container escape

SYS_ADMIN facilite les container escapes : avec cette capability, un attaquant peut monter des filesystems (mount()), manipuler les namespaces, et accéder aux ressources kernel généralement inaccessibles depuis un conteneur. NET_ADMIN permet des attaques réseau affectant les autres pods sur le même nœud (ARP spoofing, redirection de trafic). La suppression de toutes les capabilities via capDrop ALL combinée avec seccomp RuntimeDefault et AppArmor crée une défense en profondeur efficace contre les container escapes.

Audit Kubernetes des capabilities

Identifiez les pods avec capabilities dangereuses : kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name} {range .spec.containers[*]}{.securityContext.capabilities.add}{end}{"\n"}{end}' | grep -E 'SYS_ADMIN|NET_ADMIN|NET_RAW'. Priorisez le hardening de ces pods. Dans GKE, activez GKE Security Posture qui signale automatiquement les capabilities dangereuses dans le dashboard de sécurité GKE.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis