Geekly articles weekly

Kubernetes RBAC Benutzer und Autorisierung

Hinweis perev. : Wir setzen das kürzlich angesprochene Thema Kubernetes Sicherheit im Allgemeinen und RBAC im Besonderen fort und veröffentlichen eine Übersetzung dieses Materials von einem französischen Berater des internationalen Unternehmens Adaltas Big Data. Der Autor zeigt im Detail, wie Benutzer erstellt, ihnen Rechte erteilt und weiterhin bereitgestellt werden.

Das Einrichten und Starten eines Kubernetes-Clusters ist nur der Anfang: Es muss ebenfalls ausgenutzt werden. Um den Zugriff auf den Cluster zu sichern, müssen Sie Benutzeranmeldeinformationen festlegen und die Authentifizierungs- und Autorisierungseinstellungen korrekt verwalten.

(Abbildung aus dem CNCF-Blog - ca. übersetzt.)

In diesem Artikel wird beschrieben, wie Sie Benutzer mit X.509- Clientzertifikaten erstellen und die Autorisierung mithilfe der grundlegenden RBAC- APIs in Kubernetes verwalten. Wir werden auch über einige Open-Source-Projekte sprechen, die die Clusterverwaltung vereinfachen: rakkess, kubectl-who-can, rbac-lookup und RBAC Manager.

Voraussetzungen und Annahmen


Zunächst müssen mehrere Annahmen getroffen werden:


Wenn Sie keinen vorgefertigten Kubernetes-Cluster haben, empfehlen wir Ihnen, auf den Artikel eines Kollegen (Arthur BUSSER) zu verweisen, in dem er über die Installation von Kubernetes unter CentOS 7 mit Vagrant spricht.

Es gibt 4 Knoten in unserem Cluster: einen Master und 3 Worker. Der Assistent wird auch als Randknoten für die Interaktion mit dem Cluster verwendet.

RBAC-APIs


Die rollenbasierte Zugriffssteuerung (RBAC) ist eine Methode zur Steuerung des Zugriffs auf Computer und Netzwerkressourcen, basierend auf den Rollen einzelner Benutzer in einem Unternehmen. RBAC kann mit allen Kubernetes-Ressourcen verwendet werden, die CRUD unterstützen (Erstellen, Lesen, Aktualisieren, Löschen). Beispiele für solche Ressourcen:

  • Namespaces
  • Pods
  • Bereitstellungen
  • persistente Volumes (PersistentVolumes);
  • ConfigMaps

Und hier sind Beispiele für mögliche Operationen mit ihnen:

  • create ;
  • get
  • delete (löschen) ;
  • list (Listenansicht) ;
  • update .

Um RBAC in Kubernetes zu verwalten, müssen wir Folgendes deklarieren:

  • Role und ClusterRole . Dies sind einfach Regelsätze, die eine Reihe von Berechtigungen darstellen. Role kann nur verwendet werden, um den Zugriff auf Ressourcen in Namespaces zu ermöglichen. ClusterRole kann dieselben Berechtigungen wie Role bereitstellen und auch Zugriff auf Ressourcen gewähren, die im gesamten Cluster verfügbar sind, sowie auf sogenannte Nicht-Ressourcen-Endpunkte (wie /healthz - ca. Transl.) .
  • Subjects Der Betreff ist eine Entität, die Operationen in einem Cluster ausführt. Dies können Benutzer, Dienste oder sogar Gruppen sein.
  • RoleBinding und ClusterRoleBinding . Wie der Name schon sagt, handelt es sich lediglich um eine Bindung des Betreffs an Role oder ClusterRole.

Kubernetes hat die folgenden Standardrollen:

  • view : Nur-Lese-Zugriff, schließt Geheimnisse aus;
  • edit : Das oben Genannte + die Fähigkeit, die meisten Ressourcen zu bearbeiten, schließt Rollen und Rollenbindungen aus.
  • admin : die oben genannten + die Fähigkeit, Rollen und Rollenzuordnungen auf Namespace-Ebene zu verwalten;
  • cluster-admin : Alle möglichen Berechtigungen.

Natürlich können Sie Ihre eigenen Roles und ClusterRoles erstellen. Wir empfehlen jedoch, die Standardrollen so weit wie möglich zu verwenden, sofern die Situation dies zulässt. Andernfalls können Sie schnell verwirrt werden.

Anwendungsbeispiel


Wir werden zwei Namespaces erstellen: my-project-dev und my-project-prod sowie zwei Benutzer: jean und sarah - mit unterschiedlichen Rollen in diesen Namespaces:

  • my-project-dev:
    • Jean: Bearbeiten
  • my-project-prod:
    • Jean: Ansicht
    • sarah: bearbeiten

