Kubernetes Security Vertiefung — Pod Security Admission & Secrets-Härtung

In diesem 90-Minuten-Modul verlässt ihr die Workload-lokale Sicht auf einzelne Container und wechselt zur Namespace-weiten Policy-Ebene. Los geht es mit den Pod Security Standards als Konzept: den drei Profilen privileged, baseline und restricted, und der Abgrenzung, die den Einstieg trägt – ein securityContext (aus dem Modul Anwendungsdesign bereits bekannt) wirkt pro Workload, eine Pod-Security-Policy wirkt pro Namespace und trifft jeden Pod darin, egal wer ihn einreicht. Im Hands-on setzt ihr genau dieses Bordmittel ein: Mit dem Label pod-security.kubernetes.io/enforce=restricted auf einem Namespace seht ihr live, wie ein Pod mit privileged: true und ohne runAsNonRoot vom Admission-Controller abgewiesen wird, bevor er überhaupt geplant wird – danach ordnet ihr den Unterschied zu den Modi warn und audit ein. Der dritte Block geht über Base64 hinaus, das ihr aus dem Modul Workloads & Konfiguration bereits als “kodiert, nicht verschlüsselt” kennt: Encryption at Rest für Secrets über eine EncryptionConfiguration am API-Server, als Konzept-Demo direkt gegen etcd – ohne Cloud-KMS, dazu eine Abgrenzung zu Vault/External-Secrets-Operator als eigenständigem Betriebsmodell. Zum Abschluss ein bewusster Ausblick ohne eigenes Hands-on: eingebaute Pod Security Admission gegen Policy-Engines wie Kyverno oder OPA Gatekeeper – Scope-Grenze offen benannt, ohne unbelegte Tool-Empfehlung. Das eigene, mehrstündige Hands-on-Modul dazu gibt es inzwischen: siehe Kubernetes Admission Controllers & Policy Engines — Kyverno vs. OPA Gatekeeper. Voraussetzung sind die Module “Kubernetes Administration” (RBAC/ ServiceAccounts) und “Kubernetes Anwendungsdesign” ( securityContext) – beide werden hier vorausgesetzt und nicht wiederholt. Die Session läuft weiterhin vollständig lokal über Minikube oder kind, ohne Cloud-Account und ohne Kostenwirkung.