Was sind die Grundlagen der Kubernetes-Sicherheit (RBAC und Network Policies)?

Kubernetes wird standardmäßig offen ausgeliefert — weite Berechtigungen und flaches Netzwerk — daher ist Sicherheit etwas, das du hinzufügen musst. Die zwei grundlegenden Kontrollen sind RBAC und Network Policies, und eine starke Antwort erklärt sowohl den Mechanismus als auch das Standardverhalten, das Leute beißt.

RBAC: Wer die API berühren darf

Alles in Kubernetes läuft über den API-Server, daher ist die Steuerung des API-Zugriffs entscheidend.

• Roles / ClusterRoles definieren eine Menge erlaubter Verben (get, list, create, delete) auf Ressourcen (Pods, Secrets). Roles sind namespace-gebunden; ClusterRoles gelten clusterweit.
• RoleBindings / ClusterRoleBindings hängen diese Rollen an Subjekte an — Benutzer, Gruppen oder Service-Konten.
• Geringste Rechte: Vermeide es, irgendetwas an cluster-admin zu binden, vermeide Wildcard-Verben/-Ressourcen und gib dem Service-Konto jeder Workload nur das, was es braucht. Ein Pod, der alle secrets lesen kann, ist bei Kompromittierung ein ernster Eskalationspfad.

Network Policies: Wer mit wem sprechen darf

Standardmäßig kann jeder Pod jeden anderen Pod erreichen — flaches, alles erlaubendes Netzwerk. Ein kompromittierter Pod kann frei scannen und pivotieren.

• Wende eine Default-Deny-Richtlinie in einem Namespace an und füge dann explizite Ingress-/Egress-Regeln hinzu, die nur die Flüsse erlauben, die deine App tatsächlich braucht (z. B. Frontend zu Backend auf einem Port).
• Kritischer Vorbehalt: Network Policies werden vom CNI-Plugin erzwungen. Wenn dein CNI sie nicht unterstützt (oder du annimmst, ein No-Op-Default tue es), tut die Richtlinie still gar nichts — ein häufiger Grund, warum eine „Deny"-Regel ignoriert erscheint.

Worauf Interviewer achten

RBAC (API-Autorisierung) von Network Policies (Verkehrssegmentierung) trennen, beide Standardverhalten kennen (weites RBAC, alles erlaubendes Netzwerk) und die CNI-Abhängigkeit, die Network Policies ohne Unterstützung wirkungslos macht.