Kubernetes Security Hardening: Die komplette Checkliste für deutsche Unternehmen

TL;DR - Kurzfassung

Ein gehärteter Kubernetes-Cluster basiert auf vier Säulen: RBAC (wer darf was), Network Policies (wer spricht mit wem), Pod Security Standards (wie laufen Container) und Audit-Logging (was ist passiert). Deutsche Unternehmen müssen zusätzlich DSGVO- und BSI-Anforderungen erfüllen. Dieser Guide zeigt alle Schritte mit kopierbaren YAML-Beispielen.

Kubernetes bietet von Haus aus grundlegende Sicherheitsmechanismen - doch in der Standardkonfiguration ist ein Cluster nicht produktionsreif. Pods können uneingeschränkt kommunizieren, Container laufen häufig als Root, und Secrets liegen unverschlüsselt in etcd. Für Unternehmen in Deutschland, die DSGVO, BSI IT-Grundschutz oder branchenspezifische Vorgaben wie NIS2 oder KRITIS einhalten müssen, ist ein systematisches Security Hardening unverzichtbar.

Warum Security Hardening gerade jetzt kritisch ist

Die Bedrohungslage für Container-Infrastrukturen verschärft sich kontinuierlich:

• 96% aller Unternehmen nutzen oder evaluieren Kubernetes (CNCF Survey 2024)
• 67% der Cluster haben mindestens eine bekannte Fehlkonfiguration (Red Hat State of K8s Security 2025)
• NIS2-Richtlinie verpflichtet seit Oktober 2024 mehr Unternehmen zu erhöhten Sicherheitsstandards
• Die durchschnittlichen Kosten eines Container-Sicherheitsvorfalls liegen bei über 1 Mio. EUR

Säule 1: RBAC - Rollenbasierte Zugriffskontrolle richtig konfigurieren

RBAC (Role-Based Access Control) ist das Fundament jeder Kubernetes-Sicherheitsstrategie. Das Prinzip: Jeder Benutzer und jeder ServiceAccount bekommt nur die Berechtigungen, die er tatsächlich braucht.

Häufige RBAC-Fehler vermeiden

Die drei häufigsten RBAC-Fehlkonfigurationen in der Praxis:

1. cluster-admin für Entwickler - Niemals ClusterAdmin-Rechte an Entwicklerteams vergeben
2. Wildcard-Berechtigungen (* bei Verbs oder Resources) - Immer explizit definieren
3. Default ServiceAccount nutzen - Jede Anwendung braucht einen eigenen ServiceAccount

Praxis-Beispiel: Namespace-isolierte Entwicklerrolle

