Kubernetes Security Best Practices 2026

Kubernetes ist 2026 der De-facto-Standard für Container-Orchestrierung. Mit wachsender Adoption wächst aber auch die Angriffsfläche — und Sicherheitsvorfälle in Kubernetes-Umgebungen nehmen stetig zu. Dieser Artikel bietet einen umfassenden Überblick über Security Best Practices, die dem aktuellen Stand von Technologien, Bedrohungen und Regulierungen entsprechen.

Dies ist kein einfaches RBAC-Tutorial — wir konzentrieren uns auf fortgeschrittene Techniken, die 2026 den Unterschied zwischen „wir haben Kubernetes” und „wir haben sicheres Kubernetes” ausmachen.

1. Supply Chain Security: Sichern Sie ab, was Sie deployen¶

SBOM als Grundlage¶

Software Bill of Materials (SBOM) ist zur Pflicht geworden — nicht nur aus Best-Practice-Sicht, sondern auch aufgrund von Regulierungen wie NIS2 und dem Cyber Resilience Act (CRA). Jedes Container-Image sollte ein begleitendes SBOM im SPDX- oder CycloneDX-Format haben.

# SBOM-Generierung mit Syft
syft packages registry.example.com/app:v2.1.0 -o spdx-json > sbom.json

# SBOM-Attestierung zum Image mit Cosign
cosign attest --predicate sbom.json \
  --type spdxjson \
  registry.example.com/app:v2.1.0

SLSA Framework Level 3+¶

Supply-chain Levels for Software Artifacts (SLSA) definiert Vertrauensstufen für den Build-Prozess. 2026 sollten Produktions-Workloads mindestens SLSA Level 3 erreichen:

• Level 1: Dokumentierter Build-Prozess
• Level 2: Gehosteter Build mit Provenance
• Level 3: Gehärtete Build-Plattform, nicht fälschbare Provenance
• Level 4: Zwei-Parteien-Review, hermetischer Build

# GitHub Actions mit SLSA Provenance
jobs:
  build:
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/attest-build-provenance@v2
        with:
          subject-name: registry.example.com/app
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

Image-Signierung und -Verifizierung¶

Jedes in den Cluster deployte Image muss signiert und verifiziert werden. Cosign vom Sigstore-Projekt ist 2026 der Industriestandard:

# Kyverno-Policy zur Signaturverifizierung
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign
      match:
        any:
          - resources:
              kinds: ["Pod"]
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "[email protected]"
                    issuer: "https://token.actions.githubusercontent.com"

2. Admission Control: Das Tor zum Cluster¶

Kyverno vs OPA Gatekeeper¶

2026 gibt es zwei Hauptansätze für Admission Control:

Kyverno — eine native Kubernetes-Policy-Engine mit YAML-basierten Regeln. Einfachere Adoption, starke Integration mit der Kubernetes-API.

OPA Gatekeeper — eine allgemeinere Policy-Engine mit der Rego-Sprache. Flexibler, aber mit steilerer Lernkurve.

Für die meisten Organisationen empfehlen wir Kyverno wegen seiner Zugänglichkeit und erweiterten Funktionen wie Ressourcen-Generierung und Mutation:

# Automatisches Hinzufügen von Security Context
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-securitycontext
spec:
  rules:
    - name: add-security-context
      match:
        any:
          - resources:
              kinds: ["Pod"]
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                securityContext:
                  runAsNonRoot: true
                  readOnlyRootFilesystem: true
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop: ["ALL"]
                  seccompProfile:
                    type: RuntimeDefault

Pod Security Standards — Restricted-Profil¶

Kubernetes Pod Security Standards (PSS) haben die veraltete PodSecurityPolicy ersetzt. In der Produktion verwenden Sie das restricted-Profil:

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

Das Restricted-Profil erfordert: - runAsNonRoot: true - Keine privilegierten Container - Eingeschränkte Capabilities (nur NET_BIND_SERVICE) - Seccomp-Profil RuntimeDefault oder Localhost - Keine hostPath-Volumes - Privilege Escalation deaktiviert

ValidatingAdmissionPolicy — Eine native Alternative¶

