Le baseline de sécurité Kubernetes aligné CIS que nous livrons dès le premier jour

La plupart des clusters Kubernetes en production n'ont pas été durcis — ils ont été déployés. Paramètres par défaut, permissions de service account par défaut, pas de policies d'admission, pas de network policies, pas d'audit log. Ils fonctionnent. Ils passent aussi un pen test basique en environ 12 minutes.

Voici le baseline de sécurité que nous livrons dès le premier jour pour chaque cluster que nous gérons. Aligné CIS Kubernetes Benchmark, mais pragmatique.

Pod Security Standards en mode restricted

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

restricted rejette les pods qui tournent en root, autorisent l'escalade de privilèges, utilisent le host networking ou omettent seccompProfile: RuntimeDefault. Pour la petite minorité de workloads qui nécessitent des privilèges élevés (un driver CSI, un agent CNI), nous les plaçons dans un namespace séparé avec le profil privileged et traitons le contenu de ce namespace comme partie de la TCB du cluster.

L'article complet couvre :

• Les policies Kyverno comme code — et pourquoi nous le préférons à OPA Gatekeeper
• Signatures d'image requises et vérifiées au moment de l'admission via Cosign keyless
• NetworkPolicies default-deny — le modèle de connectivité opt-in
• Policy d'audit : capturer tout ce qui est important, alerter sur les bonnes choses
• Tokens de ServiceAccount : désactiver l'auto-mount par défaut, SA dédiés au but
• Chiffrement etcd au repos avec rotation de clés correcte

Nous déployons ce baseline dès le premier jour pour chaque client Kubernetes managé.