Kubernetes Security Best Practices | Decripte Security

Kubernetes hat die Orchestrierung und Verwaltung von Containern im großen Maßstab revolutioniert und ist zum De-facto-Standard für das Deployment von Cloud-native-Anwendungen geworden, doch seine verteilte Architektur und inhärente Komplexität führen im Vergleich zu traditionellen Deployment-Modellen zu einer erheblich erweiterten Angriffsfläche. Ein typischer Kubernetes-Cluster umfasst Dutzende miteinander verbundener Komponenten - API Server, etcd, Scheduler, Controller Manager, kubelet, kube-proxy - jede mit ihren eigenen potenziellen Schwachstellen und spezifischen Hardening-Anforderungen. Die dynamische Natur von K8s, in der Pods ständig erstellt und zerstört werden, Workloads zwischen Nodes migrieren und Network Policies in Echtzeit angewendet werden müssen, macht Security zu einer mehrdimensionalen Herausforderung, die einen Defense-in-Depth-Ansatz erfordert. Unsichere Standardkonfigurationen wie übermäßig permissive RBAC-Berechtigungen, das Fehlen von Network Policies, die uneingeschränkte Kommunikation zwischen Pods erlauben, Container, die als root mit privilegierten Capabilities laufen, und Secrets, die im Klartext in unverschlüsseltem etcd gespeichert sind, stellen Angriffsvektoren dar, die in schlecht konfigurierten K8s-Umgebungen häufig ausgenutzt werden. Dieser Artikel behandelt grundlegende Praktiken zum Hardening von Kubernetes-Clustern und umfasst rollenbasierte Zugriffskontrolle (RBAC), Pod Security Standards, Network Policies für die Mikrosegmentierung, sicheres Secrets Management, Admission Controllers für das Policy Enforcement, Runtime-Security-Monitoring mit Tools wie Falco und Compliance mit Branchen-Benchmarks wie dem CIS Kubernetes Benchmark, und bietet damit eine vollständige Roadmap zum Aufbau und Betrieb sicherer Kubernetes-Cluster in Produktionsumgebungen.

K8s-Security-Architektur

Ein Kubernetes-Cluster verfügt über mehrere kritische Komponenten:

• Control Plane: API Server, etcd, Scheduler, Controller Manager
• Nodes: kubelet, kube-proxy, Container Runtime
• Add-ons: DNS, Dashboard, Ingress Controllers

RBAC (Role-Based Access Control)

RBAC ist die Grundlage der K8s-Security und steuert, wer über den API Server auf was zugreifen kann.

RBAC-Konfiguration

      # Role zum Lesen von Pods in einem bestimmten Namespace
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: production
      name: pod-reader
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ---
      # RoleBinding ordnet die Role einem Benutzer zu
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: read-pods
      namespace: production
      subjects:
      - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
      

RBAC-Prinzipien

• Least Privilege: Nur die erforderlichen Berechtigungen gewähren
• ClusterAdmin vermeiden: Funktionsspezifische Rollen erstellen
• Service Accounts: Jeder Pod sollte einen dedizierten SA haben
• Namespace Isolation: RoleBindings statt ClusterRoleBindings

Pod Security

Pod Security Standards

Kubernetes 1.25+ verwendet Pod Security Admission anstelle der veralteten PSPs:

• Privileged: Uneingeschränkt, für vertrauenswürdige Workloads
• Baseline: Minimal restriktiv, verhindert bekannte Eskalationen
• Restricted: Stark eingeschränkt, folgt den Hardening-Best-Practices

Security Context

      apiVersion: v1
      kind: Pod
      metadata:
      name: secure-pod
      spec:
      securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 2000
      seccompProfile:
      type: RuntimeDefault
      containers:
      - name: app
      image: myapp:latest
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
      drop:
      - ALL
      

Network Policies

Standardmäßig können Pods frei kommunizieren. Network Policies implementieren die Segmentierung:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: api-allow-from-frontend
      namespace: production
      spec:
      podSelector:
      matchLabels:
      app: api
      policyTypes:
      - Ingress
      ingress:
      - from:
      - podSelector:
      matchLabels:
      app: frontend
      ports:
      - protocol: TCP
      port: 8080
      

Secrets Management

• Secrets niemals hartcodieren: Kubernetes Secrets oder externe Vaults verwenden
• etcd Encryption: Encryption-at-rest für etcd aktivieren
• External Secrets Operator: Integration mit Vault, AWS Secrets Manager
• Secrets rotieren: Automatische Rotation implementieren
• RBAC für Secrets: Einschränken, wer Secrets lesen darf

Image Security

• Private Registries: In der Produktion keine öffentlichen Registries verwenden
• Image Scanning: Trivy, Clair, Anchore zum Scannen von Schwachstellen
• Image Signing: Cosign zur Überprüfung der Integrität
• Admission Controllers: Images vor dem Deployment validieren
• Distroless Images: Angriffsfläche minimieren

Admission Controllers

API Server Hardening

• Audit Logging aktivieren
• TLS für alle Kommunikationen verwenden
• Anonymous Auth deaktivieren
• API Rate Limiting implementieren
• Zugriff auf den API Server einschränken (Network ACLs)

Runtime Security

• Falco: Runtime Threat Detection für K8s
• Sysdig Secure: Runtime Protection und Compliance
• Aqua Security: Container-Security über den gesamten Lebenszyklus

Compliance und Auditing

• CIS Kubernetes Benchmark: Hardening-Framework
• kube-bench: Automatisierte CIS-Compliance-Prüfungen
• kube-hunter: Penetration-Testing-Tool für K8s
• Audit Logs: Zur Analyse in einem SIEM zentralisieren

Service Mesh Security

Service Meshes (Istio, Linkerd) fügen eine Sicherheitsebene hinzu:

• Automatisches mTLS zwischen Pods
• Fine-grained Authorization Policies
• Traffic Encryption in Transit
• Observability und Auditability