Kubernetes RBAC: Zugriffskontrolle im Container-Cluster

Kubernetes 1.6 führt RBAC (Role-Based Access Control) ein — granulare Zugriffskontrolle für API-Ressourcen. Wie man ein Sicherheitsmodell für einen Multi-Tenant-Cluster entwirft.

Warum RBAC in Kubernetes¶

Eine Standard-Kubernetes-Installation hat keine Zugriffskontrolle — jeder mit API-Zugang kann alles tun. In einer Produktionsumgebung mit mehreren Teams ist das inakzeptabel.

RBAC (Role-Based Access Control) ermöglicht die Definition, wer (Subjekt) was (Verb) mit was (Ressource) tun darf. Granulare Berechtigungen auf Namespace- oder Cluster-Ebene.

Role, ClusterRole und Bindings¶

Das RBAC-Modell hat vier Objekte:

# Kubernetes RBAC: Zugriffskontrolle im Container-Cluster
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

---
# RoleBinding - assigning a role to a user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: [email protected]
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Role = Berechtigungen in einem Namespace. ClusterRole = Berechtigungen über den gesamten Cluster. Binding = Verknüpfung einer Rolle mit einem Subjekt.

Entwurf des RBAC-Modells¶

Empfohlener Ansatz für Enterprise:

• Cluster Admin — Vollzugriff (nur Infrastruktur-Team)
• Namespace Admin — Vollzugriff innerhalb des Team-Namespace
• Developer — Deploy, Logs ansehen, Exec in Pods im eigenen Namespace
• Viewer — Read-Only-Zugriff für Monitoring und Debugging

Prinzip der geringsten Berechtigung — beginnen Sie mit dem Minimum und erweitern Sie bei Bedarf. Berechtigungen regelmäßig auditieren.

Service Accounts und Automatisierung¶

Service Accounts sind Identitäten für Prozesse (CI/CD, Operatoren, Monitoring):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deploy
  namespace: production
subjects:
- kind: ServiceAccount
  name: ci-deployer
  namespace: production
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

CI/CD-Pipelines verwenden Service-Account-Tokens statt persönlicher Credentials. Token-Rotation und Audit-Logging sind Best Practices.

Fazit: Sicherheit als First-Class Citizen¶

RBAC ist unverzichtbar für Kubernetes-Produktionscluster. Investieren Sie Zeit in den Entwurf Ihres Berechtigungsmodells, bevor Sie den Cluster für mehrere Teams öffnen. Geringste Berechtigung, regelmäßige Audits und Service Accounts für Automatisierung sind die wichtigsten Best Practices.