Rollenbasierte Zugriffskontrolle (RBAC) in Kubernetes

Rollenbasierte Zugriffskontrolle (RBAC) wird verwendet, um den Zugriff auf Computer- oder Netzwerkressourcen im Kubernetes-Cluster zuzuweisen.

In diesem Artikel werden wir die Grundlagen von RBAC verstehen und die Objekte Role, ClusterRole, RoleBinding und ClusterRoleBinding erstellen.

Wir werden dann eine kubeconfig-Datei erstellen, um einem bestimmten Benutzer eingeschränkten Zugriff auf einen ausgewählten Namespace zu gewähren.

Aber bevor wir fortfahren, lassen Sie uns zuerst die Grundlagen verstehen.

1. Eine Role oder ClusterRole enthält eine Reihe von Berechtigungen.
2. Eine Role legt Berechtigungen innerhalb eines bestimmten Namespaces fest, während ClusterRole eine nicht-namespaced Ressource ist.
3. Ein RoleBinding gewährt die in einer Role definierten Berechtigungen einem Benutzer oder einer Benutzergruppe, während ClusterRoleBinding diesen Zugriff clusterweit gewährt.
4. Ein RoleBinding kann auf jede Role im selben Namespace verweisen. Alternativ kann ein RoleBinding auf eine ClusterRole verweisen und diese ClusterRole an den Namespace des RoleBindings binden.
5. Eine kubeconfig-Datei ist eine Datei, die verwendet wird, um den Zugriff auf Kubernetes über das kubectl-Befehlszeilenwerkzeug zu konfigurieren.

Um RBAC im Detail zu verstehen, besuchen Sie die offizielle Dokumentation von Kubernetes hier.

Hinweis: Verweisen Sie auf Screenshots, um Verwirrung vor der Ausführung der Befehle zu vermeiden. ( ubuntu@master = master node und ubuntu@ip-172-31-25-70 = Benutzermaschine)

Voraussetzungen

1. Kubernetes-Cluster mit mindestens 1 Worker-Node.
   Wenn Sie lernen möchten, wie man ein Kubernetes-Cluster erstellt, klicken Sie hier. Dieser Leitfaden hilft Ihnen, ein Kubernetes-Cluster mit 1 Master und 2 Nodes auf AWS Ubuntu EC2-Instanzen zu erstellen.

Was werden wir tun?

1. Erstellen von Dateien für Role, Role Binding, Cluster Role, Cluster Role Binding.
2. Erstellen von Role, Role Binding, Cluster Role, Cluster Role Binding Objekten im Cluster.
3. Bereitstellung des Zugriffs für Benutzer mithilfe der kubeconfig-Datei.
4. Zusammenfassung der Erstellung der kubeconfig-Datei.

Erstellen von Role, Role Binding, Cluster Role, Cluster Role Binding Objektdateien.

Erstellen Sie eine Datei, um eine Role im “default” Namespace zu erstellen, die verwendet werden kann, um den Zugriff auf Pods zu gewähren, um sie zu erhalten, zu beobachten und aufzulisten.

vim my-role.yml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Erstellen Sie eine neue Datei, um ein RoleBinding zu erstellen, das der Benutzerin “jane” innerhalb des “default” Namespace die Role “pod-reader” zuweist.

vim my-role-binding.yml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Erstellen Sie eine Datei, um eine ClusterRole zu erstellen, die verwendet werden kann, um den Zugriff auf Secrets in einem bestimmten Namespace oder in allen Namespaces, je nachdem, wie sie gebunden ist, zu gewähren.

vim my-cluster-role.yml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Erstellen Sie eine neue Datei, um ein ClusterRoleBinding zu erstellen, das es jedem Benutzer in der Gruppe “manager” ermöglicht, Secrets in jedem Namespace zu lesen.

vim my-cluster-role-binding.yml

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Erstellen von Role, Role Binding, Cluster Role, Cluster Role Binding Objekten.

Holen Sie sich eine Liste der vorhandenen Roles und ClusterRoles aus dem Cluster.

kubectl get roles

kubectl get clusterroles

Holen Sie sich eine Liste der vorhandenen RoleBindings und ClusterRoleBindings aus dem Cluster.

kubectl get rolebinding

kubectl get clusterrolebinding

Erstellen Sie nun eine Role, ein RoleBinding und ein ClusterRole, ClusterRoleBinding mit den Dateien, die wir in den obigen Schritten erstellt haben.

kubectl create -f my-role.yml

kubectl create -f my-role-binding.yml

kubectl create -f my-cluster-role.yml

kubectl create -f my-cluster-role-binding.yml

Verwenden Sie die folgenden Befehle, um zu überprüfen, ob die Objekte erstellt wurden.

kubectl get roles | grep pod-reader

kubectl get rolebinding | grep read-pods

