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
Outils open source — Gratuits, portables, hors ligne
Caractéristiques communes
100 % hors ligne — aucune donnée transmise
Portables — un seul fichier exécutable
Gratuits — MIT ou GPL v3
Code source ouvert sur GitHub
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.

Academy Contact

seccomp

cloud

Définition

Seccomp (Secure Computing Mode) est un mécanisme de sécurité du noyau Linux permettant de restreindre les appels système (syscalls) qu'un processus peut effectuer. En Kubernetes, les profils seccomp limitent les syscalls disponibles pour les conteneurs, réduisant drastiquement la surface d'attaque en empêchant l'exploitation de vulnérabilités noyau via des syscalls non nécessaires. Seccomp fonctionne en mode filtre : un programme BPF (Berkeley Packet Filter) définit quels syscalls sont autorisés, refusés (avec SIGSYS ou retour EPERM), ou tracés. Les profils seccomp en Kubernetes sont des fichiers JSON listant les syscalls autorisés (whitelist) ou refusés (blacklist). Le profil RuntimeDefault (fourni par le container runtime comme containerd) autorise les syscalls nécessaires à la plupart des applications conteneurisées et est activé par défaut dans Kubernetes 1.27+. Les profils seccomp dans Kubernetes se configurent via le champ securityContext.seccompProfile dans les PodSpec. Trois valeurs sont possibles : RuntimeDefault (profil du container runtime, recommandé comme minimum), Localhost (profil personnalisé stocké sur le nœud dans /var/lib/kubelet/seccomp/), et Unconfined (aucun filtrage - déconseillé). Les Pod Security Standards Kubernetes imposent RuntimeDefault ou Localhost pour le profil Restricted. La création de profils seccomp personnalisés pour une application spécifique nécessite d'identifier les syscalls réellement utilisés. L'outil SeccompProfilerOperator Kubernetes automatise ce processus : il enregistre les syscalls utilisés par une application pendant son exécution, puis génère un profil minimal. Des outils comme inspektor-gadget et Tetragon permettent aussi cette découverte de syscalls. Les attaques Kubernetes ciblant les vulnérabilités du noyau (container escape via kernel exploits) utilisent souvent des syscalls qui ne sont pas nécessaires pour les applications normales : ptrace pour le debugging de processus, pivot_root ou clone pour la manipulation des namespaces, et mount pour monter des filesystems. Un profil seccomp restrictif bloque ces syscalls, rendant ces attaques beaucoup plus difficiles même si le conteneur est compromis.

Activation de seccomp dans Kubernetes

Activez RuntimeDefault comme profil seccomp par défaut pour tous les pods (Kubernetes 1.27+ le supporte via --seccomp-default sur le kubelet). Ajoutez la directive dans le securityContext de chaque pod (seccompProfile.type: RuntimeDefault) via Kyverno mutation policy pour les déploiements existants. Utilisez audit2seccomp pour convertir les logs d'audit seccomp en profils. Le passage de Unconfined à RuntimeDefault est une amélioration sécurité immédiate sans impact applicatif dans 95% des cas.

Profils personnalisés pour les applications sensibles

Pour les applications critiques, créez des profils seccomp minimaux : deployez l'application avec un profil SCMP_ACT_LOG (log sans bloquer) pendant quelques jours, collectez les syscalls utilisés via les logs système, générez un profil whitelist minimal avec SeccompProfilerOperator ou manuellement, testez le profil en mode log-only puis en mode enforce. Un profil minimal peut réduire les syscalls disponibles de 400+ à 50-80, réduisant considérablement la surface d'attaque noyau.

seccomp vs AppArmor vs capabilities

Ces trois mécanismes sont complémentaires. seccomp filtre les syscalls (quelles opérations le processus peut demander au kernel). AppArmor filtre les accès aux ressources (quels fichiers, réseaux, capabilities un processus peut utiliser). Capabilities Linux décompose les privileges root en capacités granulaires accordées individuellement. Utilisez les trois ensemble pour une défense en profondeur : seccomp pour la restriction syscall, AppArmor pour les accès ressources, et capabilities.drop: ALL avec ajout minimal pour le contrôle des privileges.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis