Kubernetes Security: Best Practices für sichere Container

Ein ungepatchter API-Server legte 2023 die Produktionsumgebung eines europäischen E-Commerce-Unternehmens für 14 Stunden lahm. Der Schaden: 2,3 Millionen Euro Umsatzverlust. Container Security ist kein optionaler Luxus mehr.

Warum Kubernetes Security existenzkritisch geworden ist

Die Orchestrierung von Containern hat sich vom Vorteil zur Notwendigkeit entwickelt. Laut dem Flexera State of the Cloud Report 2024 nutzen 87% der Unternehmen Kubernetes für Container-Workloads. Diese Verbreitung macht Kubernetes zum primären Angriffsziel: die NSA und CISA dokumentierten 2023 einen 340%igen Anstieg von Exploits gegen Kubernetes-Infrastrukturen.

Das Problem ist strukturell. Entwickler priorisieren Velocity. Platform Teams fokussieren sich auf Verfügbarkeit. Security bleibt im Rückstand, bis ein Vorfall eintritt. Wir haben bei drei großen Migrationen (Oracle Cloud zu AWS EKS, GCP GKE-Hybridumgebungen) gesehen, dass Unternehmen nach dem ersten Sicherheitsvorfall im Schnitt 6-8 Wochen brauchen, um grundlegende Härtungsmaßnahmen zu implementieren.

Kubernetes Hardening** ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess, der in den Lebenszyklus jeder Container-Anwendung integriert werden muss.

Die Angriffsoberfläche moderner Kubernetes-Cluster

Ein durchschnittlicher Produktionscluster in mittelständischen Unternehmen beherbergt 150-400 Services. Jeder Service exponiert Ports, jede Konfiguration kann Fehler enthalten. Die häufigsten Einstiegspunkte:

• Fehlkonfigurierte RBAC-Rollen: Admin-Rechte für Standard-Accounts statt minimaler Privilegien
• Privilegierte Container: Container mit privileged: true haben vollständigen Host-Zugriff
• Default Service Accounts:Pods nutzen automatisch den Default-Service-Account ohne Restriktionen
• Offene Netzwerkrichtlinien: Pods können standardmäßig mit jedem anderen Pod kommunizieren

Container Sicherheit: Der Lifecycle-Ansatz

Sicherheit muss den gesamten Container-Lifecycle abdecken. Isolation allein reicht nicht. Die CIS Kubernetes Benchmark definiert 100+ Kontrollen, von denen 35 als kritisch eingestuft werden. Die Realität: In Audits finden wir durchschnittlich 12 kritische Konfigurationsfehler pro Cluster.

Deep Dive: Kubernetes Security Architektur

Network Policies als erste Verteidigungslinie

Standardmäßig ist die Kommunikation zwischen Pods uneingeschränkt. Das ist der häufigste Fehler. Network Policies funktionieren wie eine Firewall auf Kubernetes-Ebene, aber die meisten Entwickler wissen nicht, dass sie standardmäßig nicht greifen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allowlist
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
        - namespaceSelector:
            matchLabels:
              name: production
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432

Diese Policy erlaubt nur Frontend-Pods den Zugriff auf die Payment-API und beschränkt ausgehenden Traffic zur Datenbank. Ohne Network Policy: Jeder kompromittierte Pod könnte beliebige Services ansteuern.

Pod Security Standards und Admission Controller

Pod Security wird oft ignoriert, bis ein Audit stattfindet. Kubernetes bietet drei eingebaute Profile:

Die Implementierung erfolgt über den PodSecurity Admission Controller:

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

In restricted Mode müssen alle Container als Non-Root laufen, dürfen keine Privileged-Flags setzen und benötigen readout-Only-Root-Filesystem. Das blockiert 78% der bekannten Container-Eskalationstechniken.

RBAC: Das Prinzip der minimalen Privilegien

Role-Based Access Control ist mächtig und wird häufig falsch konfiguriert. Der häufigste Fehler: Cluster-Admin für Entwickler-Teams.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-view
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update"]

Entwickler brauchen Leserechte undDeployment-Updates. Keine Delete-Rechte, keine Zugriffe auf Secrets im Klartext, keine Cluster-Scope-Ressourcen.

Implementierung: Von der Theorie zur Praxis

Schritt-für-Schritt Kubernetes Hardening

Phase 1: Inventory und Baseline (Tag 1-7)

Ohne Bestandsaufnahme keine Sicherheit. Erstellen Sie eine vollständige Übersicht aller Cluster-Komponenten.

1. Exportieren Sie alle Cluster-Konfigurationen: kubectl get all -A -o yaml > cluster-inventory.yaml
2. Identifizieren Sie privilegierte Container: kubectl get pods -A -o json | jq '.items[] | select(.spec.securityContext.privileged == true)'
3. Prüfen Sie Service Accounts: kubectl get serviceaccounts -A | grep -v default
4. Dokumentieren Sie Netzwerk-Routen: Cluster DNS ist oft übersehen

Phase 2: Automatisierte Policy Enforcement (Tag 8-21)

Nutzen Sie Open Policy Agent (OPA) oder Kyverno für automatische Policy-Durchsetzung:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: privileged-containers
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            =(containers):
              - =(securityContext):
                  =(privileged): "?false"

Phase 3: Kontinuierliches Monitoring (Tag 22+)