Erstellen und authentifizieren Sie Benutzer mithilfe von X.509-Clientzertifikaten


In der Regel gibt es zwei Arten von Benutzern: von Kubernetes verwaltete Dienstkonten und reguläre Benutzer. Wir werden uns auf Letzteres konzentrieren. So werden sie in der offiziellen Dokumentation beschrieben:

Es wird davon ausgegangen, dass reguläre Benutzer von einem externen, unabhängigen Dienst verwaltet werden. Die Rolle kann von einem Administrator gespielt werden, der private Schlüssel verteilt, von einem Benutzer-Repository wie Keystone oder Google Accounts oder sogar von einer Datei mit einer Liste von Benutzernamen und Kennwörtern. In dieser Hinsicht hat Kubernetes keine Objekte, die normale Benutzer darstellen. Normale Benutzer können nicht über einen API-Aufruf zum Cluster hinzugefügt werden.

Es gibt verschiedene Möglichkeiten, reguläre Benutzer zu verwalten:

  • Grundlegende Authentifizierung :
    • Übertragen der Konfiguration auf den API-Server mit den folgenden (oder ähnlichen) Inhalten: Kennwort, Benutzername, UID, Gruppe;
  • X.509 Client-Zertifikat:
    • Erstellung eines geheimen Schlüssels und einer Zertifikatsignierungsanforderung eines Benutzers;
    • Zertifizierung in einer Zertifizierungsstelle (Kubernetes CA), um ein Benutzerzertifikat zu erhalten;
  • Inhaber-Token (JSON Web Tokens, JWT):
    • OpenID Connect
    • Authentifizierungsschicht über OAuth 2.0;
    • Webhooks

In diesem Artikel werden X.509- und OpenSSL-Zertifikate aufgrund ihrer Einfachheit verwendet. Das Erstellen von Benutzern erfolgt in mehreren Schritten - wir werden sie alle durchgehen. Vorgänge sollten unter dem Benutzerkonto mit Administratorrechten des Clusters (Cluster-Administrator) ausgeführt werden. Hier sind alle Schritte zum Erstellen eines Benutzers (am Beispiel von jean ):

  • Erstellen Sie im Assistenten einen Benutzer, und wechseln Sie in sein Ausgangsverzeichnis, um die verbleibenden Schritte auszuführen:

     useradd jean && cd /home/jean
  • Erstellen Sie einen privaten Schlüssel:

     openssl genrsa -out jean.key 2048
  • Erstellen Sie eine Zertifikatsignierungsanforderung (CSR). CN ist der Benutzername, O ist die Gruppe. Sie können Berechtigungen nach Gruppe festlegen. Dies vereinfacht die Arbeit, wenn Sie beispielsweise viele Benutzer mit denselben Berechtigungen haben:

     #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3"
  • Unterzeichnen Sie CSR in Kubernetes CA. Wir müssen das CA-Zertifikat und den CA-Schlüssel verwenden, die normalerweise in /etc/kubernetes/pki . Das Zertifikat ist 500 Tage gültig:

     openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500
  • Erstellen Sie das Verzeichnis .certs . Darin speichern wir die öffentlichen und privaten Schlüssel des Benutzers:

     mkdir .certs && mv jean.crt jean.key .certs
  • Erstellen Sie einen Benutzer in Kubernetes:

     kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key
  • Kontext für Benutzer festlegen:

     kubectl config set-context jean-context \ --cluster=kubernetes --user=jean
  • Bearbeiten Sie die Benutzerkonfigurationsdatei. Es enthält die für die Authentifizierung in einem Cluster erforderlichen Informationen. Sie können die Cluster-Konfigurationsdatei verwenden, die normalerweise in /etc/kubernetes : Die certificate-authority-data und server sollten mit denen in der genannten Datei identisch sein:

     apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key

    Jetzt müssen Sie die obige Konfiguration in das .kube Verzeichnis .kube :

     mkdir .kube && vi .kube/config
  • Es bleibt, den Benutzer zum Eigentümer aller erstellten Dateien und Verzeichnisse zu machen:

     chown -R jean: /home/jean/

User jean erfolgreich erstellt. Wir werden das Gleiche für sarah tun. Es gibt einige Schritte, und das Erstellen einer großen Anzahl von Benutzern kann lange dauern. Deshalb habe ich Bash-Skripte geschrieben, die den Prozess automatisieren: Sie befinden sich im Repository auf GitHub .

Hinweis perev. : Wie wir in unserem kürzlich erschienenen Artikel geschrieben haben , kann dieses Verfahren für Kubernetes auf eine „native“ Weise vereinfacht werden - durch neue Funktionen im Dienstprogramm kubeadm console . Beachten Sie jedoch, dass diese zum Zeitpunkt der Veröffentlichung dieser Übersetzung in Alpha-Form verfügbar sind. Ein Beispiel für einen Befehl zum Erstellen eines Benutzers ist kubeadm alpha kubeconfig user .

