Utilizza il controllo dell'accesso basato sui ruoli con Oracle Cloud Native Environment

Introduzione

All'aumentare del numero di distribuzioni nel cluster Kubernetes, potrebbe essere necessaria assistenza per la gestione. L'API Kubernetes consente di aggiungere utenti e definire le autorizzazioni per il cluster.

Dopo l'autenticazione dell'utente, Kubernetes verifica le azioni che l'utente è autorizzato a eseguire. Role-Based Access Control (RBAC) è supportato in modo nativo da Kubernetes e abilitato per impostazione predefinita in Oracle Cloud Native Environment (Oracle CNE). Che lo rende uno dei metodi di controllo dell'accesso comunemente utilizzati. RBAC consente di gestire l'accesso alle risorse distribuite nell'ambiente Kubernetes applicando regole che limitano l'accesso degli utenti alle risorse cluster. Queste regole possono essere limitate allo spazio di nomi utilizzando un ruolo o a livello di cluster utilizzando un ClusterRole.

Troverai utile avere una comprensione dei componenti chiave del controllo dell'accesso basato sui ruoli (RBAC) in Kubernetes, che sono:

Ruoli: set definito di autorizzazioni che definiscono le azioni consentite all'interno di uno spazio di nomi.
RoleBindings: utilizzato per associare un ruolo a un account utente o servizio all'interno di uno spazio di nomi.
ClusterRole: set definito di autorizzazioni che definiscono le azioni consentite in tutti gli spazi di nomi nel cluster.
ClusterRoleBindings: utilizzato per associare un ClusterRole a un account utente o servizio in tutti gli spazi di nomi del cluster.
Oggetti: si tratta di utenti, gruppi o account di servizio associati a Ruoli o ClusterRoles.
Autorizzazioni: queste definiscono le azioni consentite che un ruolo o ClusterRole può eseguire su una risorsa specificata. Sono associati a ruoli e ruoli cluster anziché a utenti o account di servizio.

Un altro modo per gestire l'accesso al cluster Kubernetes è ABAC (Attribute-Based Access Control), che consente di ottimizzare i criteri rispetto a RBAC. Ma questo è al di fuori dell'ambito di questo tutorial.

Questa esercitazione descrive le nozioni di base sull'uso di RBAC per gestire l'accesso al cluster Kubernetes e illustra un semplice caso d'uso.

Per ulteriori informazioni su Oracle Cloud Native Environment 2, fai riferimento al sito corrente della documentazione di rilascio.

Obiettivi

In questo tutorial imparerai a:

Creare un ruolo per dimostrare la limitazione delle autorizzazioni utente in base allo spazio di nomi.
Creare un file ClusterRole per dimostrare la concessione delle autorizzazioni utente a livello di cluster.

Prerequisiti

Installazione di Oracle Cloud Native Environment (Oracle CNE)
Un singolo nodo di controllo e un nodo di lavoro

Configura Oracle Cloud Native Environment

Nota: se è in esecuzione nella propria tenancy, leggere il progetto linux-virt-labs GitHub README.md e completare i prerequisiti prima di distribuire l'ambiente di laboratorio.

Aprire un terminale sul Luna Desktop.

Duplicare il progetto linux-virt-labs GitHub.

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

Passare alla directory di lavoro.
```
cd linux-virt-labs/ocne2
```

Installare le raccolte richieste.

ansible-galaxy collection install -r requirements.yml

Implementare l'ambiente di laboratorio.
```
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'"
```
L'ambiente di esercitazione pratica gratuito richiede l'aggiunta della variabile local_python_interpreter, che imposta ansible_python_interpreter per le riproduzioni eseguite su localhost. Questa variabile è necessaria perché l'ambiente installa il pacchetto RPM per l'SDK Oracle Cloud Infrastructure per Python, situato sotto i moduli python3.6.

