Rollenbasierte Zugriffskontrolle mit Oracle Cloud Native Environment verwenden

Einführung

Wenn die Anzahl der Deployments in Ihrem Kubernetes-Cluster steigt, benötigen Sie möglicherweise Unterstützung bei der Verwaltung. Mit der Kubernetes-API können Sie Benutzer hinzufügen und ihre Berechtigungen für das Cluster definieren.

Nachdem der Benutzer authentifiziert wurde, prüft Kubernetes, welche Aktionen der Benutzer ausführen darf. Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) wird nativ von Kubernetes unterstützt und standardmäßig in Oracle Cloud Native Environment (Oracle CNE) aktiviert. Sie zu einer der gängigen Zugriffskontrollmethoden zu machen. Mit RBAC können Sie den Zugriff auf Ressourcen verwalten, die in der Kubernetes-Umgebung bereitgestellt werden, indem Sie Regeln anwenden, die den Benutzerzugriff auf Clusterressourcen einschränken. Diese Regeln können mit einer Rolle oder clusterweit mit einer ClusterRole eingeschränkt werden.

Es ist hilfreich, die wichtigsten Komponenten der rollenbasierten Zugriffskontrolle (Role-Based Access Control, RBAC) in Kubernetes zu verstehen:

Rollen: Eine definierte Gruppe von Berechtigungen, die zulässige Aktionen in einem Namespace definieren.
RoleBindings: Wird verwendet, um eine Rolle an einen Benutzer- oder Serviceaccount in einem Namespace zu binden.
ClusterRole: Eine definierte Gruppe von Berechtigungen, die zulässige Aktionen für alle Namespaces im Cluster definieren.
ClusterRoleBindings: Wird verwendet, um eine ClusterRole an einen Benutzer oder Serviceaccounts über alle Namespaces im Cluster hinweg zu binden.
Themen: Dies sind Benutzer, Gruppen oder Serviceaccounts, die an Rollen oder ClusterRoles gebunden sind.
Berechtigungen: Diese definieren die zulässigen Aktionen, die eine Rolle oder ClusterRole für eine angegebene Ressource ausführen kann. Sie sind mit Rollen und Clusterrollen und nicht mit Benutzern oder Serviceaccounts verknüpft.

Eine weitere Möglichkeit, den Zugriff auf das Kubernetes-Cluster zu verwalten, ist die Attribute-Based Access Control (ABAC), die eine feinere Optimierung von Policys im Vergleich zu RBAC ermöglicht. Aber das liegt außerhalb des Rahmens dieses Tutorials.

Dieses Tutorial behandelt die Grundlagen der Verwendung von RBAC zur Verwaltung des Zugriffs auf Ihr Kubernetes-Cluster und zeigt einen einfachen Anwendungsfall.

Weitere Informationen zu Oracle Cloud Native Environment 2 finden Sie auf der aktuellen Releasedokumentations-site.

Ziele

In diesem Tutorial lernen Sie:

Erstellen Sie eine Rolle, um zu demonstrieren, wie Benutzerberechtigungen nach Namespace eingeschränkt werden.
Erstellen Sie eine ClusterRole, um zu demonstrieren, dass Benutzerberechtigungen clusterweit erteilt werden.

Voraussetzungen

Installation von Oracle Cloud Native Environment (Oracle CNE)
Ein einzelner Kontrollknoten und ein Worker-Knoten

Oracle Cloud Native Environment konfigurieren

Hinweis: Wenn Sie in Ihrem eigenen Mandanten ausgeführt werden, lesen Sie das Projekt linux-virt-labs GitHub README.md, und schließen Sie die Voraussetzungen ab, bevor Sie die Übungsumgebung bereitstellen.

Öffnen Sie ein Terminal auf dem Luna Desktop.

Klonen Sie das Projekt linux-virt-labs GitHub.

git clone https://github.com/oracle-devrel/linux-virt-labs.git

Wechseln Sie in das Arbeitsverzeichnis.
```
cd linux-virt-labs/ocne2
```

Installieren Sie die erforderlichen Sammlungen.

ansible-galaxy collection install -r requirements.yml

