Welche Arten von RBAC-Rollen gibt es?

• Der Geltungsbereich einer Kubernetes-Rolle ist auf Ressourcen in einem bestimmten Namensbereich (z. B. in einer Bereitstellung oder einem Service) begrenzt.
• Der Geltungsbereich einer Kubernetes-Clusterrolle ist auf alle Ressourcen in einem Cluster (z. B. Workerknoten) begrenzt oder auf Ressourcen, die in jedem Namensbereich vorkommen (z. B. Pods).

Was sind RBAC-Rollenbindungen und Cluster-Rollenbindungen?

Von Rollenbindungen werden RBAC-Rollen oder Clusterrollen auf einen bestimmten Namensbereich angewendet. Wenn Sie eine Rollenbindung zum Anwenden auf eine Rolle verwenden, erteilen Sie einem Benutzer Zugriff auf eine bestimmte Ressource in einem bestimmten Namensbereich. Wenn Sie eine Rollenbindung zum Anwenden auf eine Clusterrolle verwenden, erteilen Sie einem Benutzer Zugriff auf Ressourcen in einem Namensbereich, die in jedem Namensbereich vorhanden sind (wie zum Beispiel Pods), aber nur in einem bestimmten Namensbereich.

Von Clusterrollenbindungen werden RBAC-Clusterrollen auf alle Namensbereiche im Cluster angewendet. Wenn Sie eine Clusterrollenbindung verwenden, um eine Clusterrolle anzuwenden, erteilen Sie einem Benutzer Zugriff auf clusterweite Ressourcen wie Workerknoten oder auf namensbereichsorientierte Ressourcen in jedem Namensbereich, wie zum Beispiel Pods.

Wie sehen diese Rollen in meinem Cluster aus?

Wenn Benutzer innerhalb eines Clusters mit Kubernetes-Ressourcen interagieren können sollen, müssen Sie den Benutzerzugriff auf einen oder mehrere Namensbereiche durch IBM Cloud IAM-Servicezugriffsrollen zuordnen. Jedem Benutzer, dem eine Servicezugriffsrolle zugeordnet ist, wird automatisch eine entsprechende RBAC-Clusterrolle zugeordnet. Diese RBAC-Clusterrollen sind vordefiniert und ermöglichen es Benutzern, mit Kubernetes-Ressourcen im Cluster zu interagieren. Darüber hinaus wird entweder eine Rollenbindung erstellt, um die Clusterrolle auf einen bestimmten Namensbereich anzuwenden, oder eine Clusterrollenbindung wird erstellt, um die Clusterrolle auf alle Namensbereiche anzuwenden.

Weitere Informationen zu den für die einzelnen RBAC-Rollen zulässigen Aktionen finden Sie im Referenzthema IBM Cloud: IAM-Servicezugriffsrollen. Informationen zu den Berechtigungen, die durch die einzelnen RBAC-Rollen für einzelne Kubernetes-Ressourcen erteilt werden, finden Sie im Abschnitt zu den Kubernetes-Ressourcenberechtigungen für RBAC-Rollen.

Kann ich benutzerdefinierte Rollen oder Cluster-Rollen erstellen?

Wenn Sie eigene angepasste RBAC-Richtlinien erstellen, stellen Sie sicher, dass Sie die vorhandenen IBM-Rollenbindungen im Cluster nicht bearbeiten oder angepasste Rollenbindungen mit demselben Namen wie die vorhandenen IBM-Bindungen erstellen. Änderungen, die Sie an den von IBMbereitgestellten RBAC-Rollenbindungen vornehmen, werden bei Aktualisierungen nicht beibehalten.

Die Clusterrollen view (Anzeigen), edit (Bearbeiten), admin (Administrator) und cluster-admin (Clusteradministrator) sind vordefinierte Rollen, die automatisch erstellt werden, wenn Sie einem Benutzer die entsprechende IBM Cloud IAM-Servicezugriffsrolle zuordnen. Wenn Sie andere Kubernetes-Berechtigungen erteilen möchten, können Sie angepasste RBAC-Berechtigungen erstellen. Benutzerdefinierte RBAC-Rollen gelten zusätzlich zu den RBAC-Rollen, die Sie möglicherweise im Rahmen von Servicezugriffsrollen haben, und ändern oder überschreiben diese nicht. Hinweis: Um benutzerdefinierte RBAC-Berechtigungen zu erstellen, benötigen Sie die Zugriffsrolle IAM Manager oder die Plattformrolle Administrator, die Ihnen die RBAC-Rolle Kubernetescluster-admin gewährt. Die anderen Benutzer benötigen jedoch keine IAM-Servicezugriffsrolle, wenn Sie eigene angepasste Kubernetes-RBAC-Rollen verwalten.