La forma di distribuzione predefinita utilizza la CPU AMD e Oracle Linux 8. Per utilizzare una CPU Intel o Oracle Linux 9, aggiungere -e instance_shape="VM.Standard3.Flex" o -e os_version="9" al comando di distribuzione.

Importante: attendere che il playbook venga eseguito correttamente e raggiungere il task di sospensione. In questa fase del playbook, l'installazione di Oracle CNE è completa e le istanze sono pronte. Prendi nota del gioco precedente, che stampa gli indirizzi IP pubblici e privati dei nodi che distribuisce e qualsiasi altra informazione di distribuzione necessaria durante l'esecuzione del laboratorio.

Accedi al cluster Kubernetes

Aprire un terminale e connettersi tramite SSH all'istanza ocne.
```
ssh oracle@<ip_address_of_instance>
```
Attendere che il cluster venga stabilizzato e che tutti i pod vengano segnalati in stato di esecuzione.
```
watch kubectl get pods -A
```
Dopo che tutti i pod mostrano uno STATUS di In esecuzione, digitare Ctrl-C per uscire dal comando watch.
Confermare il numero di nodi presenti.
```
kubectl get nodes
```

Conferma configurazione RBAC corrente

RBAC gestisce le autorizzazioni per le azioni eseguite sulle risorse distribuite nel cluster Kubernetes. Si verificherà che RBAC sia abilitato ed esaminerà i ruoli predefiniti nel cluster.

Conferma RBAC abilitata.

Se l'API rbac.authorization.k8s.io è visibile, significa che RBAC è configurato e viene utilizzato per controllare le azioni che gli utenti o gli account di servizio possono eseguire sulle risorse del cluster.
```
kubectl api-versions | grep rbac
```
Output di esempio:
```
[oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1
```

Mostra i ruoli cluster built-in.

kubectl get clusterroles | grep admin

Output di esempio:

