ake1150 - stock.adobe.com

Rollenbasierte Zugangskontrolle in Kubernetes verwalten

Kubernetes RBAC verfügt über Funktionen, die IT-Teams viel Zeit und Nerven sparen können. Diese kurze Anleitung führt durch das Planen neuer Rollen zur Berechtigungsverwaltung.

Die rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC) ist ein Autorisierungsmechanismus, mit dem Administratoren den Benutzerzugriff auf eine Ressource oder ein System über Standard- oder benutzerdefinierte Rollen einschränken und steuern.

Sie können Containerumgebungen mit diesem Ansatz einfacher verwalten, müssen jedoch bestimmte Prozesse anwenden, damit sie kein unnötig komplexes System erstellen. Alle Kubernetes-RBAC-Autorisierungsregeln in einem Cluster werden von der API-Gruppe rbac.authorization.k8s.io gesteuert.

Es hat sich bewährt, RBAC-Rollen im Cluster immer zu aktivieren, damit Projekte – und die gesamte Organisation – ein möglichst hohes Sicherheitsniveau erreichen.

Zu den Best Practices von Kubernetes RBAC gehören:

  • Vergeben Sie stets so wenig Privilegien wie möglich. Standardmäßig wird jeglicher Zugriff verweigert, wenn RBAC aktiviert ist. IT-Administratoren definieren davon ausgehend Benutzerberechtigungen im Detail. Gewähren Sie Benutzern nur die absolut erforderlichen Berechtigungen. Jede unnötige Freigabe erhöht das Sicherheitsrisiko und die vergrößert die Angriffsfläche. Sie sollten zum Beispiel Berechtigungen auf Clusteradministratorebene nicht auf alle IT-Mitarbeiter ausdehnen.
  • Passen Sie die RBAC-Strategie kontinuierlich an. Rollenbasierte Zugangskontrollen sind keine statische Angelegenheit. Gehen Sie beim Testen und Validieren von RBAC langsam vor und führen Sie die Rollen und Berechtigungen in Phasen ein; finden Sie Kompromisse mit Mitarbeitern, damit Sicherheit und Nutzererfahrung sich das Gleichgewicht halten. Legen Sie ein Intervall fest, nach dem Sie den bisherigen Erfolg evaluieren und die Umgebung regelmäßig auf Lücken oder Verbesserungsmöglichkeiten untersuchen. Dazu gehört auch, das System zu bereinigen, wenn es Änderungen im Unternehmen gab – beispielsweise Teamwechsel, Beförderungen oder Mitarbeiter, die Ihre Organisation verlassen haben.
  • Rollen wiederverwenden und sparsam erstellen. Erstellen Sie keine Kubernetes-RBAC-Rollen, um den Anforderungen von Einzelpersonen gerecht zu werden: Das erhöht das Risiko und macht den Nutzen rollenbasierter Zugangskontrollen zunichte – schließlich heißt es nicht nutzerbasierte Ihre Rollen sollten wiederverwendbar sein und reale Benutzergruppen im Unternehmen wiederspiegeln, die alle dieselben Rechte erhalten. Konsequenz beim Erstellen und Verteilen von Rollen reduziert den Verwaltungsaufwand für Administratoren erheblich.

Roles, ClusterRoles, RoleBindings, ClusterRoleBindings und Subjects

Das Kubernetes RBAC-Modell besteht aus drei Hauptkomponenten:

  • Role und ClusterRole. Hierbei handelt es sich um eine Reihe von Berechtigungen, die sich durch ihre jeweilige Geltung unterscheiden. Roles legen Berechtigungen auf Namespace-Ebene fest, während ClusterRoles Berechtigungen auf Clusterebene oder für alle im Ökosystem vorhandenen Namensräume definieren.
  • RoleBinding und ClusterRoleBinding. Diese Komponenten sind eine Spezies-Liste von Subjekten und ihre entsprechenden Rollenzuweisungen. RoleBindings binden Komponenten an Rollen; ClusterRoleBindings binden eine ClusterRole an alle Namespaces.
  • Subjects. Benutzer, Gruppen und Dienstkonten werden in RBAC-Regeln als Subjects bezeichnet.

Bevor wir lernen können, wie IT-Administratoren RBAC-Komponenten in Kubernetes implementieren, erstellen wir ein Benutzerkonto in einer Testumgebung. Wir verwenden für diese Anleitung ein X.509-Zertifikat, ein ServiceAccount funktioniert ebenso. Der Einfachheit halber arbeiten wir jedoch mit einem normalen Benutzerkonto.

Erstellen Sie ein Kubernetes-Benutzerkonto mit einem Zertifikat

Erstellen Sie ein Benutzerkonto, einen neuen Mitarbeiter, und führen Sie den Befehl openssl aus, um einen privaten Schlüssel zu generieren:

openssl genrsa -out neuermitarbeiter.key 2048

Als nächstes stellen Sie eine Certificate Signing Request (CSR) mit dem Nutzernamen des neuen Mitarbeiters (neuermitarbeiter), den wir gerade erstellt haben.