Bereitstellen der Übungsumgebung.
```
ansible-playbook create_instance.yml -e localhost_python_interpreter="/usr/bin/python3.6" -e install_ocne_rpm=true -e create_ocne_cluster=true -e "ocne_cluster_node_options='-n 1 -w 1'"
```
Die kostenlose Übungsumgebung erfordert die zusätzliche Variable local_python_interpreter, die ansible_python_interpreter für Wiedergaben festlegt, die auf localhost ausgeführt werden. Diese Variable ist erforderlich, da die Umgebung das RPM-Package für das Oracle Cloud Infrastructure-SDK für Python unter den python3.6-Modulen installiert.

Die Standard-Deployment-Ausprägung verwendet AMD-CPU und Oracle Linux 8. Um eine Intel CPU oder Oracle Linux 9 zu verwenden, fügen Sie dem Deployment-Befehl -e instance_shape="VM.Standard3.Flex" oder -e os_version="9" hinzu.

Wichtig: Warten Sie, bis das Playbook erfolgreich ausgeführt wird, und erreichen Sie die Unterbrechungsaufgabe. In dieser Phase des Playbooks ist die Installation von Oracle CNE abgeschlossen, und die Instanzen sind bereit. Notieren Sie sich die vorherige Wiedergabe, in der die öffentlichen und privaten IP-Adressen der bereitgestellten Knoten und alle anderen Deployment-Informationen gedruckt werden, die während der Ausführung der Übung erforderlich sind.

Auf Kubernetes-Cluster zugreifen

Öffnen Sie ein Terminal, und stellen Sie eine SSH-Verbindung zur ocne-Instanz her.
```
ssh oracle@<ip_address_of_instance>
```
Warten Sie, bis sich das Cluster stabilisiert und alle Pods in einem aktiven Status gemeldet werden.
```
watch kubectl get pods -A
```
Wenn alle Pods den STATUS Wird ausgeführt aufweisen, geben Sie Ctrl-C ein, um den Befehl watch zu beenden.
Prüfen Sie, wie viele Knoten vorhanden sind.
```
kubectl get nodes
```

Aktuelle RBAC-Konfiguration bestätigen

RBAC verwaltet die Berechtigungen für die Aktionen, die Sie für Ressourcen ausführen, die in Ihrem Kubernetes-Cluster bereitgestellt sind. Prüfen Sie, ob RBAC aktiviert ist, und prüfen Sie die Standardrollen in Ihrem Cluster.

Bestätigen Sie, dass RBAC aktiviert ist.

Wenn die rbac.authorization.k8s.io-API sichtbar ist, bedeutet dies, dass RBAC konfiguriert ist und verwendet wird, um zu steuern, welche Aktionen Benutzer oder Serviceaccounts für Clusterressourcen ausführen können.
```
kubectl api-versions | grep rbac
```
Beispielausgabe:
```
[oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1
```

Integrierte Clusterrollen anzeigen.

kubectl get clusterroles | grep admin

Beispielausgabe:

[oracle@ocne ~]$ kubectl get clusterroles | grep admin
admin                                                                  2025-07-23T10:21:55Z
cluster-admin                                                          2025-07-23T10:21:55Z
system:aggregate-to-admin                                              2025-07-23T10:21:55Z
system:kubelet-api-admin                                               2025-07-23T10:21:55Z

Normale Benutzer verwenden die Rollen admin und cluster-admin, während die RBAC-API die Rollen system: für interne Komponenten reserviert.

Listen Sie die Berechtigungen für cluster-admin auf.
```
kubectl describe clusterrole cluster-admin
```
Beispielausgabe:
```
[oracle@ocne ~]$ kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]
```
Die Sternchen in den Spalten Verben und Ressourcen bedeuten, dass die Rolle cluster-admin jede Aktion ausführen kann. Eine allgemeine Liste der Vorgänge (Verben), die für jedes Kubernetes-Release verfügbar sind, ist im API-Überblick für dieses Release verfügbar. Beispiel: In Kubernetes v1.33.0. Eine detaillierte Liste der gültigen Vorgänge (Verben), die für jeden Ressourcentyp verfügbar sind, finden Sie, indem Sie kubectl api-resources -o wide über die Befehlszeile ausführen.

Da Sie sich jedoch nicht bei kubectl anmelden, woher weiß Kubernetes, wer der Benutzer ist, der den Befehl ausführt? Produktionssysteme verwenden üblicherweise einen LDAP-Server zur Authentifizierung. Eine ServiceAccount kann verwendet werden, wenn kein externes Authentifizierungssystem verfügbar ist.

Hinweis: ServiceAccounts wird von automatisierten Workloads wie CI/CD-Pipelines verwendet, kann aber auch zum Testen verwendet werden.