Wann muss ich angepasste Clusterrollenbindungen und Rollenbindungen verwenden?

Es kann sinnvoll sein, Personen Berechtigungen zuzuordnen, die Pods im Cluster erstellen und aktualisieren. Mit Pod-Sicherheitsrichtlinien (PSPs) können Sie vorhandene Cluster-Rollenbindungen nutzen, die zu Ihrem Cluster gehören, oder eigene erstellen.

Es kann auch sinnvoll sein, Add-ons in den Cluster zu integrieren. Beispielsweise, wenn Sie Helm in Ihrem Cluster einrichten.

Angepasste RBAC-Berechtigungen für Benutzer, Gruppen oder Servicekonten erstellen

Die Clusterrollen view (Anzeigen), edit (Bearbeiten), admin (Administrator) und cluster-admin (Clusteradministrator) werden automatisch erstellt, wenn Sie die entsprechende IBM Cloud IAM-Servicezugriffsrolle zuordnen. Müssen die Clusterzugriffsrichtlinien differenzierter sein, als dies anhand der vordefinierten Berechtigungen möglich ist? Kein Problem! Sie können angepasste RBAC-Rollen und Clusterrollen erstellen.

Sie können angepasste RBAC-Rollen und Clusterrollen einzelnen Benutzern, Benutzergruppen oder Servicekonten zuordnen. Wenn für eine Gruppe eine Bindung erstellt wird, wirkt sich dies auf alle Benutzer aus, die dieser Gruppe hinzugefügt oder die aus dieser Gruppe entfernt werden. Wenn Sie Benutzer zu einer Gruppe hinzufügen, erhalten diese zusätzlich zu den individuellen Zugriffsberechtigungen, die Sie ihnen gewähren, die Zugriffsberechtigungen der Gruppe. Werden sie entfernt, wird ihr Zugriff widerrufen. Beachten Sie, dass Sie keine Dienstkonten zu Zugriffsgruppen hinzufügen können.

Wenn Sie einem Containerprozess, der in Pods ausgeführt wird – beispielsweise einer Continuous-Delivery-Toolchain –, Zugriffsrechte zuweisen möchten, können Sie … verwenden Kubernetes ServiceAccounts. Eine Anleitung zur Einrichtung von Dienstkonten für Travis und Jenkins sowie zur Zuweisung benutzerdefinierter RBAC-Rollen an diese Dienstkonten finden Sie im Blogbeitrag Kubernetes ServiceAccounts zur Verwendung in automatisierten Systemen.

Um Änderungen zu vermeiden, die Unterbrechungen verursachen können, lassen Sie die vordefinierten Clusterrollen view, edit, admin und cluster-admin unverändert. Benutzerdefinierte RBAC-Rollen gelten zusätzlich zu den RBAC-Rollen, die Sie möglicherweise über die IAM-Zugriffsrollen von IBM Cloud haben, und ändern oder überschreiben diese nicht.

• Namensbereichszugriff: Wenn Sie einem Benutzer, einer Zugriffsgruppe oder einem Servicekonto Zugriff auf eine Ressource in einem bestimmten Namensbereich gewähren möchten, wählen Sie eine der folgenden Kombinationen aus:

  • Erstellen Sie eine Rolle und wenden Sie sie mit einer Rollenbindung an. Diese Option ist nützlich, um den Zugriff auf eine eindeutige Ressource zu steuern, die nur in einem Namensbereich vorhanden ist, wie zum Beispiel eine App-Implementierung.
  • Erstellen Sie eine Clusterrolle und wenden Sie sie mit einer Rollenbindung an. Diese Option ist nützlich, um den Zugriff auf allgemeine Ressourcen in einem Namensbereich zu steuern, zum Beispiel auf Pods.

• Clusterweiter Zugriff: Um einem Benutzer oder einer Zugriffsgruppe den Zugriff auf clusterweite Ressourcen oder Ressourcen in allen Namensbereichen zu ermöglichen, erstellen Sie eine Clusterrolle und wenden sie mit einer Clusterrollenbindung an. Diese Option ist nützlich, um den Zugriff auf Ressourcen zu steuern, die sich nicht auf Namensbereiche (zum Beispiel Workerknoten) oder Ressourcen in allen Namensbereichen im Cluster (zum Beispiel Pods in jedem Namensbereich) beziehen.

• Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

• Stellen Sie sicher, dass Sie über die IAM-Service-Zugangsrolle Manager für alle Namensräume oder die Plattformrolle Administrator verfügen.

