Wesentliche RBAC-Best Practices für die Sicherung Ihrer Kubernetes-Cluster

Kubernetes-RBAC entscheidet, wer was in Ihrem Cluster tun kann. Eine einzige breite Bindung kann es einem kompromittierten Konto ermöglichen, Geheimnisse zu lesen, Workloads zu ändern oder Cluster-Ressourcen zu übernehmen.

Dieser Leitfaden erklärt die grundlegenden RBAC-Objekte, zeigt funktionierende Beispiele und gibt Ihnen Überprüfungsgewohnheiten, die verhindern, dass Zugriffe im Laufe der Zeit abweichen.

Grundlagen von Kubernetes-RBAC verstehen

RBAC in Kubernetes ist ein Autorisierungsmechanismus, der den Zugriff auf Kubernetes-Ressourcen basierend auf den Rollen einzelner Benutzer oder Servicekonten regelt. Es ist eine entscheidende Verteidigungsschicht, die sicherstellt, dass nur autorisierte Entitäten bestimmte Aktionen auf bestimmten Ressourcen ausführen können.

Im Kern basiert RBAC auf vier Haupttypen von Kubernetes-Objekten:

Role: Eine Role ist eine Reihe von Berechtigungen, die innerhalb eines bestimmten Namespace gelten. Sie definiert, welche Aktionen (Verben wie get, list, create, update, delete) auf welchen Ressourcen (wie pods, deployments, services, secrets) ausgeführt werden können. Beispielsweise könnte eine Role die Berechtigung erteilen, pods und deployments im development-Namespace zu lesen.
ClusterRole: Ähnlich wie eine Role, aber eine ClusterRole definiert Berechtigungen, die clusterweit oder für nicht-namespace-gebundene Ressourcen (z. B. nodes, persistentvolumes) gelten. Eine ClusterRole kann auch Berechtigungen für namespace-gebundene Ressourcen über alle Namespaces hinweg definieren. Beispielsweise könnte eine ClusterRole das Auflisten aller nodes im Cluster erlauben.
RoleBinding: Eine RoleBinding gewährt die in einer Role (oder einer ClusterRole, die namespace-gebunden angewendet wird) definierten Berechtigungen einem Benutzer, einer Gruppe oder einem Servicekonto. Sie operiert immer innerhalb eines bestimmten Namespace.
ClusterRoleBinding: Eine ClusterRoleBinding gewährt die in einer ClusterRole definierten Berechtigungen einem Benutzer, einer Gruppe oder einem Servicekonto und wendet diese Berechtigungen über den gesamten Cluster an.

Zusammen ermöglichen diese Objekte Administratoren den Aufbau eines robusten und granularen Zugriffskontrollsystems. Wenn ein Benutzer oder eine Anwendung (repräsentiert durch ein Servicekonto) versucht, eine Aktion auszuführen, wertet Kubernetes die vorhandenen RoleBindings und ClusterRoleBindings aus, um zu bestimmen, ob die angeforderte Aktion erlaubt ist.

Implementierung des Prinzips der geringsten Privilegien mit RBAC

Ein zentraler Grundsatz der Informationssicherheit ist das Prinzip der geringsten Privilegien. Ein Benutzer, Programm oder Prozess sollte nur die Berechtigungen erhalten, die er für seine Aufgabe benötigt. In Kubernetes sind übermäßig permissive Rollen ein häufiger Weg, wie aus einer kleinen Kompromittierung ein clusterweites Problem werden kann.

Definieren granularer Berechtigungen

Beim Erstellen von RBAC-Richtlinien sollten Sie über die genauen Aktionen und Ressourcen nachdenken, die erforderlich sind:

Verben: Anstatt * (alle Verben) zu gewähren, geben Sie genau an, welche Aktionen benötigt werden (get, list, watch, create, update, delete, patch, exec).
Ressourcen: Seien Sie spezifisch bei den Ressourcen (pods, deployments, secrets, configmaps). Vermeiden Sie es, Zugriff auf * für Ressourcen zu gewähren, es sei denn, es ist absolut notwendig und für gut begründete administrative Rollen.
Ressourcennamen: Für sehr sensible Ressourcen wie secrets können Sie einige Verben, wie get, auf bestimmte resourceNames innerhalb eines Ressourcentyps beschränken. Verlassen Sie sich nicht auf resourceNames für listenartigen Zugriff, da list und watch nicht auf dieselbe Weise auf ein einzelnes benanntes Objekt beschränkt sind.
API-Gruppen: Die meisten Kubernetes-Ressourcen gehören zu einer API-Gruppe (z. B. apps, rbac.authorization.k8s.io, "" für Kernressourcen). Geben Sie die richtige API-Gruppe an, um den Umfang weiter einzuschränken.

Namespace-Begrenzung