Seit Kubernetes 1.30 ist ValidatingAdmissionPolicy (VAP) GA. Sie bietet native Admission Control ohne externe Webhooks mittels CEL (Common Expression Language):

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-privileged-containers
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: >-
        object.spec.containers.all(c,
          !has(c.securityContext) ||
          !has(c.securityContext.privileged) ||
          c.securityContext.privileged == false)
      message: "Privilegierte Container sind nicht erlaubt"

VAP ist eine leichtgewichtige Alternative zu Webhooks — sie läuft direkt im API-Server, ohne Netzwerkaufrufe. Für einfache Policies ist sie die ideale Wahl.

3. Netzwerksicherheit: Mikrosegmentierung und darüber hinaus¶

Network Policies — Baseline¶

Das Standardverhalten von Kubernetes ist „allow all” — jeder Pod kann mit jedem kommunizieren. Das ist in der Produktion inakzeptabel:

# Default Deny für Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Dann nur die benötigte Kommunikation erlauben:

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

Cilium Network Policies — Layer 7 und DNS¶

Standard-Kubernetes-Network-Policies arbeiten auf L3/L4. Cilium erweitert die Möglichkeiten um L7-Filterung, DNS-bewusste Policies und identitätsbasierte Sicherheit:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  egress:
    - toEndpoints:
        - matchLabels:
            app: user-service
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/users/.*"
              - method: "POST"
                path: "/api/v1/users"
    - toFQDNs:
        - matchName: "api.external-service.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Automatisches Mutual TLS (mTLS)¶

Service-Mesh-Lösungen wie Cilium (mit mTLS-Unterstützung), Istio oder Linkerd bieten automatische verschlüsselte Kommunikation zwischen Pods. 2026 ist Cilium die bevorzugte Wahl dank eBPF — ohne Sidecar-Proxy, geringere Latenz, weniger Ressourcen-Overhead:

# Cilium mTLS-Konfiguration
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: require-mtls
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: order-service
      authentication:
        mode: required

4. Runtime Security: Echtzeit-Erkennung¶

Falco — Syscall-Monitoring¶

Falco überwacht Syscalls und erkennt verdächtiges Verhalten zur Laufzeit. 2026 ist Falco ein ausgereiftes CNCF-Graduated-Projekt:

# Falco-Regel zur Reverse-Shell-Erkennung
- rule: Reverse Shell
  desc: Detect reverse shell
  condition: >
    spawned_process and
    proc.name in (bash, sh, zsh) and
    fd.type = ipv4 and
    fd.direction = out
  output: >
    Reverse shell detected
    (user=%user.name command=%proc.cmdline
     connection=%fd.name container=%container.name
     image=%container.image.repository)
  priority: CRITICAL
  tags: [network, process, mitre_execution]

# Erkennung des Lesens sensibler Dateien
- rule: Read Sensitive Files
  desc: Detect reading of sensitive files
  condition: >
    open_read and
    sensitive_files and
    container and
    not trusted_containers
  output: >
    Sensitive file read in container
    (file=%fd.name container=%container.name
     image=%container.image.repository)
  priority: WARNING

Tetragon — eBPF Security Observability¶

Cilium Tetragon ist eine neuere Alternative zu Falco, basierend auf eBPF. Es bietet Echtzeit-Enforcement (nicht nur Erkennung) mit minimalem Overhead:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-sensitive-file-access
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/run/secrets/kubernetes.io"
          matchActions:
            - action: Sigkill

Der wesentliche Unterschied: Falco erkennt und meldet, Tetragon kann aktiv blockieren. Für kritische Workloads empfehlen wir eine Kombination beider — Tetragon für Enforcement, Falco für den Audit-Trail.

Audit-Logging¶

Das Kubernetes-Audit-Log ist unverzichtbar für forensische Analyse und Compliance:

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Alle Anfragen an Secrets protokollieren
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  # Exec in Pods protokollieren
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
  # Alle RBAC-Änderungen protokollieren
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings",
                     "roles", "rolebindings"]
  # Metadaten für alles andere
  - level: Metadata
    omitStages:
      - RequestReceived

Audit-Logs in ein zentrales SIEM-System (Elasticsearch, Splunk oder Cloud-SIEM) leiten und Alerting für kritische Ereignisse einrichten.