Rolle erstellen

Eine Rolle ist eine Ressource mit eingeschränktem Namespace, die Berechtigungen für den Zugriff auf Kubernetes-Ressourcen in einem einzelnen Namespace definiert.

Namespace und Rolle erstellen

Einen Namespace erstellen.

Erstellen Sie einen neuen Namespace für dieses Beispiel.
```
kubectl create namespace rbac-example
```
Erstellen einer Rolle.

Erstellen Sie eine Rolle, die schreibgeschützten Zugriff ("get"- und "list"-Berechtigungen) auf pods und deployments im Namespace rbac-example erteilt.
```
cat << EOF | tee pod-reader-role.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: rbac-example
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
EOF
```
Dabei gilt:
- rules:: Definiert die Berechtigungen, die der Rolle erteilt werden. In diesem Beispiel werden zwei Regeln definiert (siehe unten).
- apiGroups: [""]: Ermöglicht dem an diese Regel gebundenen Benutzer- oder Serviceaccount das Abrufen und Auflisten von Pods im rbac-example-Namespace.
- apiGroups: ["apps"]: Ermöglicht dem an diese Regel gebundenen Benutzer- oder Serviceaccount, Deployments im Namespace rbac-example abzurufen und aufzulisten.
Übernehmen Sie die Datei.
```
kubectl apply -f pod-reader-role.yaml
```

Prüfen Sie die Berechtigungen für die neu erstellte pod-reader-Rolle.

kubectl describe role/pod-reader -n rbac-example

Beispielausgabe:

[oracle@ocne ~]$ kubectl describe role/pod-reader -n rbac-example
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
 pods              []                 []              [get list]
 deployments.apps  []                 []              [get list]

Benutzer erstellen und an Rolle binden

Erstellen Sie einen neuen ServiceAccount-Benutzer namens pod-reader-user, und binden Sie ihn an die Rolle pod-reader.
```
cat << EOF | tee pod-reader-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac-example
roleRef:
  name: pod-reader
  kind: Role
subjects:
- kind: ServiceAccount
  name: pod-reader-user
  namespace: rbac-example
EOF
```
Dabei gilt:
- Die ServiceAccount erstellt den Serviceaccount.
  - name:: Der Name des Serviceaccountbenutzers (pod-reader-user).
  - namespace: Der Namespace, in dem er erstellt wird (rbac-example).
- Die RoleBinding erteilt dem Serviceaccount die Namespace-bezogenen Berechtigungen.
  - roleRef:: Gibt die Binding-Rolle an. In diesem Beispiel referenziert es eine Rolle mit dem Namen pod-reader.
  - subjects:: Gibt die Entity an, der Berechtigungen erteilt werden sollen. In diesem Beispiel ein Serviceaccount mit dem Namen pod-reader-user.
Übernehmen Sie die Datei.
```
kubectl apply -f pod-reader-user.yaml
```

Testen Sie RoleBinding

Testen Sie als Nächstes die RoleBinding, indem Sie einen neuen Pod erstellen und mit dem neu erstellten pod-reader-user-Serviceaccount darauf zugreifen.

Neues Test-Deployment erstellen.
```
cat << EOF | tee testpod.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: rbac-example
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 80
  serviceAccountName: pod-reader-user
EOF
```
Dabei gilt:
- Die spec: definiert den gewünschten Status des Pods.
  - containers:: Gibt die Liste der Container an, die im Pod ausgeführt werden sollen. In diesem Beispiel gibt es nur einen Container.
    - name:: Der Name des Containers (test-container).
    - image:: Das zu verwendende Image (ghcr.io/oracle/oraclelinux9-nginx:1.20).
    - ports:: Gibt den Port an, der vom Container angegeben wird. In diesem Beispiel ist es Port 80 (containerPort: 80).
  - serviceAccountName:: Gibt den Serviceaccount an, der für den Pod verwendet werden soll. In dieser Konfiguration verwendet der Pod die Berechtigungen und Zugangsdaten, die dem Serviceaccount pod-reader-user zugewiesen sind.
Übernehmen Sie die Datei.
```
kubectl apply -f testpod.yaml
```
Versuchen Sie jetzt, mit dem pod-reader-user ServiceAccount auf den Pod zuzugreifen.
```
kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
```
Als Ausgabe sollte yes angezeigt werden. Dies gibt an, dass der pod-reader-user über die Berechtigung zum Zugriff auf den Pod verfügt.