Wir haben jetzt Benutzer und können zwei Namespaces erstellen:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod

Da wir die Benutzerberechtigung noch nicht festgelegt haben, sollten sie keinen Zugriff auf Clusterressourcen haben:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev"

Erstellung von Rolle und ClusterRole


Wir werden ClusterRole , das standardmäßig verfügbar ist. Wir zeigen jedoch auch, wie Sie Ihre eigene Role und ClusterRole . Im Wesentlichen sind Role und ClusterRole nur eine Reihe von Aktionen ( verbs , ClusterRole wörtlich - Verben) , die für bestimmte Ressourcen und Namespaces zulässig sind. Hier ist eine Beispiel-YAML-Datei:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ]

Führen Sie den folgenden Befehl aus, um sie zu erstellen:

 kubectl create -f /path/to/your/yaml/file

Bindungsrolle oder Clusterrolle an Benutzer


Binden Sie nun die Standard- ClusterRole ( edit und view ) wie folgt an unsere Benutzer:

  • jean :
    • edit - im Namespace my-project-dev ;
    • view - im Namespace my-project-prod ;
  • sarah :
    • edit - im Namespace my-project-prod .

RoleBindings müssen durch Namespaces angegeben werden, nicht durch Benutzer. Mit anderen Worten, um Jean zu autorisieren, erstellen wir zwei RoleBindings. Ein Beispiel für eine YAML-Datei, die RoleBindings für Jean definiert:

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io

Wir erlauben jean , my-project-prod view und my-project-dev bearbeiten. Das gleiche muss mit Berechtigungen für sarah . Führen Sie den folgenden Befehl aus, um sie zu aktivieren:

 kubectl apply -f /path/to/your/yaml/file

In diesem Fall wurde kubectl apply anstelle von kubectl create . Der Unterschied zwischen den beiden besteht darin, dass create das Objekt erstellt und nichts anderes tut und apply - erstellt nicht nur das Objekt (falls es nicht vorhanden ist), sondern aktualisiert es bei Bedarf auch.

Lassen Sie uns überprüfen, ob unsere Benutzer die erforderlichen Berechtigungen erhalten haben.

  • Benutzer: sarah (in my-project-prod edit )
    • my-project-prod
      • kann Pods (1) auflisten;
      • kann Bereitstellungen erstellen (2).
    • my-project-dev
      • Pods (4) können nicht aufgelistet werden;
      • Bereitstellungen können nicht erstellt werden (5).

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev"

  • Benutzer: jean (in my-project-prod view und in my-project-dev edit )
    • my-project-prod
      • kann Pods (1) auflisten;
      • kann Deployment'ov (2) auflisten;
      • Bereitstellungen können nicht gelöscht werden (3).
    • my-project-dev:
      • kann Pods auflisten (4);
      • kann Bereitstellungen erstellen (5);
      • kann Deployment'ov (6) auflisten;
      • kann Bereitstellungen entfernen (7).

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found.

Benutzerverwaltung und Autorisierung


Daher haben wir erfolgreich verschiedene Rollen und Benutzerberechtigungen festgelegt. Es stellt sich die Frage: Wie geht das jetzt? Woher weiß ich, ob die Berechtigungen für einen bestimmten Benutzer richtig eingestellt sind? Woher weiß ich, wer befugt ist, eine bestimmte Aktion auszuführen? Wie bekomme ich ein allgemeines Bild der Benutzerberechtigungen?

Wir brauchen Antworten auf all diese Fragen, um die Cluster-Sicherheit zu gewährleisten. Mit dem kubectl auth can-i können Sie herausfinden, ob ein Benutzer eine bestimmte Aktion ausführen kann:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean

Mit dem ersten Befehl (1) kann der Benutzer herausfinden, ob er eine Aktion ausführen kann. Die zweite (2) - ermöglicht es dem Administrator, sich als Benutzer auszugeben, um herauszufinden, ob er eine bestimmte Aktion ausführen kann. Diese "Reinkarnation" ist nur für Benutzer mit Cluster-Administratorrechten zulässig.

Dies ist praktisch alles, was mit dem integrierten Toolkit möglich ist. Aus diesem Grund werde ich einige Open Source-Projekte vorstellen, die die Funktionen des kubectl auth can-i-Teams erweitern. Bevor wir sie einführen, legen wir die Abhängigkeiten fest: Go und Krew .

Gehen Sie zur Installation