kubectl get clusterroles | grep secret-reader

kubectl get clusterrolebinding | grep read-secrets-global

Im obigen Screenshot sehen Sie, dass die Role, das RoleBinding und die ClusterRole, das ClusterRoleBinding erstellt wurden.

Bereitstellung des Zugriffs für Benutzer mithilfe der kubeconfig(config) Datei.

Jetzt werden wir in diesem Abschnitt eine Konfigurationsdatei erstellen, die mit einem Benutzer geteilt werden kann. Hier, um dieses Szenario zu testen, werden wir einen Benutzer “bob” auf dem Linux-Server erstellen und diese Konfigurationsdatei mit dem Benutzer “bob” teilen. Wir werden dann versuchen, Operationen durchzuführen, die diesem Benutzer erlaubt und nicht erlaubt sind. Wir werden eine Admin-ClusterRole an den Benutzer “bob” binden, die Zugriff auf alle Objekte innerhalb des “bob” Namespaces gewährt.

Erstellen Sie auf den Master-Knoten einen Schlüssel und eine Zertifikatsanfrage (CSR) mit openssl.

pwd

mkdir user-bob

cd user-bob/

openssl req -new -newkey rsa:4096 -nodes -keyout bob-k8s.key -out bob-k8s.csr -subj "/CN=bob/O=devops"

cat bob-k8s.csr | base64 | tr -d '
'

Erstellen Sie eine Definition für ein CertificateSigningRequest-Objekt, das die CSR enthält, die wir im obigen Schritt generiert haben. Fügen Sie in der untenstehenden Datei die Ausgabe des Befehls “cat bob-k8s.csr | base64 | tr -d ‘ ‘“ in die “request”-Eigenschaft ein.

vim k8s-csr.yaml

apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: bob-k8s-access
spec:
  groups:
  - system:authenticated
  request: # ersetzen Sie die Ausgabe von: cat bob-k8s.csr | base64 | tr -d '
'
  usages:
  - client auth

cat k8s-csr.yaml

Erstellen Sie ein CertificateSigningRequest-Objekt innerhalb von Kubernetes, das die CSR enthält, die wir im obigen Schritt generiert haben.

kubectl get csr

kubectl create -f k8s-csr.yaml

kubectl get csr

Jetzt möchten wir das CSR (CertificateSigningRequest)-Objekt genehmigen, das wir im obigen Schritt erstellt haben.

kubectl get csr

kubectl certificate approve bob-k8s-access

kubectl get csr

Im obigen Screenshot sehen Sie, dass das CSR genehmigt und ausgestellt wurde.

Rufen Sie das Zertifikat ab, das im Feld „status.certificate“ des CSR-Objekts verfügbar ist.

ls -lt

kubectl get csr bob-k8s-access -o jsonpath='{.status.certificate}' | base64 --decode > bob-k8s-access.crt

ls -lt

cat bob-k8s-access.crt

Rufen Sie das Cluster-CA-Zertifikat ab, das die nächste Anforderung für Bobs kubeconfig-Datei ist, und speichern Sie es in der Datei “k8s-ca.crt”.

ls -lt

kubectl config view -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' --raw | base64 --decode - > k8s-ca.crt

ls -lt

cat k8s-ca.crt

Richten Sie die Clusterkonfiguration in Bobs kubeconfig-Datei ein. Alle diese Details werden aus unserer vorhandenen kubeconfig mit dem folgenden Befehl übernommen.

ls -lt

kubectl config set-cluster $(kubectl config view -o jsonpath='{.clusters[0].name}') --server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') --certificate-authority=k8s-ca.crt --kubeconfig=bob-k8s-config --embed-certs

ls -lt

cat bob-k8s-config

Richten Sie den Benutzer ein, der Bobs Schlüssel und Zertifikat in die Konfigurationsdatei importiert.

ls -lt

kubectl config set-credentials bob --client-certificate=bob-k8s-access.crt --client-key=bob-k8s.key --embed-certs --kubeconfig=bob-k8s-config

ls -lt

cat bob-k8s-config

Erstellen Sie einen Kontext für Bobs Konfigurationsdatei mit dem folgenden Befehl.

ls -lt

kubectl config set-context bob --cluster=$(kubectl config view -o jsonpath='{.clusters[0].name}') --namespace=bob --user=bob --kubeconfig=bob-k8s-config

ls -lt

cat bob-k8s-config

Erstellen Sie einen Namespace für Bob

kubectl get ns

kubectl create ns bob

kubectl get ns -o wide

kubectl label ns bob user=bob env=sandbox

kubectl get ns -o wide

Geben Sie den Kontext an, den Bob für seine kubectl-Befehle verwenden wird.

cat bob-k8s-config

kubectl config use-context bob --kubeconfig=bob-k8s-config

