Hardening kernel pour Kubernetes : outils et bonnes pratiques

TL;DR : Le hardening kernel kubernetes renforce la sécurité des nœuds en limitant les syscalls, en isolant les namespaces et en appliquant des profils Seccomp/AppArmor. Cette couche défensive bloque les évasions de conteneurs et réduit la surface d'attaque du cluster.

Pour maîtriser ces techniques de sécurité avancée, découvrez la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes.

Pourquoi le hardening kernel kubernetes est-il indispensable ?

Le hardening kernel kubernetes constitue la première ligne de défense contre les attaques ciblant vos clusters. Chaque conteneur partage le kernel du nœud hôte. Une faille dans ce kernel expose tous les workloads du nœud.

Selon le rapport CNCF 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive fait des clusters des cibles privilégiées. Le kernel Linux représente le dernier rempart entre un conteneur compromis et le contrôle total du nœud.

À retenir : Un conteneur n'est pas une VM. L'isolation repose sur les namespaces et cgroups du kernel, pas sur une séparation matérielle.

La sécurité kernel linux dans un contexte Kubernetes exige une approche multicouche :

Quels outils utiliser pour le hardening kernel kubernetes ?

Seccomp : filtrer les appels système

Seccomp (Secure Computing Mode) est un mécanisme kernel qui restreint les syscalls disponibles pour un processus. Kubernetes supporte nativement les profils Seccomp depuis la version 1.19.

Créez un profil Seccomp personnalisé :

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "exit", "exit_group", "futex"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Appliquez ce profil à un pod :

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/custom-seccomp.json
  containers:
  - name: app
    image: nginx:1.25

Le profil RuntimeDefault bloque environ 44 syscalls dangereux comme ptrace, mount et reboot. Utilisez-le systématiquement en production.

AppArmor : confiner les applications

AppArmor est un module de sécurité Linux qui restreint les capacités des programmes via des profils. Chaque profil définit les fichiers accessibles, les capacités réseau et les opérations autorisées.

Exemple de profil AppArmor pour un conteneur Nginx :

#include <tunables/global>