Go ist eine Open Source-Programmiersprache, mit der Sie einfache, zuverlässige und effiziente Software erstellen können. Es wurde von Google unter der Inspiration von C und Pascal entwickelt, basierend auf den ursprünglichen Konzepten von Robert Griesemer , Rob Pike und Ken Thompson .

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin

Krew Installation


Krew ist ein Tool, das die Verwendung von Kubectl-Plugins vereinfacht. Krew hilft Ihnen beim Suchen, Installieren und Verwalten von Plugins. In Bezug auf Funktionen ähnelt es Werkzeugen wie apt, dnf oder Brew. Krew ist nur mit kubectl Version 1.12 und höher kompatibel.

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

Rakkess


In diesem Projekt können Sie alle Berechtigungen anzeigen, die dem Benutzer erteilt wurden. Zum Beispiel hilft es bei der Beantwortung der Frage, was jean tun kann. Lassen Sie es uns zunächst installieren:

 kubectl krew install access-matrix

Die Projektdokumentation finden Sie im Repository auf GitHub . Hier ist ein Beispiel seiner Arbeit:

 kubectl access-matrix -n my-project-dev --as jean



kubect-who-can


Mit diesem Projekt können wir herausfinden, welche Benutzer eine bestimmte Aktion ausführen können. Es hilft, die Frage zu beantworten: "Wer kann das?" Installation:

 go get -v github.com/aquasecurity/kubectl-who-can

Die Dokumentation befindet sich im GitHub-Repository . Arbeitsbeispiel:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User

rbac-lookup


Dieses Projekt bietet einen Überblick über die RBAC-Regeln. Es hilft bei der Beantwortung der Fragen: „Zu welcher Rolle gehören jean und sarah ?“, „Zu welcher Rolle gehören alle Benutzer?“, „Zu welcher Rolle gehört die gesamte Gruppe?“. Führen Sie zum Installieren den folgenden Befehl aus:

 kubectl krew install rbac-lookup

Die Dokumentation befindet sich im GitHub-Repository . Hier ist ein Beispiel für die Arbeit:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer

RBAC Manager


Wie der Name dieses Projekts offensichtlich folgt, ist er der Manager von RBAC. Es vereinfacht die vielen notwendigen Manipulationen. Das vielleicht wichtigste ist die Erstellung von RoleBindings. Wir haben bereits früher gesehen, dass beim Erstellen verschiedener Rollen für einen Benutzer unterschiedliche Rollenbindungen erstellt werden müssen. Mit RBAC Manager können Sie nur eine Rollenbindung mit allen Berechtigungen gleichzeitig erstellen. Zur Installation müssen Sie die YAML-Datei aus dem Repository auf GitHub herunterladen:

 kubectl apply -f /path/to/rbac/manager/yaml/file

Die offizielle Dokumentation befindet sich im GitHub-Repository . Arbeitsbeispiel:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit

Fazit


Wir haben Benutzer im Kubernetes-Cluster mithilfe des X.509-Clientzertifikats mit OpenSSL erstellt und sie aktiviert. Zur einfacheren Benutzererstellung können Sie das in meinem Repository auf GitHub verfügbare Skript (oder die experimentellen kubeadm-Befehle - ca. Transl.) Verwenden . Für die Clusterverwaltung können Sie die im Artikel vorgestellten Open Source-Projekte verwenden:

  • kubectl auth can-i : Finden Sie heraus, ob der Benutzer eine Aktion ausführen kann.
  • rakkess : Finden Sie alle Aktionen heraus, die der Benutzer ausführen kann.
  • kubectl-who-can : Bestimmen Sie, welche Benutzer eine Aktion ausführen können.
  • rbac-lookup : einen allgemeinen Überblick über RBAC erhalten;
  • RBAC Manager : Vereinfachen Sie die Konfiguration, indem Sie Rechtebindungen kombinieren, Änderungen an RBAC automatisieren und Beschriftungen als Selektoren zum Zuweisen von Rechten verwenden.

Das Erstellen von Benutzern kann zu einer sehr zeitaufwändigen Aufgabe werden, insbesondere wenn Sie eine große Anzahl von Benutzern gleichzeitig festlegen müssen (oder diese häufig erstellen müssen). Um die Situation zu verbessern, kann LDAP für Unternehmen mit dem Kubernetes-Cluster verbunden werden. Einige Open Source-Projekte ( Kismatic [ Object sieht wie aufgegeben aus] und ObjectifLibre ) bieten Kubernetes-Webhooks an, die eine direkte Authentifizierung über LDAP ermöglichen. Eine andere mögliche Lösung besteht darin, einen OpenID-Server mit Unternehmens-LDAP als Backend zu konfigurieren.

PS vom Übersetzer


Lesen Sie auch in unserem Blog:

Source: https://habr.com/ru/post/de470503/

More articles:


All Articles