# Rolle: Entwickler darf in seinem Namespace Pods sehen und Logs lesen
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: team-frontend
rules:
  - apiGroups: ['']
    resources: ['pods', 'pods/log', 'services', 'configmaps']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['apps']
    resources: ['deployments']
    verbs: ['get', 'list', 'watch', 'create', 'update', 'patch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: team-frontend
subjects:
  - kind: User
    name: max.mustermann@unternehmen.de
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Praxis-Beispiel: Monitoring-ServiceAccount mit minimalen Rechten

# ServiceAccount für Prometheus - nur Leserechte auf Metriken
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-monitoring
  namespace: monitoring
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-reader
rules:
  - apiGroups: ['']
    resources: ['nodes', 'nodes/metrics', 'services', 'endpoints', 'pods']
    verbs: ['get', 'list', 'watch']
  - nonResourceURLs: ['/metrics']
    verbs: ['get']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-reader-binding
subjects:
  - kind: ServiceAccount
    name: prometheus-monitoring
    namespace: monitoring
roleRef:
  kind: ClusterRole
  name: prometheus-reader
  apiGroup: rbac.authorization.k8s.io

Tipp: Mit kubectl auth can-i --list --as=system:serviceaccount:monitoring:prometheus-monitoring können Sie die tatsächlichen Berechtigungen eines ServiceAccounts prüfen.

Säule 2: Network Policies - Netzwerksegmentierung im Cluster

Ohne Network Policies kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren - über Namespace-Grenzen hinweg. Das ist vergleichbar mit einem Firmennetzwerk ohne Firewalls.

Default-Deny-Strategie implementieren

Best Practice: Zuerst allen Traffic blockieren, dann gezielt erlauben.

# Default Deny: Kein eingehender oder ausgehender Traffic erlaubt
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Gezielte Kommunikation erlauben

# Frontend darf nur mit dem Backend sprechen (Port 8080)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              tier: frontend
      ports:
        - protocol: TCP
          port: 8080
---
# Backend darf nur mit der Datenbank sprechen (Port 5432)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              tier: database
      ports:
        - protocol: TCP
          port: 5432
    - to: # DNS erlauben
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53

Wichtig für DSGVO-Compliance: Network Policies sind technische Massnahmen nach Art. 32 DSGVO ("Sicherheit der Verarbeitung"). Dokumentieren Sie Ihre Netzwerksegmentierung als Teil Ihrer technisch-organisatorischen Massnahmen (TOMs).

Säule 3: Pod Security Standards - Container-Härtung

Kubernetes definiert drei Pod Security Standards (PSS): Privileged, Baseline und Restricted. Für Produktionsumgebungen sollte mindestens Baseline, idealerweise Restricted gelten.

Pod Security Admission pro Namespace konfigurieren

# Namespace mit Restricted Pod Security Standard
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Gehärtetes Deployment-Template

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: webapp
          image: registry.example.com/webapp:v1.2.3  # Kein :latest verwenden
          ports:
            - containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ['ALL']
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 100Mi

Checkliste für gehärtete Pods:

• runAsNonRoot: true - Kein Root-Benutzer im Container
• readOnlyRootFilesystem: true - Dateisystem ist schreibgeschützt
• allowPrivilegeEscalation: false - Keine Privilegien-Eskalation
• capabilities.drop: ['ALL'] - Alle Linux Capabilities entfernt
• seccompProfile: RuntimeDefault - Seccomp-Profil aktiviert
• automountServiceAccountToken: false - Kein automatisches Token-Mount
• Explizite Resource Limits gesetzt
• Keine :latest-Tags - Immer fixe Image-Versionen

Säule 4: Audit-Logging und Compliance-Monitoring

Audit-Logging beantwortet die Frage: Wer hat wann was im Cluster gemacht? Für DSGVO und BSI IT-Grundschutz ist eine lückenlose Protokollierung Pflicht.

Kubernetes Audit Policy konfigurieren

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets immer auf RequestResponse-Level loggen
  - level: RequestResponse
    resources:
      - group: ''
        resources: ['secrets']

  # RBAC-Änderungen vollständig loggen
  - level: RequestResponse
    resources:
      - group: 'rbac.authorization.k8s.io'
        resources: ['clusterroles', 'clusterrolebindings', 'roles', 'rolebindings']

  # Pods und Deployments auf Request-Level
  - level: Request
    resources:
      - group: ''
        resources: ['pods']
      - group: 'apps'
        resources: ['deployments', 'statefulsets', 'daemonsets']

  # Read-Operationen nur Metadaten
  - level: Metadata
    verbs: ['get', 'list', 'watch']

  # Health-Checks nicht loggen (zu viel Noise)
  - level: None
    nonResourceURLs:
      - '/healthz*'
      - '/readyz*'
      - '/livez*'

Prometheus-Alerting für Security-Events

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: security-alerts
  namespace: monitoring
spec:
  groups:
    - name: kubernetes-security
      rules:
        - alert: UnauthorizedAccessAttempt
          expr: sum(rate(apiserver_audit_event_total{verb!~"get|list|watch",code=~"40[13]"}[5m])) > 5
          for: 2m
          labels:
            severity: warning
          annotations:
            summary: 'Erhöhte Anzahl unautorisierter API-Zugriffe'
            description: 'Mehr als 5 unautorisierte Zugriffsversuche pro Minute in den letzten 2 Minuten.'

        - alert: PrivilegedPodCreated
          expr: sum(kube_pod_container_info{container!="",pod=~".*"}) > 0
          for: 0m
          labels:
            severity: critical
          annotations:
            summary: 'Privilegierter Pod erstellt'
            description: 'Ein Container mit erweiterten Privilegien wurde gestartet.'

Compliance-Mapping: BSI IT-Grundschutz und DSGVO

BSI IT-Grundschutz Baustein SYS.1.6 (Containerisierung)

DSGVO-Anforderungen und technische Umsetzung

Security Hardening Checkliste zum Abhaken

Cluster-Ebene

• Kubernetes auf aktuellem Patch-Level (mindestens n-1)
• etcd-Verschlüsselung aktiviert (EncryptionConfiguration)
• API-Server mit OIDC/LDAP statt statischen Tokens
• Audit-Logging aktiviert und an SIEM angebunden
• kube-bench CIS-Benchmark regelmässig ausgeführt

Namespace-Ebene

• Pod Security Standards auf restricted oder mindestens baseline
• ResourceQuotas und LimitRanges definiert
• Default-Deny NetworkPolicies aktiv
• Dedizierte ServiceAccounts pro Anwendung

Workload-Ebene

• Alle Container als Non-Root
• Read-Only Filesystem aktiviert
• Alle Linux Capabilities gedroppt
• Keine :latest-Image-Tags
• Liveness- und Readiness-Probes konfiguriert
• Resource Requests und Limits gesetzt

Netzwerk-Ebene

• CNI mit NetworkPolicy-Support (Cilium, Calico)
• Ingress-Controller mit TLS-Terminierung
• Egress-Filtering für ausgehenden Traffic
• Service Mesh für mTLS zwischen Services (optional, aber empfohlen)

Automatisierte Policy-Enforcement Tools

Manuelle Prüfungen skalieren nicht. Diese Open-Source-Tools automatisieren das Hardening:

Nächste Schritte

Sofort umsetzen (Tag 1-3)

1. RBAC-Audit durchführen: kubectl auth can-i --list für alle ServiceAccounts
2. Default-Deny NetworkPolicies in allen Produktions-Namespaces aktivieren
3. Pod Security Standards auf baseline setzen (als Warnung starten)
4. kube-bench ausführen und kritische Findings beheben

Kurzfristig (Woche 1-4)

5. Audit-Logging aktivieren und an zentrales Logging anbinden
6. Image-Scanning in die CI/CD-Pipeline integrieren
7. Pod Security Standards auf restricted hochstufen
8. Egress-Policies für alle Namespaces definieren

Mittelfristig (Monat 1-3)

9. OPA/Gatekeeper oder Kyverno für automatisierte Policy-Enforcement
10. Service Mesh für mTLS zwischen Services evaluieren
11. BSI IT-Grundschutz Compliance-Dokumentation erstellen
12. Penetrationstest durch externen Dienstleister

Sie möchten Ihre Kubernetes-Sicherheit professionell aufstellen? Wir bieten Kubernetes Security Schulungen für Teams und unterstützen Sie mit unserem Managed Security Service bei der Absicherung Ihrer Cluster - DSGVO-konform und nach BSI IT-Grundschutz.

Weiterführende Artikel:

• Kubernetes RBAC im Enterprise-Einsatz - Detaillierte RBAC-Strategien für grosse Organisationen
• Network Policies Advanced Guide - Fortgeschrittene Netzwerksegmentierung
• BSI IT-Grundschutz für Kubernetes - Vollständiges BSI-Compliance-Mapping
• DSGVO-Compliance mit Kubernetes - Datenschutz in Container-Umgebungen
• Kubernetes Security Scanning automatisiert - CI/CD-Integration
• Managed Security Service für KMU - Wenn Sie Security auslagern möchten