AppArmor et SELinux : sécuriser les workloads Kubernetes

AppArmor Kubernetes et SELinux constituent les deux piliers de la sécurité des conteneurs au niveau système. Ces technologies de Mandatory Access Control (MAC) restreignent les actions des processus au-delà des permissions Unix classiques. Un conteneur compromis se retrouve confiné dans un périmètre strict, limitant l'impact d'une exploitation.

TL;DR : Déployez des profils AppArmor pour chaque workload sensible. Utilisez SELinux sur les distributions RHEL/CentOS. Combinez ces mécanismes avec les Pod Security Standards pour une défense en profondeur.

Les professionnels qui veulent maîtriser ces compétences suivent la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes.

Qu'est-ce qu'AppArmor et pourquoi l'utiliser avec Kubernetes ?

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

Kubernetes supporte nativement AppArmor depuis la version 1.4. Cette intégration permet d'appliquer des profils à chaque conteneur individuellement.

Selon le CNCF Annual Survey 2025, 82% des organisations exécutent Kubernetes en production. Chaque conteneur sans profil de sécurité représente un vecteur d'attaque potentiel.

À retenir : AppArmor confine les processus conteneurisés. Un profil restrictif empêche l'accès aux fichiers système sensibles même si le conteneur est compromis.

Comment configurer AppArmor Kubernetes pour vos pods ?

L'application d'un profil AppArmor kubernetes s'effectue via des annotations sur le pod ou le conteneur.

Vérifier la disponibilité d'AppArmor

# Vérifier le module AppArmor sur les nodes
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'

# Sur un node, vérifier les profils chargés
cat /sys/module/apparmor/parameters/enabled
aa-status

Créer un profil AppArmor personnalisé

# /etc/apparmor.d/k8s-restricted
#include <tunables/global>

