Zum Inhalt springen
_CORE
KI & Agentensysteme Unternehmensinformationssysteme Cloud & Platform Engineering Datenplattform & Integration Sicherheit & Compliance QA, Testing & Observability IoT, Automatisierung & Robotik Mobile & Digitale Produkte Banken & Finanzen Versicherungen Öffentliche Verwaltung Verteidigung & Sicherheit Gesundheitswesen Energie & Versorgung Telko & Medien Industrie & Fertigung Logistik & E-Commerce Retail & Treueprogramme
Referenzen Technologien Blog Know-how Tools
Über uns Zusammenarbeit Karriere
CS EN DE
Lassen Sie uns sprechen

Pod Security Standards — Kubernetes

17. 05. 2024 Aktualisiert: 27. 03. 2026 1 Min. Lesezeit intermediate

Pod Security Standards definieren drei Sicherheitsstufen: Privileged (ohne Einschraenkungen), Baseline (Minimum) und Restricted (am strengsten). Sie ersetzen die frueher verwendete PodSecurityPolicy, die in Kubernetes 1.25 entfernt wurde. PSS sind direkt in Kubernetes als Pod Security Admission Controller integriert — keine externen Tools erforderlich. Die richtige Konfiguration schraenkt die Auswirkungen einer Container-Kompromittierung erheblich ein.

Stufen

  • Privileged: Keine Einschraenkungen — der Container kann alles tun, einschliesslich Zugriff auf Host-Namespace und Geraete. Nur fuer Systemkomponenten und Infrastruktur-Workloads (CNI-Plugins, CSI-Treiber).
  • Baseline: Blockiert bekannte Privilege-Escalation-Vektoren — verbietet hostNetwork, hostPID, privilegierten Modus und gefaehrliche Capabilities. Mindeststandard fuer alle Workloads.
  • Restricted: Gehaertete Best Practices fuer die Produktion — erzwingt non-root User, schreibgeschuetztes Root-Dateisystem, drop ALL Capabilities, seccomp-Profile. Der Container laeuft mit minimalen Berechtigungen.

Enforcement

# Namespace Label
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Die drei Modi koennen kombiniert werden: enforce lehnt nicht konforme Pods ab, warn zeigt Warnungen beim kubectl-Deploy und audit schreibt ins Audit-Log. Empfohlene Vorgehensweise: Beginnen Sie mit warn+audit auf Restricted-Ebene, beheben Sie nicht konforme Workloads und aktivieren Sie erst dann enforce. So vermeiden Sie unerwartete Ausfaelle bei der Bereitstellung.

Migration von PodSecurityPolicy

Wenn Sie von PSP migrieren, zeigt der Audit-Modus, welche Workloads den Restricted-Standard nicht erfuellen wuerden. Typische Probleme: Container, die als Root laufen, fehlendes seccomp-Profil, unnoetige Capabilities. Beheben Sie das Dockerfile (USER nonroot) und die Kubernetes-Manifeste (securityContext) vor der Aktivierung des Enforcements.

Wichtigste Erkenntnis

Restricted fuer die Produktion, Baseline als absolutes Minimum fuer jeden Workload. Enforcement auf Namespace-Ebene. Jeder neue Namespace sollte von Anfang an PSS-Labels haben.

securitykubernetespod security
Teilen:

CORE SYSTEMS Team

Wir bauen Kernsysteme und KI-Agenten, die den Betrieb am Laufen halten. 15 Jahre Erfahrung mit Enterprise-IT.