• Um einzelnen Benutzern oder Benutzern in einer Zugriffsgruppe Zugriffsrechte zuzuweisen, stellen Sie sicher, dass dem Benutzer oder der Gruppe mindestens eine IAM-Plattform-Zugriffsrolle auf der Ebene des IBM Cloud Kubernetes Service-Dienstes zugewiesen wurde.

Zum Erstellen von benutzerdefinierten RBAC-Berechtigungen,

1. Erstellen Sie eine Datei .yaml ähnlich der folgenden, um role oder cluster role zu definieren.

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       namespace: default
       name: my_role
   rules:
   - apiGroups: [""]
       resources: ["pods"]
       verbs: ["get", "watch", "list"]
   - apiGroups: ["apps", "extensions"]
       resources: ["daemonsets", "deployments"]
       verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   

   Verstehen der YAML-Parameter

   Parameter	Beschreibung
   kind	Verwenden Sie Role, um Zugriff auf die Ressourcen in einem bestimmten Namensbereich zu erteilen. Verwenden Sie ClusterRole, um Zugriff auf clusterweite Ressourcen (zum Beispiel Workerknoten) oder namensbereichsorientierte Ressourcen (zum Beispiel Pods in allen Namensbereichen) zu erteilen.
   metadata.namespace	Nur für Role: Geben Sie den Kubernetes-Namensbereich an, für den der Zugriff erteilt wird.
   rules.apiGroups	Geben Sie die Kubernetes-API-Gruppen an, mit denen Benutzer interagieren können sollen, z. B. "apps", "batch", oder "extensions". Für den Zugriff auf die Gruppe der API-Kerndefinitionen im REST-Pfad api/v1 lassen Sie die Angabe für die Gruppe leer [""].
   rules.resources	Geben Sie die Kubernetes-Ressourcentypen an, für die Sie Zugriff gewähren möchten, z. B. "daemonsets", "deployments", "events", oder "ingresses". Falls Sie "nodes" angeben, muss als Typ ClusterRole angegeben werden.
   rules.verbs	Geben Sie die Arten von Aktionen an, die Benutzer ausführen können sollen, z. B. "get", "list", "describe", "create", oder "delete".

2. Erstellen Sie die Rolle oder Clusterrolle in Ihrem Cluster.

   kubectl apply -f my_role.yaml
   

3. Überprüfen Sie, ob die Rolle bzw. Clusterrolle erstellt wurde.

   • Rolle:

       kubectl get roles -n <namespace>
       ```
   * Clusterrolle:
   ```sh {: pre}
       kubectl get clusterroles
       ```
   

4. Binden Sie Benutzer an die Rolle oder Clusterrolle, indem Sie eine Datei .yaml erstellen. Notieren Sie die eindeutige URL, die für die einzelnen Namen des jeweiligen Subjekts verwendet werden soll

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
       name: my_role_binding
       namespace: default
   subjects:
   - kind: User
       name: IAM#user1@example.com
       apiGroup: rbac.authorization.k8s.io
   - kind: Group
       name: team1
       apiGroup: rbac.authorization.k8s.io
   - kind: ServiceAccount
       name: <service_account_name>
       namespace: <kubernetes_namespace>
   roleRef:
       kind: Role
       name: my_role
       apiGroup: rbac.authorization.k8s.io
   

   Verstehen der YAML-Parameter

   Parameter	Beschreibung
   kind	Geben Sie RoleBinding für einen namensbereichsspezifische Role oder ClusterRole an. Geben Sie ClusterRoleBinding für eine clusterweite ClusterRole an.
   apiVersion	Verwenden Sie rbac.authorization.k8s.io/v1.
   metadata.namespace	Für den Typ RoleBinding: Geben Sie den Kubernetes-Namensbereich an, auf den der Zugriff gewährt wird. Für den Typ ClusterRoleBinding: Verwenden Sie nicht das Feld namespace.
   metadata.name	Benennen Sie die Rollenbindung bzw. Clusterrollenbindung.
   subjects.kind	Geben Sie den Typ wie folgt an: User: RBAC-Rolle oder Clusterrolle an einen einzelnen Benutzer in Ihrem Konto binden. Group: RBAC-Rolle oder Clusterrolle an eine IBM Cloud IAM-Zugriffsgruppe in Ihrem Konto binden. ServiceAccount: RBAC-Rolle oder Clusterrolle an ein Servicekonto in einem Namensbereich in Ihrem Cluster binden.
   subjects.name	User: Fügen Sie die E-Mail-Adresse des einzelnen Benutzers wie folgt an IAM# an: IAM#user@email.com. Group: Geben Sie den Namen der IAM-Zugangsgruppe IBM Cloud in Ihrem Konto an. Für ServiceAccount: Geben Sie den Namen des Servicekontos an.
   subjects.apiGroup	User oder Group: Verwenden Sie rbac.authorization.k8s.io. Für ServiceAccount: Fügen Sie dieses Feld nicht ein.
   subjects.namespace	ServiceAccount nur: Geben Sie den Namen des Kubernetes-Namespace an, in dem das Dienstkonto bereitgestellt wird.
   roleRef.kind	Geben Sie denselben Wert als kind in der .yaml-Rollendatei an: Role oder ClusterRole.
   roleRef.name	Geben Sie den Namen der .yaml-Rollendatei an.
   roleRef.apiGroup	Verwenden Sie rbac.authorization.k8s.io.

5. Erstellen Sie die Ressource für die Rollenbindung bzw. Clusterrollenbindung in Ihrem Cluster.

   kubectl apply -f my_role_binding.yaml
   

6. Überprüfen Sie, dass die Bindung erstellt wurde.

   kubectl get rolebinding -n <namespace>
   

7. Optional: Wenn Sie dieselbe Stufe des Benutzerzugriffs in anderen Namensbereichen erzwingen möchten, ist das Kopieren der Rollenbindungen für diese Rollen oder Clusterrollen in andere Namensbereiche möglich.

   1. Kopieren Sie die Rollenbindung von einem Namensbereich in einen anderen Namensbereich.

       kubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -
       ```
       Beispielsweise kopieren Sie die `custom-role` Rollenbindung vom  `default`-Namespace zum `testns`-Namespace.
       ```sh {: pre}
       kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
       ```
   2. Überprüfen Sie, dass die Bindung kopiert wurde. Wenn Sie eine IBM Cloud IAM-Zugriffsgruppe zu der Rollenbindung hinzugefügt haben, wird jeder Benutzer in dieser Gruppe einzeln hinzugefügt, nicht als Zugriffsgruppen-ID.
   ```sh {: pre}
       kubectl get rolebinding -n <namespace_2>
       ```
   

