Sécurité Kubernetes : Guide de Durcissement pour l’Entreprise

Pourquoi la sécurité Kubernetes est critique

Kubernetes apporte vitesse et flexibilité, mais il augmente aussi la surface d’attaque : API, kubelet, images, registres, secrets, réseau inter-pods et droits utilisateurs. En PME, l’erreur la plus fréquente est simple : cluster fonctionnel, mais politiques de sécurité incomplètes. Résultat : un incident banal devient un incident majeur.

La bonne approche est pragmatique : on ne cherche pas la perfection théorique, on réduit d’abord les risques qui ont le plus d’impact en production.

Plan d’action sécurité Kubernetes en 30 jours

Semaine 1 : couper les risques évidents

• Activer l’authentification forte et nettoyer les comptes inactifs.
• Auditer les ClusterRoleBinding à privilèges élevés.
• Forcer des images depuis registres autorisés.

Semaine 2 : isolation et politiques

• Mettre en place une politique default deny réseau par namespace.
• Appliquer les standards de sécurité Pod (mode baseline/restricted).
• Bloquer les conteneurs privilégiés non justifiés.

Semaine 3 : secrets et supply chain

• Sortir les secrets sensibles des manifests statiques.
• Scanner les images avant déploiement.
• Signer les images critiques et tracer la provenance.

Semaine 4 : audit et routine opérationnelle

• Activer ou durcir l’audit log API.
• Définir 6 à 10 alertes sécurité exploitables.
• Formaliser un runbook incident sécurité.

Accès et RBAC : réduire le blast radius

Le RBAC doit suivre le principe du moindre privilège. Un rôle trop large sur un namespace de prod suffit à compromettre la plateforme.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-readonly
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]

kubectl get clusterrolebinding
kubectl auth can-i create pods --as system:serviceaccount:production:default -n production

Complète ce travail avec un inventaire régulier des comptes techniques et des ServiceAccounts utilisés.

Isolation réseau : fermer par défaut, ouvrir explicitement

Sans NetworkPolicy, le trafic latéral est souvent trop permissif. Il faut fermer par défaut puis autoriser les flux nécessaires.

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

Si tu veux aller plus loin sur l’exploitation, regarde aussi notre guide Kubernetes monitoring en production.

Sécurité des pods : baseline minimale en production

Un pod sécurisé en prod doit au minimum :

• tourner sans root,
• désactiver l’escalade de privilèges,
• réduire les capabilities Linux,
• utiliser un filesystem en lecture seule si possible.

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Secrets : éviter les fuites silencieuses

Les secrets Kubernetes en base64 ne sont pas chiffrés fonctionnellement pour l’usage quotidien. Ils doivent être protégés à plusieurs niveaux :

• chiffrement au repos côté etcd,
• rotation périodique,
• droits RBAC stricts sur secrets,
• pas de secret en clair dans CI/CD.

Pour les environnements sensibles, externalise avec un gestionnaire dédié (Vault, cloud secret manager) et garde Kubernetes comme point de consommation.

Audit, logs et détection : ce qui doit remonter en premier

Ton système de détection doit remonter vite les actions risquées :

• création de ressources privilégiées,
• usage anormal de comptes de service,
• exec shell dans pods sensibles,
• changement de rôles RBAC critiques.

kubectl get events -A --sort-by=.lastTimestamp
kubectl logs -n kube-system -l component=kube-apiserver --tail=200

Ajoute un runbook court : qui décide, qui isole, qui communique, qui valide le retour en prod.

Checklist finale sécurité Kubernetes

• ☐ RBAC nettoyé, droits admin limités
• ☐ NetworkPolicy active sur namespaces critiques
• ☐ Pods root/privilégiés traités ou justifiés
• ☐ Secrets audités et rotation planifiée
• ☐ Scan image avant déploiement CI/CD
• ☐ Audit log exploitable + alertes prioritaires
• ☐ Runbook incident sécurité testé

FAQ sécurité Kubernetes