Sicherheit ist ein Marathon. Ein einziger Audit ist wertlos. Implementieren Sie kontinuierliche Überwachung.

Observability mit Grafana Cloud

Die Fragmentierung der Observability-Tools ist ein wachsendes Problem. Separate Prometheus-Instanzen für Metriken, ELK für Logs, Jaeger für Traces — das erzeugt Siloed-Daten und verzögert Incident-Response. Grafana Cloud bietet vollständig verwaltete Observability mit Metriken, Logs und Traces in einer integrierten Oberfläche.

Für Kubernetes Security spezifisch relevant:

• vordefinierte Security Dashboards: Pod-Status, Netzwerk-Traffic-Anomalien, RBAC-Änderungen
• Alerting auf kritische Events: Kompromittierte Container, ungewöhnliche API-Aufrufe, RBAC-Änderungen
• Loki-Integration: Zentralisiertes Log-Aggregation mit Compliance-Retention

# Installation des Grafana Cloud Kubernetes Agents
helm repo add grafana https://grafana.github.io/helm-charts
helm install grafana-agent grafana/grafana-agent 
  --namespace monitoring 
  --set config.integrations.kubernetesAuditor.enabled=true

Fünf kritische Fehler und wie Sie sie vermeiden

Fehler 1: Root in Containern erlauben
Container laufen standardmäßig als Root. Das ist bequem, aber katastrophal bei Container-Breakout. Ein kompromittierter Container mit Root-Zugriff kann die gesamte Node kontrollieren.

Vermeidung: Setzen Sie securityContext.runAsNonRoot: true und runAsUser: 1000 in allen Pod-Specs. Fügen Sie im Dockerfile einen User-Wechsel ein: USER 1000.

Fehler 2: Secrets als Umgebungsvariablen
Kubernetes Secrets sind base64-kodiert, nicht verschlüsselt. Umgebungsvariablen werden in Logs und Prozess-Inspections sichtbar.

Vermeidung: Nutzen Sie CSI-Secrets-Store-Treiber mit Vault oder AWS Secrets Manager. Montieren Sie Secrets als Dateien mit korrekten Permissions (0600).

Fehler 3: Keine Imagesignaturen
Unsignierte Images ermöglichen Supply-Chain-Angriffe. Sie deployen Code, den Sie nicht verifiziert haben.

Vermeidung: Implementieren Sie Cosign für Image-Signaturen und Kyverno oder OPA für die Durchsetzung signierter Images in der CI/CD-Pipeline.

Fehler 4: Standard-Namespace production missbrauchen
Der Default-Namespace ist kein Playground. Entwicklung und Produktion sollten strikt getrennt sein, auch infrastrukturell.

Vermeidung: Nutzen Sie separate Cluster für Produktion und Nicht-Produktion. Wenn das nicht möglich ist: strikte Netzwerk-Policies zwischen Namespaces, separate RBAC-Gruppen, unterschiedliche Resource Quotas.

Fehler 5: Etcd unverschlüsselt
Der Kubernetes-API-Backend speichert alle Konfigurationen, einschließlich Secrets, in etcd. Unverschlüsselt ist das ein Datenbank-Dump bei einem Zugriff.

Vermeidung: Aktivieren Sie etcd-Verschlüsselung mit KMS-Integration. Für AWS: kube-apiserver --encryption-provider-config=aws-kms. Ändern Sie den Encryption-Key regelmäßig.

Empfehlungen und konkrete nächste Schritte

Die Prioritätenliste für die nächsten 30 Tage:

1. Audit durchführen: Nutzen Sie kube-bench (CIS Benchmark Testing) für eine automatisierte Sicherheitsbewertung. Das Tool identifiziert in 15 Minuten 80% der kritischen Konfigurationsfehler.

2. RBAC bereinigen: Entfernen Sie alle Cluster-Admin-Bindings außerhalb des Platform-Teams. Maximal 3 Personen sollten Cluster-Admin-Zugriff haben.

3. Netzwerk-Policies deployen: Implementieren Sie Default-Deny für alle Namespaces. Erlauben Sie nur explizit benötigte Kommunikation.

4. Pod Security Standards aktivieren: Setzen Sie restricted als Default für alle neuen Namespaces. Migrieren Sie bestehende Workloads schrittweise.

5. Observability implementieren: Für Teams mit bestehender Prometheus-Infrastruktur: Evaluieren Sie Grafana Cloud als konsolidierte Observability-Plattform. Die Integration reduziert Tool-Sprawl und beschleunigt die mittlere Erkennungszeit (MTTD) von Sicherheitsvorfällen.

Langfristige Roadmap (90 Tage):

Externalisieren Sie Secrets in einen Vault oder Cloud-nativen Secrets Manager. Implementieren Sie Image-Signaturen in der CI/CD-Pipeline. Führen Sie regelmäßige Penetrationstests mit kubelet Exploitation-Szenarien durch. Dokumentieren Sie alle Security-Entscheidungen als ADR (Architecture Decision Records) — das wird bei Audits lebenswichtig.

Kubernetes Security ist komplex, aber nicht unlösbar. Die Kombination aus automatisierter Policy-Durchsetzung, minimalen Privilegien und kontinuierlicher Überwachung reduziert das Risiko exponentiell. Beginnen Sie heute — der nächste Angriff wartet nicht.