Fahren Sie jetzt, nachdem Sie eine angepasste Kubernetes-RBAC-Rolle oder -Clusterrolle erstellt und gebunden haben, mit den Benutzern fort. Bitten Sie sie, eine Aktion auszuführen, für deren Ausführung sie die Berechtigung aufgrund Ihrer Rolle haben. Zum Beispiel das Löschen eines Pods.

Vorhandene Berechtigungen durch Aggregieren von Clusterrollen erweitern

Sie können die vorhandenen Berechtigungen Ihrer Benutzer erweitern, indem Sie Clusterrollen mit anderen Clusterrollen aggregieren oder kombinieren. Wenn Sie einem Benutzer eine IBM Cloud-Servicezugriffsrolle zuweisen, wird der Benutzer einer entsprechenden Kubernetes-RBAC-Clusterrolle hinzugefügt. Möglicherweise möchten Sie jedoch bestimmten Benutzern erlauben, weitere Vorgänge auszuführen.

Beispiel: Ein Benutzer mit der Clusterrolle admin für den Namensbereich kann den Befehl kubectl top pods nicht zum Anzeigen von Pod-Metriken für alle Pods im Namensbereich verwenden. Sie können eine Clusterrolle aggregieren, sodass Benutzer in der Clusterrolle admin berechtigt sind, den Befehl top pods auszuführen. Weitere Informationen finden Sie in der Dokumentation zu Kubernetes.

Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "IAM#myname@example.com" can't list resource "pods" in API group "metrics.k8s.io" in the namespace "mynamespace"

RBAC-Rollen überprüfen

Überprüfen Sie Ihren angepassten RBAC- oder synchronisierten IAM-Servicezugriff auf RBAC-Rollen in Ihrem IBM Cloud Kubernetes Service-Cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: 2018-05-23T14:34:24Z
  name: ibm-view
  namespace: default
  resourceVersion: "8192510"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/ibm-view
  uid: 63f62887-5e96-11e8-8a75-b229c11ba64a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: IAM#user@email.com
- apiGroup: rbac.authorization.k8s.io
  kind: group
  name: team1

Kubernetes-Servicezugriffsrollen und entsprechende RBAC-Rollen

In der folgenden Tabelle sind die Kubernetes-Ressourcenberechtigungen aufgeführt, die durch die einzelnen Servicezugriffsrollen und die entsprechenden RBAC-Rollen erteilt werden.