Hinweis: Verwenden Sie die kubectl auth can-i-Funktionalität, um Befehle als neu erstelltes ServiceAccount-Benutzerkonto auszuführen und zu prüfen, ob eine Aktion zulässig ist.

Stellen Sie sicher, dass ServiceAccount wie erwartet funktioniert.

kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example

Beispielausgabe:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          109s

Versuchen Sie, einen Pod mit der Rolle pod-reader-user zu löschen.

kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example

Beispielausgabe:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example
Error from server (Forbidden): pods "test-pod" is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot delete resource "pods" in API group "" in the namespace "rbac-example"

Die Rolle pod-reader-user kann keine Pods in der Rolle rbac-example löschen. Vielleicht können sie neue Pods starten?

Versuchen Sie, einen Pod mit der Rolle pod-reader-role auszuführen.

kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:default:my-serviceaccount -n rbac-example

Beispielausgabe:

[oracle@ocne ~]$ kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot create resource "pods" in API group "" in the namespace "rbac-example"

Dieser Fehler ist korrekt, da die Rolle pod-reader-user nur die Aktionen get und list für Podressourcen im Namespace rbac-example des Clusters ausführen darf. Andere Aktionen, delete oder create, sind nicht zulässig.

Erstellen Sie eine ClusterRole.

ClusterRoles ähnelt Rollen, definiert jedoch zulässige Berechtigungen für Ressourcen im gesamten Cluster.

Hinweis: Seien Sie vorsichtig, wenn Sie zu breite Berechtigungen erteilen. Verwenden Sie stattdessen das Least-Privilege-Prinzip, um Benutzern und Serviceaccounts nur die Berechtigungen zu erteilen, die zum Abschließen der ihnen zugewiesenen Aufgaben erforderlich sind.

Erstellen Sie eine ClusterRole und eine ClusterRoleBinding.

Im vorherigen Beispiel wurde gezeigt, wie Sie einen Namespace-spezifischen Benutzer und eine spezifische Rolle erstellen. Die folgenden Schritte zeigen, wie Sie eine ClusterRole erstellen und an einen Benutzer binden, um ihm clusterweiten Admin-Zugriff zu erteilen.

Erstellen Sie eine neue ClusterRole.

Mit dieser ClusterRole können hinzugefügte Benutzer Aktionen für alle Ressourcen im gesamten Cluster ausführen.
```
cat << EOF | tee cluster-admin-clusterrole.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-cr
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF
```
Dabei gilt:
- rules:: Definiert die Berechtigungen, die dem ClusterRole erteilt werden. Dieses Beispiel enthält nur eine Regel:
  - apiGroups: ["*"]: Gibt an, dass die Regel für alle API-Gruppen gilt.
  - resources: ["*"]: Gibt an, dass die Regel für alle Ressourcen der API-Gruppen gilt.
  - verbs: ["*"]: Gibt an, dass die Regel alle möglichen Verben für die Ressourcen zuweist, einschließlich get, list, create, delete usw.

Übernehmen Sie die Datei.

kubectl apply -f cluster-admin-clusterrole.yaml

Erstellen Sie eine ClusterRoleBinding, um die ClusterRole an einen neuen Benutzer zu binden.

Die ClusterRoleBinding ähnelt der zuvor erstellten RoleBinding, ist jedoch clusterbezogen.

cat << EOF | tee cluster-admin-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-admin-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-crb
roleRef:
  name: cluster-admin-cr
  kind: ClusterRole
subjects:
- kind: ServiceAccount
  name: cluster-admin-user
  namespace: rbac-example
EOF

Dabei gilt:

subjects:: Definiert die Entitys, die Berechtigungen in ClusterRole erteilen sollen. In diesem Beispiel ist es der Serviceaccount cluster-admin-user.

Übernehmen Sie die Datei.

kubectl apply -f cluster-admin-user.yaml

Testen Sie ClusterRoleBinding

Testen Sie die Clusterrolle, indem Sie versuchen, auf eine Ressource in einem anderen Namespace zuzugreifen. Beispiel: Der Standard-Namespace.
```
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default
```
Als Ausgabe sollte yes angezeigt werden. Dies gibt an, dass cluster-admin-user über cluster-admin-Zugriff verfügt.