cat bob-k8s-config

Kopieren Sie “bob-k8s-config” vom Master-Knoten in die Datei “.kube/config” im Home-Verzeichnis von Bob und testen Sie Bobs kubeconfig, indem Sie den Befehl ‚kubectl version‘ ausführen.

vim .kube/config #Alle Ausgaben des Befehls "cat bob-k8s-config" auf dem Master-Knoten ausführen und in /home/bob/.kube/config auf der Benutzermaschine speichern.

kubectl version #Führen Sie dies auf der Benutzermaschine aus

Testen Sie die Berechtigungen, indem Sie die folgenden Befehle von der Benutzermaschine ausführen.

kubectl get nodes

kubectl get pods

kubectl get ns

kubectl get deployments

kubectl get all

Im obigen Screenshot sehen Sie, dass der Benutzer “Bob” keine Operationen durchführen kann, da ihm kein Zugriff gewährt wurde.

Weisen Sie die Standard-„admin“-Clusterrolle an Bob zu, um die meisten Arten von Kubernetes-Objekten innerhalb seines Namespaces zu erstellen. Diese Rolle “bob-admin” gewährt dem Benutzer “Bob” Administratorzugriff auf den Namespace “bob” mithilfe der “admin” ClusterRole.

Führen Sie den folgenden Befehl auf dem Master-Knoten aus.

kubectl create rolebinding bob-admin --namespace=bob --clusterrole=admin --user=bob 

kubectl get rolebinding

kubectl get clusterrole | grep admin

Holen Sie sich die Namespaces, die Bob erstellt hat.

Führen Sie jetzt alle folgenden Befehle von der Benutzermaschine aus.

kubectl get ns

kubectl get ns bob

Im obigen Screenshot sehen Sie, dass der Benutzer “Bob” nicht in der Lage ist, “Namespace”-Ressourcen aufzulisten.

Erstellen Sie ein Pod im Namespace “bob”, der als Standardnamespace in Bobs kubeconfig-Datei festgelegt ist.

kubectl run nginx --image=nginx

kubectl get pods

kubectl get pods -o wide

Überprüfen Sie den aktuellen Namespace, der als Standardnamespace festgelegt ist.

kubectl config get-contexts

Im obigen Screenshot sehen Sie, dass “Bob” in der Lage ist, ein Pod im Namespace “bob” zu erstellen, da wir die “admin”-Rolle an den Benutzer “Bob” für den Namespace “bob” gebunden haben.

Versuchen Sie, ein Pod im “default” Namespace zu erstellen, für den Bob keine Berechtigungen hat. Da wir dem Benutzer “Bob” nur erlaubt haben, Objekte im Namespace “bob” zu erstellen, kann der Benutzer Bob keine Ressourcen in einem anderen Namespace als “bob” erstellen.

kubectl run nginx-2 --image=nginx --namespace=default

Überprüfen Sie den Namespace, der als Standardnamespace in der kubeconfig-Datei festgelegt ist. Dies zeigt, dass der Namespace “bob” als Standardnamespace in der Konfigurationsdatei festgelegt ist.

kubectl config view --minify | grep namespace:

Zusammenfassung der Erstellung der Kubeconfig-Datei

1. Erstellen Sie einen Schlüssel und eine Zertifikatsanfrage (CSR) mit openssl.
2. Erstellen Sie eine Definition für ein CertificateSigningRequest-Objekt.
3. Erstellen Sie ein CertificateSigningRequest-Objekt.
4. Genehmigen Sie das CSR (CertificateSigningRequest).
5. Rufen Sie das Zertifikat des CSR-Objekts ab.
6. Rufen Sie das Cluster-CA-Zertifikat ab.
7. Richten Sie die Clusterkonfiguration in der kubeconfig-Datei ein.
8. Richten Sie den Benutzer ein.
9. Erstellen Sie einen Kontext.
10. Erstellen Sie einen Namespace für den Benutzer.
11. Geben Sie den Kontext in der kubeconfig-Datei an.
12. Geben Sie die kubeconfig an den Benutzer weiter.
13. Testen Sie die Berechtigungen mit der Konfigurationsdatei des Benutzers.
14. Weisen Sie die Rolle dem Benutzer zu.
15. Testen Sie die Berechtigungen erneut mit der Konfigurationsdatei des Benutzers.

Fazit

In diesem Artikel haben wir die Grundlagen von Role, RoleBinding und ClusterRole, ClusterRoleBinding gesehen und diese Objekte in unserem Cluster erstellt. Wir haben dann eine Konfigurationsdatei erstellt, die es einem bestimmten Benutzer ermöglicht, Operationen in einem bestimmten Namespace durchzuführen. Wir haben gesehen, wie RBAC uns helfen kann, den Zugriff auf den Kubernetes-Cluster einzuschränken.