Kubernetes absichern – Zugriff mit RBAC, Netzrichtlinien, Pod Security

Kubernetes liefert dir viele Sicherheitsfunktionen direkt mit. Ohne aktive Konfiguration bleiben jedoch Rechte, Netzwerkzugriffe und Container-Berechtigungen oft zu weit geöffnet. Das führt zu unnötigen Risiken und schwer nachvollziehbaren Fehlern im Betrieb.

In diesem Guide zeige ich dir die drei Grundlagen, mit denen du jedes Cluster sofort härtest: RBAC für feingranulare Zugriffsrechte, Network Policies für Microsegmentation und Pod Security für harte Container-Grenzen. Du bekommst einfache Erklärungen, klare Defaults und kleine Beispiele, die du direkt übernehmen kannst.

Das Sicherheitsmodell in drei Säulen

Kubernetes-Security lässt sich pragmatisch so denken: Wer darf was (RBAC), wer darf mit wem reden (Network Policies) und was darf ein Pod auf dem Host (Pod Security über SecurityContext und Pod Security Admission). Zusammen ergeben diese Säulen Least Privilege, Segmentierung und Workload-Härtung.

RBAC – Wer darf was im Cluster

Grundprinzip: Least Privilege

Mit Role/ClusterRole definierst du Rechte auf Ressourcen (z. B. Pods, Deployments), mit RoleBinding/ClusterRoleBinding verknüpfst du diese Rechte mit Identitäten wie ServiceAccounts, Benutzern oder Gruppen. Ziel ist immer: nur notwendige Aktionen erlauben.

Praxisregeln: Vergib Rechte pro Namespace, nutze eigene ServiceAccounts pro App statt default, trenne Bauen/Deployen von Betrieb, starte mit Leserechten und erweitere bei Bedarf.

Mini-Beispiel: Nur Pod-Logs lesen

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: app
rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-pod-log-reader
  namespace: app
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: app
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io

Damit bekommt app-sa nur Zugriff auf Logs im Namespace app – nicht mehr.

Network Policies – Wer darf mit wem sprechen

Default-Deny als Startpunkt

Ohne Network Policies dürfen Pods meist frei miteinander kommunizieren. Sichere Basis ist Default-Deny: erst alles blockieren, dann gezielt öffnen. Du steuerst Ingress und Egress über podSelector, namespaceSelector, ports und ipBlock.

Beispiel: Namespace absperren und Web-Pods öffnen

# Alles sperren im Namespace "app"
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: app
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]
---
# Ingress auf Port 80/443 für Pods mit app=web erlauben (im selben Namespace)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-ingress
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

So erreichst du Microsegmentation: nur definierte Wege sind offen, alles andere bleibt zu.

Wichtig: Egress nicht vergessen – sonst sprechen Pods unkontrolliert nach außen. Prüfe, ob dein CNI (z. B. Calico, Cilium) NetworkPolicy vollständig unterstützt.

Pod Security – Was darf ein Pod auf dem Host

Pod Security Admission anwenden

Ehemalige Pod Security Policies sind entfernt. Heute setzt du Pod Security Admission (PSA) mit den Levels privileged, baseline und restricted ein und wählst die Modi enforce, warn oder audit. Für Workloads ist restricted die sichere Voreinstellung.

Beispiel-Labels:

kubectl label ns app pod-security.kubernetes.io/enforce=restricted
kubectl label ns staging pod-security.kubernetes.io/warn=restricted

SecurityContext im Pod setzen

Harte Container-Grenzen definierst du im securityContext. Zentral sind: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, Capabilities droppen und Seccomp aktivieren.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: app
spec:
  replicas: 2
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      serviceAccountName: app-sa
      containers:
      - name: web
        image: ghcr.io/example/web:1.0
        securityContext:
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          seccompProfile:
            type: RuntimeDefault
        ports:
        - containerPort: 8080

Damit verhinderst du viele Container-zu-Host-Angriffe bereits by default.

Secrets, Images und Supply Chain – kurz und wichtig

Lege Zugangsdaten immer in Secrets ab, nie als Klartext im Manifest. Nutze ImagePullSecrets für private Registries. Bevorzuge schlanke Basis-Images, signierte Artefakte und regelmäßige Scans. Ein readOnlyRootFilesystem plus non-root blockt viele Runtime-Risiken.

Monitoring, Policies und Audits

Aktiviere Audit Logs und führe Änderungen nachvollziehbar. Mit Kyverno oder OPA Gatekeeper setzt du Cluster-weit Regeln durch (z. B. runAsNonRoot erzwingen, Registry-Whitelist). Kombiniere Metriken, Logs und Events, damit RBAC-Fehler, Policy-Verstöße und Netzwerk-Blockaden schnell sichtbar werden.

Ein Fahrplan für Einsteiger

Starte in einem Pilot-Namespace:

• RBAC minimal binden – ServiceAccounts statt default.
• Network Policies: Default-Deny, dann gezielt Ingress/Egress öffnen.
• Pod Security: Namespace auf restricted, SecurityContext in allen Deployments setzen.
  Läuft es stabil, übertrage die Regeln auf weitere Namespaces und halte Vorlagen bereit.

Fazit

Mit RBAC, Network Policies und Pod Security sicherst du dein Kubernetes-Setup wirksam und verständlich ab. RBAC kontrolliert Aktionen, Network Policies kontrollieren Verbindungen und Pod Security beschränkt Berechtigungen im Container. Wenn du diese drei Säulen konsequent nutzt, gewinnst du Sichtbarkeit, Kontrolle und Resilienz gegen Angriffe.