Für die meisten Anwendungen und Entwicklungsteams sollten Berechtigungen auf bestimmte Namespaces beschränkt sein. Diese Trennung stellt sicher, dass eine Kompromittierung in der Umgebung einer Anwendung oder eines Teams nicht automatisch zu clusterweitem Zugriff führt. Bevorzugen Sie immer Role und RoleBinding gegenüber ClusterRole und ClusterRoleBinding, wann immer möglich.

Praktische RBAC-Implementierung: Beispiele

Lassen Sie uns einige praktische Beispiele zum Erstellen und Binden von RBAC-Richtlinien durchgehen.

Beispiel 1: Entwicklerzugriff auf einen bestimmten Namespace

Stellen Sie sich vor, ein Entwickler muss Deployments verwalten und Logs in seinem dedizierten Namespace dev-team-a anzeigen. Er sollte keinen Zugriff auf andere Namespaces oder clusterweite Ressourcen haben.

Definieren Sie zunächst eine Role für den Entwickler im Namespace dev-team-a:

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Für Deployments
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: [""] # Core-API-Gruppe für Pods und Pod-Logs
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Wenden Sie diese Rolle an:

kubectl apply -f dev-role.yaml

Binden Sie als nächstes diese Role an einen bestimmten Benutzer (z. B. [email protected] über einen externen Identitätsanbieter) oder ein Servicekonto im Namespace dev-team-a:

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # Name ist case-sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

Wenden Sie diese Bindung an:

kubectl apply -f dev-role-binding.yaml

Jetzt kann [email protected] nur Deployments verwalten und Logs innerhalb des Namespace dev-team-a anzeigen. Er kann beispielsweise keine Secrets in kube-system erstellen oder alle Nodes auflisten.

Beispiel 2: Anwendungs-Servicekonto, das auf Secrets zugreift

Eine Anwendung, die als ServiceAccount läuft, muss ein bestimmtes Secret in ihrem eigenen Namespace lesen.

Stellen Sie zunächst sicher, dass das Servicekonto existiert, oder erstellen Sie eines:

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

Wenden Sie dieses Servicekonto an:

kubectl apply -f app-sa.yaml

Definieren Sie als nächstes eine Role, die das Lesen eines bestimmten Secrets erlaubt:

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

Wenden Sie diese Rolle an:

kubectl apply -f secret-reader-role.yaml

Binden Sie schließlich diese Role an das my-app-service-account:

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Wenden Sie diese Bindung an:

kubectl apply -f app-secret-reader-binding.yaml

Die Anwendung kann jetzt nur das angegebene Secret lesen und sonst nichts.

Beispiel 3: Cluster-Administrator-Rolle (mit Vorsicht)

Clusterweite administrative Rollen sollten äußerst sparsam vergeben werden. Hier ist ein Beispiel für eine ClusterRole zum Auflisten aller Nodes, die für ein Überwachungstool benötigt werden könnte.

# node-viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Wenden Sie diese ClusterRole an:

kubectl apply -f node-viewer-clusterrole.yaml

Binden Sie sie dann mit einer ClusterRoleBinding an ein Überwachungs-Servicekonto:

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Wenden Sie diese Bindung an:

kubectl apply -f monitoring-node-viewer-binding.yaml

Warnung: Seien Sie äußerst vorsichtig mit ClusterRole und ClusterRoleBinding für menschliche Benutzer. Beschränken Sie ihre Verwendung auf echte Cluster-Administratoren und spezifische Infrastruktur-Servicekonten.

Wesentliche RBAC-Best Practices

Die Einhaltung dieser Best Practices wird die Sicherheitslage Ihres Clusters erheblich verbessern:

