Rollenbasierte Zugangskontrolle in Kubernetes verwalten

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"

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}'

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

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.

Ü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

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.