Das CIS-orientierte Kubernetes-Sicherheits-Baseline, das wir am ersten Tag ausliefern

Die meisten Kubernetes-Cluster in Produktion wurden nicht gehärtet — sie wurden deployt. Standardeinstellungen, Standard-ServiceAccount-Berechtigungen, keine Admission-Policies, keine Network Policies, kein Audit-Log. Sie funktionieren. Sie überstehen auch einen einfachen Pen-Test in etwa 12 Minuten.

Dies ist das Sicherheits-Baseline, das wir am ersten Tag für jeden Cluster ausliefern, den wir verwalten. CIS-Kubernetes-Benchmark-orientiert, aber pragmatisch.

Pod Security Standards im restricted-Modus

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 weist Pods ab, die als Root laufen, Privilege-Escalation erlauben, Host-Networking nutzen oder seccompProfile: RuntimeDefault auslassen. Für die kleine Minderheit von Workloads, die erweiterte Privilegien benötigen (ein CSI-Treiber, ein CNI-Agent), legen wir sie in einen separaten Namespace mit dem privileged-Profil und behandeln den Inhalt dieses Namespaces als Teil der TCB des Clusters.

Der vollständige Beitrag behandelt:

• Kyverno-Policies als Code — und warum wir es OPA Gatekeeper vorziehen
• Erforderliche Image-Signaturen, am Admission-Zeitpunkt via Cosign Keyless verifiziert
• Default-Deny-NetworkPolicies — das Opt-in-Konnektivitätsmodell
• Audit-Policy: alles Wichtige erfassen, auf die richtigen Dinge alarmieren
• ServiceAccount-Tokens: das standardmäßige Auto-Mounting deaktivieren, zweckspezifische SAs
• etcd-Verschlüsselung at-rest mit korrekter Schlüsselrotation

Wir deployen dieses Baseline am ersten Tag für jeden gemanagten Kubernetes-Kunden.