openssl req -new -key neuermitarbeiter.key -out neuermitarbeiter.csr -subj "/CN=neuermitarbeiter"

So erstellen Sie einen privaten RSA-Schlüssel
Abbildung 1: Generieen Sie einen privaten RSA-Schlüssel.

Melden Sie sich mit einer Kubernetes-Zertifizierungsstelle an (Certificate Authority, CA); weil wir in dieser Anleitung Minikube verwenden, befinden sich in unserem Fall das Clusterzertifikat und der Schlüssel im Ordner ~/minikube/. Auf diesem Weg erhalten wir ein Nutzerzertifikat namens neuermitarbeiter.crt, das für 365 Tage gültig ist.

openssl x509 -req -in neuermitarbeiter.csr -CA ~/.minikube/ca.crt -CAkey ~/.minikube/ca.key -CAcreateserial -out neuermitarbeiter.crt -days 365

Nun erstellen wir Nutzer innerhalb des Kubernetes-Clusters:

kubectl config set-credentials neuermitarbeiter --client-certificate=neuermitarbeiter.crt --client-key=neuermitarbeiter.key

Wir können den neuen Benutzer auch schnell über den folgenden Befehl validieren:

kubectl config view -o jsonpath='{.users[*].name}'

Validieren eines Nutzerkontos in Kubernetes
Abbildung 2: Validieren Sie das neue Nutzerkonto.

Jetzt haben wir einen neuen Benutzer (Subject) in Kubernetes und können eine Rolle einrichten sowie dem Benutzer zuweisen (RoleBinding).

Erstellen einer Rolle und binden der Rolle an das Benutzerkonto

Im Folgenden richten wir einen neuen Namensraum ein und stellen einen einfachen Nginx-Server als Pod im neuen Namespace bereit:

kubectl create namespace webserver

kubectl create deployment my-nginx --image nginx --namespace webserver

Erstellen eines neuen Namensraums
Abbildung 3: Richten Sie einen neuen Namensraum ein.

Kopieren Sie die folgende YAML-Konfiguration und speichern Sie sie in einer Datei mit dem Namen role.yaml: Diese Datei definiert eine Rolle, die nur die Listenoperation für die Nginx-Pods ausführt. Diese Rolle ist an den im obigen Abschnitt erstellten neuen Mitarbeiter gebunden.

kind: Role

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: list-pods

rules:

 - apiGroups: ["*"]

   resources: ["pods"]

   verbs: ["list"]

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: neuermitarbeiter-list-pods

subjects:

 - apiGroup: ""

   kind: User

   name: neuermitarbeiter

roleRef:

 apiGroup: ""

 kind: Role

 name: list-pods

Wenden Sie diese Konfiguration dann mit dem Befehl kubectl apply -f. \ Role.yaml --namespace webserver auf den Namespace an.

Anwenden der YAML-Konfiguration
Abbildung 4: Wenden Sie die YAML-Konfiguration an.

Übergeben Sie den Benutzernamen an den Parameter --user des Befehls kubectl get pods, der die im Namespace ausgeführten Pods auflistet. Wenn wir versuchen, eine andere Operation auszuführen, zum Beispiel delete, gibt die Konsole einen forbidden-Fehler zurück. Das RBAC-Modell in dieser Anleitung erlaubt es dem neuen Mitarbeiter nicht, einen Löschvorgang auszuführen.

kubectl get pods --namespace webserver --user neuermitarbeiter

kubectl delete pod <Name des Pods> --namespace webserver --user neuermitarbeiter

Ausgabe beim Ausführen einer unerlaubten Aktion
Abbildung 5: So sieht es aus, wenn ein Mitarbeiter einen Befehl auszuführen versucht, für den er keine Berechtigung hat.

Ausweiten von Rechten

IT-Teams begegnen im gewöhnlichen Betrieb häufig Situationen, in denen sie Berechtigungen für bestimmte Benutzer ausweiten müssen. Lassen Sie uns daher unserem Beispielnutzer zusätzlich zu den Listen- auch die Löschfunktionen freischalten.

Speichern Sie die folgende Datei als role.yaml – wie Sie sehen, ist delete nun als für den Benutzer genehmigter Befehl aufgelistet.

kind: Role

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: list-pods

rules:

 - apiGroups: ["*"]

   resources: ["pods"]

   verbs: ["list","delete"]

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

 name: neuermitabeiter-list-pods

subjects:

 - apiGroup: ""

   kind: User

   name: neuermitarbeiter

roleRef:

 apiGroup: ""

 kind: Role

 name: list-pods

Wenden Sie diese Konfiguration erneut an.

kubectl apply -f .\role.yaml --namespace webserver

kubectl delete pod <Name des Pods> --namespace webserver --user neuermitarbeiter

Die Nutzerrolle neuermitarbeiter darf nun Pods in ihrem Namespace löschen.

Zusätzliche Rechte zu einer Rolle durchführen
Abbildung 6: So erweitern Sie die Rechte einer Rolle.

Fortsetzung des Inhalts unten

Erfahren Sie mehr über Identity and Access Management (IAM)

ComputerWeekly.de
Close