RBAC-Autorisierung

Einführung

Die Autorisierung in Kubernetes wird üblicherweise mit RBAC (Role-Based Access Control, rollenbasierte Zugriffskontrolle) umgesetzt.

Benutzer: Eine Mitarbeiterin oder ein Mitarbeiter, zum Beispiel „Jane“.
Role: Eine Zugangskarte mit bestimmten Zugriffsrechten, zum Beispiel „Darf den Serverraum betreten“ oder „Darf Dokumente lesen“.
RoleBinding: Das Aushändigen der Zugangskarte an die Mitarbeiterin oder den Mitarbeiter.

RBAC ist wichtig, weil der Clusterzugriff nicht nur die Authentifizierung umfasst. Sobald die Identität bekannt ist, muss das System weiterhin entscheiden, welche Aktionen diese Identität ausführen darf.

In diesem Lab übernehmen Sie die Rolle der Sicherheitsleitung:

Erstellen Sie einen „Besucherausweis“ (Role), mit dem Ressourcen nur angesehen, aber nicht verändert werden dürfen.
Weisen Sie diesen Ausweis dem Benutzer jane zu.
Überprüfen Sie, dass Jane den Cluster durchsuchen kann, aber abgewiesen wird, sobald sie etwas ändern möchte.

Role definieren

Zuerst erstellen Sie den Berechtigungssatz. Sie benötigen eine „Read-Only“-Role. Diese Role erlaubt es, Pods mit list und get zu lesen, aber nicht, sie mit create zu erstellen oder mit delete zu löschen.

RBAC ist die Kubernetes-Autorisierung, nicht die Authentifizierung. Die Authentifizierung beantwortet die Frage „Wer sind Sie?“. Die Autorisierung beantwortet die Frage „Was dürfen Sie tun?“. In diesem Lab konzentrieren Sie sich auf die zweite Frage, indem Sie ausdrücklich erlaubte Aktionen – sogenannte Verben – für bestimmte Ressourcentypen definieren.

Erstellen Sie eine Datei mit dem Namen role.yaml:

nano role.yaml

Fügen Sie das folgende YAML ein. Diese Definition erstellt eine Role, die die Aktionen „get“, „watch“ und „list“ für „pods“ erlaubt.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""] ## "" indicates the core API group
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Speichern Sie die Datei und beenden Sie den Editor (Ctrl+X, Y, Enter).

Wenden Sie diese Zugangskarte nun auf den Cluster an:

kubectl apply -f role.yaml

Überprüfen Sie, ob die Role vorhanden ist:

kubectl get roles

Die Ausgabe sollte pod-reader enthalten.

Role binden

Sie haben nun die Zugangskarte (pod-reader) und die Mitarbeiterin (jane). Jane besitzt die Zugangskarte jedoch noch nicht. Sie benötigen eine RoleBinding, um beide miteinander zu verknüpfen.

Eine Role gewährt für sich allein keine Berechtigungen, solange sie nicht von einer Binding referenziert wird. Diese Trennung ist beabsichtigt. Administratoren können dadurch wiederverwendbare Berechtigungspakete einmal definieren und sie anschließend nach Bedarf verschiedenen Benutzern, Gruppen oder ServiceAccounts zuweisen.

Erstellen Sie eine Datei mit dem Namen rolebinding.yaml:

nano rolebinding.yaml

Fügen Sie den folgenden Inhalt ein. Damit weisen Sie die Role pod-reader dem Benutzer jane zu.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Speichern Sie die Datei und beenden Sie den Editor (Ctrl+X, Y, Enter).

Wenden Sie die Binding an:

kubectl apply -f rolebinding.yaml

Damit haben Sie Jane offiziell Lesezugriff auf den Namespace default gewährt.

Zugriff überprüfen

Wie testen Sie den Zugriff? Sie müssen sich nicht ab- und als Jane wieder anmelden. Kubernetes ermöglicht es Ihnen, mit der Option --as einen Benutzer zu „imitieren“ und seine Berechtigungen zu testen.

Dies ist eine praktische Technik für die Administration. Berechtigungsprüfungen sind sicherer, wenn Sie eine Identität simulieren können, bevor Sie einem echten Benutzer oder einem Automatisierungskonto Zugriff gewähren. So überprüfen Sie die beabsichtigten Berechtigungen, ohne unnötige Änderungen im Cluster vorzunehmen.

Überprüfen Sie, ob Jane Pods auflisten darf:

kubectl auth can-i list pods --as jane

Die Ausgabe sollte yes lauten.

Sie können auch prüfen, ob Jane die Details eines bestimmten Pods abrufen darf:

kubectl auth can-i get pods --as jane

Auch diese Ausgabe sollte yes lauten.

Damit ist bestätigt, dass die RoleBinding funktioniert. Die Zugangskarte funktioniert an den Türlesern!

Einschränkungen überprüfen

Sicherheit bedeutet auch, zu wissen, was Sie nicht tun dürfen. Da Jane nur die Role pod-reader besitzt, muss es ihr strikt verboten sein, Änderungen vorzunehmen.

Hier zeigt sich das Prinzip der geringsten Berechtigungen (Least Privilege). Statt weitreichenden Zugriff zu gewähren und darauf zu hoffen, dass alle vorsichtig handeln, beginnen Sie mit den für die Aufgabe erforderlichen Mindestberechtigungen und erweitern diese nur bei einem tatsächlichen betrieblichen Bedarf.

Prüfen Sie, ob Jane einen Pod erstellen darf:

kubectl auth can-i create pods --as jane

Die Ausgabe sollte no lauten.

Prüfen Sie, ob Jane einen Pod löschen darf:

kubectl auth can-i delete pods --as jane

Die Ausgabe sollte no lauten.

Wenn Jane diese Aktionen tatsächlich ausführen würde, würde der API-Server ihre Anfrage mit einem Fehler „Forbidden“ ablehnen. Damit bestätigen Sie, dass Ihr Cluster abgesichert ist und dem Prinzip der geringsten Berechtigungen (Least Privilege) folgt.

Zusammenfassung

In diesem Lab haben Sie Ihren Cluster mit RBAC abgesichert.

Sie haben erfolgreich:

Eine Role („Zugangskarte“) mit eingeschränkten Leseberechtigungen erstellt.
Eine RoleBinding erstellt, um diese Zugangskarte dem Benutzer jane zu geben.
Überprüft, dass jane Ressourcen ansehen, aber nicht verändern darf.

Dies bildet die Grundlage für die Sicherheit in Kubernetes-Umgebungen mit mehreren Benutzern. Gewähren Sie niemals allen vollständigen Administratorzugriff!