5. Secrets Management¶

Niemals in Git, niemals in Umgebungsvariablen¶

Kubernetes Secrets sind base64-codiert, nicht verschlüsselt. Für die Produktion benötigen Sie:

1. External Secrets Operator (ESO) — Synchronisation von Secrets aus externen Vaults:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

1. Sealed Secrets — verschlüsselte Secrets in Git:

kubeseal --format yaml < secret.yaml > sealed-secret.yaml
# sealed-secret.yaml kann sicher committed werden

1. SOPS + Age/KMS — Dateiverschlüsselung mit über KMS verwalteten Schlüsseln:

sops --encrypt --age age1... secrets.yaml > secrets.enc.yaml

Secret-Rotation¶

Automatische Rotation ist 2026 eine Notwendigkeit. Setzen Sie TTLs auf Secrets und verwenden Sie dynamische Credentials wo möglich (z.B. Vault Database Secrets Engine):

# Vault dynamische Datenbank-Credentials
resource "vault_database_secret_backend_role" "app" {
  backend = vault_mount.database.path
  name    = "app-role"
  db_name = "postgres"

  creation_statements = [
    "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
    "GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
  ]

  default_ttl = 3600   # 1 Stunde
  max_ttl     = 86400  # 24 Stunden
}

6. Image Security¶

Minimale Base Images¶

Verwenden Sie distroless oder scratch Images. Je weniger Komponenten im Image, desto kleiner die Angriffsfläche:

# Multi-Stage Build mit Distroless
FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /server /server
USER 65534:65534
ENTRYPOINT ["/server"]

Vulnerability Scanning in CI/CD¶

Integrieren Sie Scanning in Ihre Pipeline — deployen Sie niemals Images mit kritischen CVEs:

# GitHub Actions mit Trivy
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: registry.example.com/app:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: CRITICAL,HIGH
    exit-code: 1  # Pipeline bei Critical/High fehlschlagen lassen

Admission Control für Image-Quality-Gates¶

# Kyverno — nur Images aus genehmigtem Registry erlauben
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Images müssen aus einem genehmigten Registry stammen"
        pattern:
          spec:
            containers:
              - image: "registry.example.com/*"
            initContainers:
              - image: "registry.example.com/*"

7. RBAC — Least Privilege in der Praxis¶

Das Prinzip der geringsten Privilegien¶

Erstellen Sie granulare Rollen anstatt cluster-admin zu verwenden:

# Rolle für die Deployment-Pipeline
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Regelmäßiges RBAC-Audit¶

Nutzen Sie Tools wie kubectl-who-can und rakkess für Berechtigungsaudits:

# Wer kann Secrets lesen?
kubectl who-can get secrets -n production

# Audit aller cluster-admin Bindings
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") |
  {name: .metadata.name, subjects: .subjects}'

Service-Account-Tokens — gebunden und kurzlebig¶

Seit Kubernetes 1.24 werden keine langlebigen SA-Tokens mehr automatisch erstellt. Verwenden Sie gebundene Service-Account-Tokens mit begrenzter Gültigkeit:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  serviceAccountName: app-sa
  containers:
    - name: app
      image: registry.example.com/app:v2
      volumeMounts:
        - mountPath: /var/run/secrets/tokens
          name: app-token
  volumes:
    - name: app-token
      projected:
        sources:
          - serviceAccountToken:
              path: token
              expirationSeconds: 3600  # 1 Stunde
              audience: "api.example.com"

8. Cluster-Hardening¶

API-Server¶

• Anonyme Authentifizierung deaktivieren: --anonymous-auth=false
• Audit-Logging aktivieren
• API-Server-Zugriff auf vertrauenswürdige Netzwerke beschränken
• OIDC für Benutzerauthentifizierung verwenden

etcd¶

• Daten at rest mittels EncryptionConfiguration verschlüsseln
• mTLS für die Kommunikation mit dem API-Server verwenden
• etcd von Worker-Nodes isolieren
• Regelmäßige Backups mit Verschlüsselung

# EncryptionConfiguration für etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}

Node-Sicherheit¶

• Automatisches OS-Patching (z.B. Bottlerocket, Flatcar, Talos)
• CIS Kubernetes Benchmark Compliance
• Minimales Node-OS — nur das, was für den Kubelet benötigt wird