Bestätigen Sie, dass die neu erstellte ClusterRole wie erwartet funktioniert.

kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

Beispielausgabe:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
kube-flannel   kube-flannel-ds-ptwkz                          1/1     Running   0          6h58m
kube-flannel   kube-flannel-ds-wn2g6                          1/1     Running   0          6h58m
kube-system    coredns-7cbdbfd99c-7xqkl                       1/1     Running   0          6h59m
kube-system    coredns-7cbdbfd99c-k2ssb                       1/1     Running   0          6h59m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          6h59m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          6h59m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          6h59m
kube-system    kube-proxy-48rm5                               1/1     Running   0          6h59m
kube-system    kube-proxy-h4kd2                               1/1     Running   0          6h58m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          6h59m
ocne-system    ocne-catalog-577b7cd5f9-bnvtm                  1/1     Running   0          6h58m
ocne-system    ui-846bddd4b-lnrwm                             1/1     Running   0          6h58m
rbac-example   test-pod                                       1/1     Running   0          6h34m

Diese Ausgabe bestätigt, dass die neu erstellte ClusterRole auf alle Namespaces zugreifen kann, die im Cluster definiert sind.

Bestätigen, dass der Benutzer ClusterRole ein neues Deployment erstellen kann

Testen Sie ClusterRole, um festzustellen, ob zugewiesene Benutzer ein neues Deployment erstellen können. Versuchen Sie dann, mit dem neu erstellten ClusterRole darauf zuzugreifen.

Neues Test-Deployment erstellen.

cat << EOF | tee testpod2.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
  namespace: default
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 8080
EOF

Beachten Sie, dass dieses Deployment im Namespace 'default' und nicht im zuvor verwendeten rbac-example-Namespace bereitgestellt wird.

Übernehmen Sie die Datei.
```
kubectl apply -f testpod2.yaml
```

Bestätigen Sie, dass das Deployment erfolgreich abgeschlossen wurde.

kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

Beispielausgabe:

[oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
default        test-pod2                                      1/1     Running   0          28s
kube-flannel   kube-flannel-ds-shgh7                          1/1     Running   0          38m
kube-flannel   kube-flannel-ds-zzrgh                          1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-jg6lz                       1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-wh5g4                       1/1     Running   0          38m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          38m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          38m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          38m
kube-system    kube-proxy-5qngx                               1/1     Running   0          38m
kube-system    kube-proxy-6fz2q                               1/1     Running   0          38m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          38m
ocne-system    ocne-catalog-577b7cd5f9-vz782                  1/1     Running   0          38m
ocne-system    ui-846bddd4b-bbhtj                             1/1     Running   0          38m
rbac-example   test-pod                                       1/1     Running   0          21m

Es wird bestätigt, dass die neue ClusterRole neue Deployments in einem anderen Namespace zulässt.

Nächste Schritte

In diesem Tutorial wurde gezeigt, wie Sie die Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) mit Kubernetes einrichten und verwenden, indem Sie Rollen erstellen, um den Zugriff auf Kubernetes-Ressourcen zu verwalten. Sie haben dies erreicht, indem Sie Rollen und Bindings definieren, um zu steuern, welche zulässigen Aktionen für Ressourcen in einem Namespace oder clusterweit zulässig waren. Auf diese Weise ist die granulare Steuerung, die RBAC bereitstellt, unerlässlich, um Ihre Kubernetes-Umgebung zu sichern, insbesondere für große Deployments. Weitere Tutorials und Inhalte finden Sie in der Oracle Linux-Schulungsstation.

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Use Role-Based Access Control with Oracle Cloud Native Environment

G40834-01

Oracle und/oder verbundene Unternehmen.

Rollenbasierte Zugriffskontrolle mit Oracle Cloud Native Environment verwenden

Einführung

Ziele

Voraussetzungen

Oracle Cloud Native Environment konfigurieren

Auf Kubernetes-Cluster zugreifen

Aktuelle RBAC-Konfiguration bestätigen

Rolle erstellen

Namespace und Rolle erstellen

Benutzer erstellen und an Rolle binden

Testen Sie RoleBinding

Erstellen Sie eine ClusterRole.

Erstellen Sie eine ClusterRole und eine ClusterRoleBinding.

Testen Sie ClusterRoleBinding

Bestätigen, dass der Benutzer ClusterRole ein neues Deployment erstellen kann

Nächste Schritte

Verwandte Links

Weitere Lernressourcen