profile k8s-restricted flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  # Refuser l'accès aux montages sensibles
  deny /proc/** w,
  deny /sys/** w,
  deny /etc/passwd w,
  deny /etc/shadow rw,
  
  # Autoriser l'accès en lecture à /app
  /app/** r,
  /app/bin/* ix,
  
  # Capabilities minimales
  capability net_bind_service,
}

Chargez le profil sur chaque node :

sudo apparmor_parser -r /etc/apparmor.d/k8s-restricted

Pour approfondir l'administration cluster Kubernetes, consultez notre guide complet.

Appliquer le profil à un pod

apiVersion: v1
kind: Pod
metadata:
  name: secured-app
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/k8s-restricted
spec:
  containers:
  - name: app
    image: myapp:v1.0
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true

À retenir : Déployez les profils AppArmor sur tous les nodes avant de les référencer dans les pods. Utilisez un DaemonSet pour automatiser le déploiement.

Comment utiliser SELinux Kubernetes sur les distributions RHEL ?

SELinux kubernetes offre une alternative à AppArmor sur les distributions Red Hat, CentOS et Fedora. Ce module MAC utilise des labels de sécurité pour contrôler les accès.

Vérifier SELinux sur les nodes

# Statut SELinux
getenforce
sestatus

# Labels des processus conteneurisés
ps -eZ | grep container

Configuration seLinuxOptions dans le securityContext

apiVersion: v1
kind: Pod
metadata:
  name: selinux-app
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
  containers:
  - name: app
    image: myapp:v1.0
    securityContext:
      seLinuxOptions:
        type: "container_t"
        level: "s0:c123,c456"

Types SELinux courants pour les conteneurs

Attention : spc_t désactive SELinux pour le conteneur. Réservez-le aux cas exceptionnels comme les agents de monitoring node-level.

Pour une formation Kubernetes complète, explorez nos parcours incluant la sécurité système.

Quand choisir AppArmor Kubernetes versus SELinux ?

Le choix entre AppArmor et SELinux dépend de votre distribution Linux et de vos compétences existantes.

Comparatif technique

Recommandations par cas d'usage

Utilisez AppArmor si :

• Vos nodes tournent sur Ubuntu/Debian
• Vous débutez avec MAC
• Vous souhaitez des profils lisibles

Utilisez SELinux si :

• Vos nodes tournent sur RHEL/CentOS
• Vous avez une expertise SELinux existante
• Vous nécessitez une isolation multi-tenant stricte

À retenir : AppArmor et SELinux sont mutuellement exclusifs sur un même node. Choisissez en fonction de votre distribution et maintenez la cohérence sur le cluster.

Consultez la sécurité Kubernetes pour une vision globale des mécanismes de protection.

Comment intégrer AppArmor Kubernetes avec les Pod Security Standards ?

Les Pod Security Standards (PSS) définissent trois niveaux de sécurité (Privileged, Baseline, Restricted). Ils complètent AppArmor sans le remplacer.

Configuration Pod Security Admission

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

Combiner PSS et AppArmor

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/k8s-restricted
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:v1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: true

Selon Spectro Cloud State of Kubernetes 2025, 82% des workloads Kubernetes sont surprovisionnés. Un securityContext strict réduit également la surface d'attaque.

Comment auditer et débugger les profils AppArmor ?

Le mode complain permet de développer des profils sans bloquer les applications.

Activer le mode complain

# Passer un profil en mode complain
aa-complain /etc/apparmor.d/k8s-restricted

# Analyser les logs d'audit
journalctl -k | grep apparmor
dmesg | grep -i apparmor

Générer un profil automatiquement

# Installer les outils
apt install apparmor-utils

# Lancer l'apprentissage
aa-genprof /app/bin/myapp

# Analyser et affiner le profil généré
aa-logprof

Tester un profil avant déploiement

# Valider la syntaxe
apparmor_parser -p /etc/apparmor.d/k8s-restricted

# Charger en mode enforce
apparmor_parser -r /etc/apparmor.d/k8s-restricted

# Vérifier le statut
aa-status | grep k8s-restricted

Pour maîtriser le dépannage Kubernetes, incluez l'analyse des logs MAC dans votre workflow.

À retenir : Développez vos profils en mode complain, analysez les logs, puis passez en enforce pour la production.

Quelles sont les bonnes pratiques AppArmor Kubernetes en production ?

Standardisez et automatisez le déploiement des profils pour garantir la cohérence sur tous les nodes.

Déploiement via DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: apparmor-loader
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: apparmor-loader
  template:
    metadata:
      labels:
        app: apparmor-loader
    spec:
      containers:
      - name: loader
        image: apparmor-profiles:v1.0
        command: ["sh", "-c", "cp /profiles/* /host/etc/apparmor.d/ && apparmor_parser -r /host/etc/apparmor.d/k8s-*"]
        volumeMounts:
        - name: apparmor-d
          mountPath: /host/etc/apparmor.d
        securityContext:
          privileged: true
      volumes:
      - name: apparmor-d
        hostPath:
          path: /etc/apparmor.d

Validation admission controller

Utilisez un webhook d'admission pour refuser les pods sans profil AppArmor :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: apparmor-validator
webhooks:
- name: validate.apparmor.k8s.io
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["pods"]

Selon le rapport CNCF Project Journey Report, 71 % des entreprises Fortune 100 exécutent Kubernetes en production. La standardisation des profils de sécurité devient critique à cette échelle.

Consultez les bonnes pratiques Kubernetes production pour compléter votre stratégie.

Checklist sécurité AppArmor et SELinux

Validez chaque point pour des workloads sécurisés :

• [ ] AppArmor/SELinux activé sur tous les nodes
• [ ] Profils personnalisés pour chaque application critique
• [ ] Mode enforce en production (pas complain)
• [ ] DaemonSet pour déploiement automatique des profils
• [ ] Validation via admission controller
• [ ] Pod Security Standards configurés (Restricted)
• [ ] Monitoring des violations MAC
• [ ] Documentation des profils et exceptions

À retenir : AppArmor et SELinux forment la dernière ligne de défense. Même si toutes les autres protections échouent, ces profils limitent les actions d'un attaquant.

Passez à l'action : formez-vous à la sécurité workloads Kubernetes

La formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes couvre AppArmor, SELinux, les Pod Security Standards et la préparation à la certification CKS. En 4 jours, maîtrisez la sécurité système des conteneurs.

Prochaines étapes :

• Découvrez les certifications Kubernetes CKA CKAD CKS
• Explorez la formation administration Kubernetes LFS458
• Consultez le calendrier des sessions

Contactez nos conseillers pour élaborer votre parcours sécurité Kubernetes sur mesure.