# CIS-Compliance-Prüfung mit kube-bench
kube-bench run --targets node
kube-bench run --targets master

9. Monitoring und Incident Response¶

Sicherheitsorientierte Metriken¶

Überwachen Sie sicherheitsrelevante Metriken:

• Anzahl fehlgeschlagener Authentifizierungsversuche
• RBAC-abgelehnte Anfragen (apiserver_authorization_decisions_total{decision="denied"})
• Admission-Webhook-Ablehnungen
• Network-Policy-Drops
• Anomalien im Ressourcenverbrauch

Incident-Response-Playbook¶

Bereiten Sie Runbooks für gängige Szenarien vor:

1. Kompromittierter Pod — Isolation über Network Policy, forensischer Snapshot, Credential-Rotation
2. Secret-Leak — sofortige Rotation, Audit-Trail-Analyse, Scope-Assessment
3. Privilegierter Zugriff — Widerruf, RBAC-Audit, Lateral-Movement-Prüfung
4. Supply-Chain-Angriff — Identifizierung betroffener Images, Rollback, SBOM-Analyse

# Notfall-Netzwerkisolierung
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: emergency-isolate
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: compromised-app
  policyTypes:
    - Ingress
    - Egress
  # Leere Ingress/Egress = deny all

10. KI-gestützte Sicherheit — Trend 2026¶

2026 wenden sich immer mehr Organisationen an KI für Sicherheitsoperationen:

• Anomalieerkennung — ML-Modelle analysieren Netzwerkverkehrs- und Syscall-Muster, identifizieren Abweichungen vom Baseline-Verhalten
• Automatisierte Triage — KI priorisiert Sicherheitswarnungen und reduziert Alert-Fatigue
• Prädiktives Patching — Vorhersage der CVE-Ausnutzbarkeit basierend auf dem Umgebungskontext
• Natural Language Policies — experimentelle Tools ermöglichen die Definition von Sicherheitsrichtlinien in natürlicher Sprache

Tools wie ARMO Kubescape, Aqua Security und Sysdig integrieren KI-gestützte Analyse in ihre Plattformen. Sie sind eine Ergänzung, kein Ersatz — haben Sie immer solide Grundlagen (RBAC, Network Policies, Admission Control) etabliert.

Checkliste: Kubernetes Security 2026¶

Bevor Sie einen Cluster als „produktionsbereit” erklären, prüfen Sie:

• [ ] Pod Security Standards — Restricted-Profil auf Produktions-Namespaces
• [ ] Network Policies — Default Deny, explizites Allow
• [ ] RBAC — Least Privilege, kein unnötiger cluster-admin
• [ ] Image-Signierung und -Verifizierung — Cosign + Kyverno/Gatekeeper
• [ ] SBOM-Generierung und -Attestierung
• [ ] Vulnerability Scanning in CI/CD mit Quality Gates
• [ ] Secrets in externem Vault (nicht in Git, nicht unverschlüsselt in etcd)
• [ ] Runtime Security — Falco oder Tetragon
• [ ] Audit-Logging ins SIEM
• [ ] etcd-Verschlüsselung at rest
• [ ] mTLS zwischen Services
• [ ] Incident-Response-Playbook
• [ ] Regelmäßige CIS-Benchmark-Audits

Fazit¶

Kubernetes Security ist keine einmalige Aufgabe — es ist ein kontinuierlicher Prozess. Technologien entwickeln sich weiter (eBPF, VAP, KI-gestützte Erkennung), Angreifer passen sich an, und Regulierungen verschärfen die Anforderungen.

Der Schlüssel zum Erfolg ist Defense in Depth: Keine einzelne Sicherheitsschicht ist ausreichend. Kombinieren Sie Supply-Chain-Security, Admission Control, Netzwerksegmentierung, Runtime-Schutz und Monitoring zu einer kohärenten Strategie.

Beginnen Sie mit dem, was den größten Nutzen bei geringstem Aufwand bringt — Network Policies und Pod Security Standards. Fügen Sie dann schrittweise Schichten hinzu, basierend auf der Reife Ihres Teams und der Kritikalität Ihrer Workloads.