Kubernetes RBAC -- Zugriffskontrolle im Multi-Tenant-Cluster

Kubernetes 1.6 bringt RBAC als Beta-Feature – und für uns ist es absolut kritisch. In einem einzigen Cluster haben wir Entwickler, ein Ops-Team und eine CI/CD-Pipeline, die jeweils unterschiedliche Berechtigungen benötigen.

Warum wir RBAC brauchen¶

Bis Version 1.6 hatte Kubernetes im Wesentlichen zwei Modi: ABAC (statische Policies in einer JSON-Datei auf dem API-Server) oder gar keine Autorisierung. ABAC war unpraktisch – jede Änderung erforderte einen Neustart des API-Servers.

RBAC ist dynamisch. Role, ClusterRole, RoleBinding, ClusterRoleBinding – alles ist ein Kubernetes-Objekt, verwaltbar über kubectl und versionierbar in Git.

Unser Modell: Namespace pro Team¶

Jedes Team (oder jeder Kunde) bekommt seinen eigenen Namespace. Innerhalb dieses Namespace hat es volle Rechte – es kann Deployments, Services und ConfigMaps erstellen. Aber es kann nichts in einem anderen Namespace sehen oder ändern.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  namespace: team-alpha
  name: team-alpha-admin
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: team-alpha-binding
subjects:
- kind: Group
  name: "team-alpha"
roleRef:
  kind: Role
  name: team-alpha-admin
  apiGroup: rbac.authorization.k8s.io

Service Accounts für CI/CD¶

Jenkins muss in den Cluster deployen, aber wir wollen ihm keine Cluster-Admin-Rechte geben. Wir erstellen einen Service Account mit genau definierten Berechtigungen – er kann Deployments und Services in einem bestimmten Namespace erstellen und aktualisieren, mehr nicht.

Das Service-Account-Token wird Jenkins als Credential übergeben. Wenn jemand Jenkins kompromittiert, erhält er keinen Zugriff auf den gesamten Cluster.

Integration mit LDAP/Active Directory¶

Kubernetes selbst hat keine Benutzerverwaltung – es delegiert die Authentifizierung an ein externes System. Wir verwenden einen OIDC-Provider (Dex), der mit unserem Active Directory verbunden ist. AD-Gruppen werden auf Kubernetes-Gruppen abgebildet.

Das Setup ist nicht trivial, aber das Ergebnis ist elegant: Jemand verlässt das Unternehmen, Sie deaktivieren sein AD-Konto, und er verliert automatisch den Zugang zu Kubernetes.

Tipps aus der Praxis¶

• Starten Sie von Anfang an mit --authorization-mode=RBAC – spätere Migration ist schmerzhaft
• Verwenden Sie Gruppen, nicht einzelne Benutzer, in RoleBindings
• Auditieren – kubectl auth can-i --list zeigt, was ein Benutzer kann
• Achten Sie auf den Default Service Account – er hat oft mehr Berechtigungen, als Sie möchten
• Network Policies + RBAC = Defense in Depth

RBAC ist die Grundlage eines sicheren Clusters¶

Ohne RBAC ist ein Kubernetes-Cluster wie ein Haus ohne Schlösser. Mit Version 1.6 haben wir endlich ein produktionsreifes Autorisierungsmodell. Die Investition in eine korrekte RBAC-Konfiguration zahlt sich vielfach aus.