[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

Gli utenti normali utilizzano i ruoli admin e cluster-admin, mentre l'API RBAC riserva i ruoli system: per i componenti interni.

Elencare le autorizzazioni per cluster-admin.
```
kubectl describe clusterrole cluster-admin
```
Output di esempio:
```
[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
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]
```
Gli asterischi nelle colonne Verbi e Risorse consentono al ruolo cluster-admin di eseguire qualsiasi azione. Un elenco di alto livello delle operazioni (Verbi) disponibili per ogni release di Kubernetes è disponibile nella panoramica API per tale release. Ad esempio, in Kubernetes v1.33.0. Un elenco dettagliato delle operazioni valide (Verbi) disponibili per ogni tipo di Risorsa è disponibile eseguendo kubectl api-resources -o wide dalla riga di comando.

Tuttavia, poiché non si esegue il login a kubectl, in che modo Kubernetes sa chi è l'utente che esegue il comando? I sistemi di produzione in genere utilizzano un server LDAP per l'autenticazione. È possibile utilizzare un valore ServiceAccount se non è disponibile un sistema di autenticazione esterno.

Nota: ServiceAccounts vengono utilizzati da carichi di lavoro automatizzati, come le pipeline CI/CD, ma possono essere utilizzati anche per i test.

Crea un ruolo

Un ruolo è una risorsa con spazio di nomi limitato che definisce le autorizzazioni per accedere alle risorse Kubernetes all'interno di un singolo spazio di nomi.

Creare uno spazio di nomi e un ruolo

Crea uno spazio di nomi.

Creare un nuovo spazio di nomi per questo esempio.
```
kubectl create namespace rbac-example
```
Creare un ruolo.

Creare un ruolo che conceda l'accesso in sola lettura (autorizzazioni get e 'list') ai pod e alle distribuzioni all'interno dello spazio di nomi rbac-example.
```
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
```
dove:
- rules:: definisce le autorizzazioni concesse al ruolo. Questo esempio definisce due regole (vedere di seguito).
- apiGroups: [""]: consente all'account utente o servizio associato a questa regola di recuperare ed elencare i pod nello spazio di nomi rbac-example.
- apiGroups: ["apps"]: consente all'account utente o servizio associato a questa regola di recuperare ed elencare le distribuzioni nello spazio di nomi rbac-example.
Applicare il file.
```
kubectl apply -f pod-reader-role.yaml
```

Controllare le autorizzazioni per il ruolo pod-reader appena creato.

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

Output di esempio:

[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]

Crea un utente e associa al ruolo

Creare un nuovo utente ServiceAccount denominato pod-reader-user e associarlo al ruolo 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
```
dove:
- L'account di servizio viene creato in ServiceAccount.
  - name:: il nome dell'utente dell'account di servizio (pod-reader-user).
  - namespace: lo spazio di nomi in cui viene creato (rbac-example).
- RoleBinding concede all'account di servizio le autorizzazioni relative allo spazio di nomi.
  - roleRef:: specifica il ruolo di associazione. In questo esempio fa riferimento a un ruolo denominato pod-reader.
  - subjects:: specifica l'entità a cui concedere le autorizzazioni. In questo esempio, un account di servizio denominato pod-reader-user.
Applicare il file.
```
kubectl apply -f pod-reader-user.yaml
```

Prova il RoleBinding

Successivamente, eseguire il test di RoleBinding creando un nuovo pod e accedendovi utilizzando il nuovo account di servizio pod-reader-user creato.

Creare una nuova distribuzione di test.
```
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
```
dove:
- spec: definisce lo stato desiderato del pod.
  - containers:: specifica la lista dei contenitori da eseguire nel pod. In questo esempio c'è un solo contenitore.
    - name:: il nome del contenitore (test-container).
    - image:: l'immagine da utilizzare (ghcr.io/oracle/oraclelinux9-nginx:1.20).
    - ports:: specifica la porta esposta dal contenitore. In questo esempio, si tratta della porta 80 (containerPort: 80).
  - serviceAccountName:: specifica l'account di servizio da utilizzare per il pod. In questa configurazione, il pod utilizza le autorizzazioni e le credenziali assegnate all'account del servizio pod-reader-user.
Applicare il file.
```
kubectl apply -f testpod.yaml
```
Ora prova ad accedere al pod utilizzando pod-reader-user ServiceAccount.
```
kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
```
L'output dovrebbe essere yes, a indicare che pod-reader-user dispone dell'autorizzazione per accedere al pod.

Nota: utilizzare la funzionalità kubectl auth can-i per eseguire i comandi come account utente ServiceAccount appena creato per verificare che un'azione sia consentita.

Verificare che ServiceAccount funzioni come previsto.

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

Output di esempio:

[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

Provare a eliminare un pod utilizzando il ruolo pod-reader-user.

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

Output di esempio:

[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"

Il ruolo pod-reader-user non può eliminare i pod in rbac-example. Forse possono avviare nuovi pod?

Provare a eseguire un pod utilizzando il ruolo pod-reader-role.

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

Output di esempio:

[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"

Questo errore è corretto perché al ruolo pod-reader-user è consentito eseguire solo azioni get e list sulle risorse pod nello spazio di nomi rbac-example del cluster. Qualsiasi altra azione, elimina o crea, non è consentita.

Creare un ClusterRole

ClusterRoles sono simili ai ruoli, ma definiscono le autorizzazioni consentite sulle risorse nell'intero cluster.

Nota: prestare attenzione quando si concedono autorizzazioni troppo ampie. In alternativa, utilizzare il principio di privilegio minimo minimo per concedere agli utenti e agli account di servizio solo le autorizzazioni necessarie per completare i task assegnati.

Creare un ClusterRole e ClusterRoleBinding

L'esempio precedente mostra come creare un utente e un ruolo specifici dello spazio di nomi. I passi seguenti illustrano come creare un ClusterRole e associarlo a un utente per concedere loro l'accesso di amministratore a livello di cluster.

Creare un nuovo ClusterRole.

Questo ClusterRole consente agli utenti aggiunti di eseguire qualsiasi azione su tutte le risorse del cluster.
```
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
```
dove:
- rules:: definisce le autorizzazioni concesse a ClusterRole. In questo esempio è presente una sola regola:
  - apiGroups: ["*"]: specifica che la regola si applica a tutti i gruppi API.
  - resources: ["*"]: specifica che la regola si applica a tutte le risorse dei gruppi API.
  - verbs: ["*"]: specifica che la regola concede tutti i verbi possibili sulle risorse, inclusi get, list, create, delete e così via.

Applicare il file.

kubectl apply -f cluster-admin-clusterrole.yaml

Creare un ClusterRoleBinding per associare il file ClusterRole a un nuovo utente.

Il file ClusterRoleBinding è simile al file RoleBinding creato in precedenza, ma è con ambito cluster.

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

dove:

subjects:: definisce le entità per concedere le autorizzazioni in ClusterRole. In questo esempio si tratta dell'account di servizio cluster-admin-user.

Applicare il file.

kubectl apply -f cluster-admin-user.yaml

Prova il ClusterRoleBinding

Eseguire il test del ruolo cluster tentando di accedere a una risorsa in uno spazio di nomi diverso. Ad esempio, lo spazio di nomi predefinito.
```
kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default
```
Si consiglia di visualizzare yes come output, indicando che cluster-admin-user dispone dell'accesso cluster-admin.

Verificare che ClusterRole appena creato funzioni come previsto.

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

Output di esempio:

[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

Questo output conferma che il nuovo file ClusterRole creato può accedere a tutti gli spazi di nomi definiti nel cluster.

Confermare che l'utente ClusterRole può creare una nuova distribuzione

Eseguire il test di ClusterRole per verificare se consente agli utenti assegnati di creare una nuova distribuzione. Quindi, provare ad accedervi utilizzando il nuovo ClusterRole creato.

Creare una nuova distribuzione di test.

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

Tenere presente che questa distribuzione viene distribuita nello spazio di nomi 'default' e non nello spazio di nomi rbac-example usato in precedenza.

Applicare il file.
```
kubectl apply -f testpod2.yaml
```

Conferma della distribuzione completata.

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

Output di esempio:

[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

Confermare che il nuovo ClusterRole consente nuove distribuzioni in uno spazio di nomi diverso.

Passi successivi

Questa esercitazione ha dimostrato come impostare e utilizzare il controllo dell'accesso basato sui ruoli (RBAC) con Kubernetes creando ruoli per gestire l'accesso alle risorse Kubernetes. È possibile ottenere questo risultato definendo ruoli e associazioni per controllare quali azioni consentite sono state consentite sulle risorse all'interno di uno spazio di nomi o a livello di cluster. In questo modo, il controllo granulare fornito da RBAC è essenziale per proteggere l'ambiente Kubernetes, in particolare per le distribuzioni di grandi dimensioni. Controlla la stazione di formazione Oracle Linux per ulteriori esercitazioni e contenuti.

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Oracle Learning Explorer.

Per la documentazione del prodotto, visitare Oracle Help Center.

Titolo e informazioni sul copyright

Use Role-Based Access Control with Oracle Cloud Native Environment

G40842-01

Oracle e/o relative consociate.

Utilizza il controllo dell'accesso basato sui ruoli con Oracle Cloud Native Environment

Introduzione

Obiettivi

Prerequisiti

Configura Oracle Cloud Native Environment

Accedi al cluster Kubernetes

Conferma configurazione RBAC corrente

Crea un ruolo

Creare uno spazio di nomi e un ruolo

Crea un utente e associa al ruolo

Prova il RoleBinding

Creare un ClusterRole

Creare un ClusterRole e ClusterRoleBinding

Prova il ClusterRoleBinding

Confermare che l'utente ClusterRole può creare una nuova distribuzione

Passi successivi

Collegamenti correlati

Altre risorse di apprendimento