profile nginx-container flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/nginx>
  
  /var/www/** r,
  /etc/nginx/** r,
  /var/log/nginx/** rw,
  
  deny /proc/** w,
  deny /sys/** w,
}

Chargez et appliquez le profil :

sudo apparmor_parser -r /etc/apparmor.d/nginx-container

Référencez-le dans votre pod :

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/nginx-container

À retenir : AppArmor fonctionne en mode « liste blanche ». Tout ce qui n'est pas explicitement autorisé est refusé.

Pour approfondir ces configurations, consultez notre guide sur la Sécurité Kubernetes.

SELinux : contrôle d'accès obligatoire

SELinux (Security-Enhanced Linux) implémente le MAC (Mandatory Access Control). Contrairement aux permissions Unix classiques, SELinux applique des politiques définies par l'administrateur, indépendamment du propriétaire du fichier.

Configurez le contexte SELinux pour un pod :

spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
      type: "container_t"

Comment implémenter le hardening kernel kubernetes en production ?

Étape 1 : auditer la configuration actuelle

Exécutez kube-bench pour évaluer la conformité de vos nœuds :

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Kube-bench vérifie la conformité aux benchmarks CIS pour Kubernetes. Il identifie les configurations kernel vulnérables.

Étape 2 : durcir les paramètres sysctl

Certains paramètres kernel améliorent la sécurité des nœuds. Configurez ces sysctls sur chaque nœud :

# Protection contre les attaques SYN flood
net.ipv4.tcp_syncookies = 1

# Désactiver l'IP forwarding si non nécessaire
net.ipv4.ip_forward = 0

# Protection contre le spoofing
net.ipv4.conf.all.rp_filter = 1

# Ignorer les paquets ICMP broadcast
net.ipv4.icmp_echo_ignore_broadcasts = 1

Kubernetes permet de configurer certains sysctls au niveau du pod :

spec:
  securityContext:
    sysctls:
    - name: net.core.somaxconn
      value: "1024"

À retenir : Seuls les sysctls « safe » sont autorisés par défaut. Les « unsafe » sysctls nécessitent une configuration explicite du kubelet.

Étape 3 : activer le mode RuntimeDefault

Modifiez la configuration du kubelet pour appliquer Seccomp par défaut :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
seccompDefault: true

Cette configuration applique le profil RuntimeDefault à tous les pods sans profil explicite.

Étape 4 : déployer un runtime sandbox

Pour les workloads sensibles, utilisez gVisor ou Kata Containers. Ces runtimes ajoutent une couche d'isolation entre le conteneur et le kernel hôte.

Installez gVisor :

curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
sudo apt-get update && sudo apt-get install -y runsc

Configurez containerd pour utiliser gVisor :

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"

Créez une RuntimeClass :

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

Le rapport Spectro Cloud 2025 révèle que les équipes IT passent en moyenne 34 jours par an à résoudre des problèmes Kubernetes. Un kernel durci réduit significativement les incidents de sécurité.

Quelles bonnes pratiques adopter pour la sécurité kernel linux ?

Principe du moindre privilège

Supprimez toutes les capabilities Linux non nécessaires :

spec:
  containers:
  - name: app
    securityContext:
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE

Cette configuration retire toutes les capabilities puis ajoute uniquement celles requises.

Empêcher l'escalade de privilèges

Bloquez l'escalade de privilèges au niveau du pod :

spec:
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 1000
      readOnlyRootFilesystem: true

Selon Orca Security 2025, 70% des organisations utilisent Kubernetes dans le cloud, la plupart avec Helm. Vérifiez les charts Helm pour vous assurer qu'ils respectent ces bonnes pratiques.

Surveiller les événements kernel

Déployez Falco pour la détection d'intrusion au niveau kernel :

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

Falco utilise eBPF pour intercepter les appels système et détecter les comportements suspects :

- rule: Terminal shell in container
  desc: Detect shell execution in container
  condition: >
    spawned_process and container and
    shell_procs and proc.tty != 0
  output: "Shell spawned in container (user=%user.name container=%container.name)"
  priority: WARNING

Consultez notre Formation Kubernetes : Guide Complet pour une vue d'ensemble des compétences essentielles.

Comment valider le hardening kernel kubernetes ?

Tests de pénétration automatisés

Utilisez kubescape pour scanner vos configurations :

kubescape scan framework nsa --exclude-namespaces kube-system

Vérification des profils Seccomp

Testez qu'un syscall est bien bloqué :

kubectl exec -it secure-pod -- strace -f ls 2>&1 | grep EPERM

Audit continu avec OPA Gatekeeper

Créez une contrainte pour imposer Seccomp :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sSeccompProfile
metadata:
  name: require-seccomp
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    allowedProfiles:
    - runtime/default
    - localhost/*

À retenir : L'audit automatisé garantit que les nouvelles ressources respectent les politiques de sécurité. Intégrez ces vérifications dans votre pipeline CI/CD.

Quels sont les défis du hardening kernel dans les environnements multi-tenants ?

Les clusters partagés amplifient les risques. Un locataire compromis peut potentiellement affecter les autres.

Stratégies pour le multi-tenant :

Appliquez les Pod Security Standards au niveau namespace :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Le niveau restricted impose les configurations les plus sécurisées : non-root, pas de capabilities, Seccomp activé.

Le marché Kubernetes passera de 2,57 milliards USD en 2025 à 8,41 milliards en 2031. Cette croissance s'accompagne d'exigences de sécurité accrues.

Prochaines étapes pour renforcer la sécurité de vos clusters

Le hardening kernel représente un pilier de la Sécurité Kubernetes. Combiné aux network policies, au RBAC et à la sécurité des images, il crée une défense en profondeur robuste.

Actions immédiates :

1. Activez Seccomp RuntimeDefault sur tous vos clusters
2. Déployez Falco pour la détection d'intrusion
3. Auditez avec kube-bench et corrigez les écarts
4. Formez vos équipes aux pratiques de sécurité kernel

La formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes couvre en profondeur le hardening kernel, les profils Seccomp, AppArmor et les techniques de détection d'intrusion. Cette formation de 4 jours prépare à la certification CKS (Certified Kubernetes Security Specialist).

Pour les équipes débutant avec Kubernetes, la formation Kubernetes les fondamentaux offre une introduction solide avant d'aborder les sujets de sécurité avancés.

Contactez nos conseillers pour construire un parcours de formation adapté aux besoins de sécurité de votre organisation.