Durchsetzen des Prinzips der geringsten Privilegien (PoLP):
- Gewähren Sie nur die minimal notwendigen Berechtigungen. Überprüfen Sie jede Berechtigung sorgfältig.
- Vermeiden Sie nach Möglichkeit Platzhalter (*) für resources und verbs. Wenn sie verwendet werden, begründen Sie sie und versuchen Sie, sie so eng wie möglich zu fassen.
- Beschränken Sie den Zugriff auf sensible Ressourcen (wie secrets) durch die Verwendung von resourceNames in Rollen.
Verwenden Sie Namespaces zur Trennung:
- Organisieren Sie Ihre Anwendungen und Teams in separaten Namespaces.
- Verwenden Sie standardmäßig Role und RoleBinding, um Berechtigungen innerhalb dieser Namespaces zu gewähren.
Bevorzugen Sie Rollen gegenüber ClusterRoles:
- Verwenden Sie ClusterRole und ClusterRoleBinding nur, wenn Berechtigungen tatsächlich clusterweit sein müssen (z. B. Node-Verwaltung, benutzerdefinierte Ressourcendefinitionen, bestimmte Überwachungsagenten).
- Die meisten anwendungsspezifischen Berechtigungen sollten namespace-gebunden sein.
Regelmäßige Überprüfung und Auditierung von RBAC-Richtlinien:
- RBAC-Richtlinien können im Laufe der Zeit abweichen. Überprüfen Sie regelmäßig, wer welchen Zugriff hat.
- Verwenden Sie Tools wie kubectl auth can-i, um Berechtigungen für bestimmte Benutzer/Servicekonten zu testen.
```
# Prüfen, ob '[email protected]' Pods in 'dev-team-a' abrufen kann
kubectl auth can-i get pods --namespace=dev-team-a [email protected]

# Prüfen, ob 'monitoring-sa' Nodes auflisten kann (clusterweit)
kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
```
- Ziehen Sie Drittanbieter-Tools oder benutzerdefinierte Skripte für umfassende RBAC-Audits in Betracht.
Trennen Sie administrative Rollen:
- Geben Sie Entwicklern oder Anwendungs-Servicekonten niemals cluster-admin-Berechtigungen.
- Erstellen Sie spezifische administrative ClusterRoles mit nur den notwendigen erhöhten Berechtigungen (z. B. cluster-reader, node-reader).
Nutzen Sie Servicekonten für Anwendungen:
- Anwendungen, die innerhalb des Clusters laufen, sollten ServiceAccounts verwenden, um mit der Kubernetes-API zu interagieren.
- Jede Anwendung oder jeder Microservice sollte idealerweise ein eigenes dediziertes ServiceAccount mit minimalen Berechtigungen haben.
- Setzen Sie automountServiceAccountToken: false für Pods, die keinen Kubernetes-API-Zugriff benötigen, entweder auf dem Pod oder auf dem Servicekonto.
Integration mit externem Identitätsmanagement:
- Für menschliche Benutzer integrieren Sie Kubernetes mit einem externen Identitätsanbieter (z. B. OIDC, LDAP, Active Directory) für Authentifizierung und Gruppenverwaltung.
- Ordnen Sie externe Gruppen zur einfacheren Verwaltung Kubernetes RoleBindings oder ClusterRoleBindings zu.
Automatisieren Sie das RBAC-Management mit GitOps:
- Behandeln Sie Ihre RBAC-Richtlinien als Code. Speichern Sie sie in einem versionierten Repository (Git).
- Verwenden Sie GitOps-Prinzipien, um RBAC-Konfigurationen zu verwalten und bereitzustellen, was Konsistenz, Rückverfolgbarkeit und einfachere Rollbacks gewährleistet.
Überwachen Sie RBAC-Ereignisse über Audit-Logs:
- Aktivieren und konfigurieren Sie Kubernetes-Audit-Logging, um API-Anfragen zu verfolgen, einschließlich wer welche Aktion wann ausgeführt hat.
- Überprüfen Sie regelmäßig Audit-Logs, um nicht autorisierte Zugriffsversuche oder verdächtige Aktivitäten im Zusammenhang mit RBAC zu erkennen.
Aktualisieren Sie Kubernetes regelmäßig:
- Bleiben Sie mit Kubernetes-Versionen auf dem neuesten Stand, um von Sicherheitspatches und Verbesserungen, einschließlich RBAC-Verbesserungen, zu profitieren.

Häufige Fallstricke und wie man sie vermeidet

Übermäßig permissive Platzhalter: Das Gewähren von apiGroups: ["*"], resources: ["*"] oder verbs: ["*"] ist ein großes Sicherheitsrisiko. Seien Sie immer explizit.
Standardmäßige cluster-admin-Nutzung: Verwenden Sie die Gruppe system:masters oder die ClusterRole cluster-admin nicht für den täglichen Betrieb oder weisen Sie sie Nicht-Admin-Benutzern zu. Beide geben weitreichende Kontrolle über den Cluster.
Ignorieren von automountServiceAccountToken: In vielen Clustern erhalten Pods ein Servicekonto-Token, es sei denn, Sie deaktivieren das automatische Einhängen. Wenn ein Pod nicht mit der Kubernetes-API interagieren muss, setzen Sie automountServiceAccountToken: false in der Pod-Spezifikation oder der Servicekonto-Definition, um seine Angriffsfläche zu verringern.
Fehlende Auditierung: Ohne regelmäßige Überprüfung können RBAC-Richtlinien veralten oder übermäßig permissiv werden, wenn sich die Cluster-Anforderungen weiterentwickeln. Implementieren Sie einen Überprüfungsprozess.
Verwechslung von Role und ClusterRole: Ein Missverständnis des Umfangs kann dazu führen, dass clusterweiter Zugriff gewährt wird, obwohl nur namespace-gebundener Zugriff beabsichtigt war.

Fazit

RBAC funktioniert am besten, wenn Sie es langweilig und spezifisch halten: namespace-gebundene Rollen für Anwendungsteams, enge Servicekonto-Berechtigungen, keine Platzhalter ohne Überprüfung und regelmäßige kubectl auth can-i-Prüfungen. Behandeln Sie jede Bindung als Produktionscode, denn in einem Kubernetes-Cluster ist sie das effektiv auch.