Quali sono i tipi di ruoli RBAC?

• Un ruolo Kubernetes è destinato alle risorse all'interno di uno spazio dei nomi specifico, come una distribuzione o un servizio.
• Un ruolo di cluster di un cluster " Kubernetes " ha come ambito le risorse a livello di cluster, come i nodi di lavoro, oppure le risorse a livello di namespace presenti in ciascun namespace, come i pod.

Cosa sono i binding dei ruoli RBAC e i binding dei ruoli di cluster?

I bind del ruolo applicano i ruoli RBAC o i ruoli cluster a uno specifico spazio dei nomi. Quando utilizzi un bind del ruolo per applicare un ruolo, fornisci a un utente l'accesso a una risorsa specifica in uno specifico spazio dei nomi. Quando utilizzi un bind del ruolo per applicare un ruolo cluster, fornisci a un utente l'accesso alle risorse con ambito delimitato agli spazi dei nomi che possono essere trovate in ognuno di questi spazi, come i pod, ma solo all'interno di uno spazio dei nomi specifico.

I bind del ruolo cluster applicano i ruoli cluster RBAC a tutti gli spazi dei nomi nel cluster. Quando utilizzi un bind del ruolo cluster per applicare un ruolo cluster, fornisci a un utente l'accesso alle risorse a livello di cluster, come i nodi di lavoro, o alle risorse con ambito delimitato agli spazi dei nomi in ogni spazio dei nomi, come i pod.

Come si presentano questi ruoli nel mio cluster?

Se si desidera che gli utenti possano interagire con le risorse di Kubernetes dall'interno di un cluster, è necessario assegnare loro l'accesso a uno o più spazi dei nomi tramite i ruoli di accesso del servizio IAM di IBM Cloud. A ogni utente a cui viene assegnato un ruolo di accesso al servizio viene automaticamente assegnato un ruolo RBAC di cluster corrispondente. Questi ruoli cluster RBAC sono predefiniti e consentono agli utenti di interagire con le risorse Kubernetes nel tuo cluster. Inoltre, viene creato un bind del ruolo per applicare il ruolo cluster a uno specifico spazio dei nomi o un bind del ruolo cluster per applicare il ruolo cluster a tutti gli spazi dei nomi.

Per ulteriori informazioni sulle azioni consentite da ciascun ruolo RBAC, consulta l'argomento di riferimento " IBM Cloud " relativo ai ruoli di accesso al servizio IAM. Per visualizzare le autorizzazioni concesse da ciascun ruolo RBAC a singole risorse Kubernetes, consulta Autorizzazioni delle risorse Kubernetes per ogni ruolo RBAC.

Posso creare ruoli personalizzati o ruoli di cluster?

Se stai creando le tue proprie politiche RBAC personalizzate, assicurati di non modificare i bind del ruolo IBM esistenti che si trovano nel cluster o di creare bind del ruolo personalizzati con lo stesso nome dei bind IBM esistenti. Le modifiche apportate ai bind del ruolo RBAC forniti da IBMnon vengono conservate negli aggiornamenti.

I ruoli di cluster “ view ”, “ edit ”, “ admin ” e “ cluster-admin ” sono ruoli predefiniti che vengono creati automaticamente quando si assegna a un utente il corrispondente ruolo di accesso al servizio IAM “ IBM Cloud ”. Per concedere altre autorizzazioni Kubernetes, puoi creare autorizzazioni RBAC personalizzate. I ruoli RBAC personalizzati si aggiungono a quelli esistenti e non modificano né sostituiscono alcun ruolo RBAC che potresti avere con i ruoli di accesso ai servizi. Nota: per creare autorizzazioni RBAC personalizzate, è necessario disporre del ruolo di accesso al servizio IAM Manager o del ruolo di amministratore della piattaforma, che conferisce il ruolo RBAC " cluster-admin " ( Kubernetes ). Tuttavia, gli altri utenti non hanno bisogno di un ruolo di accesso al servizio IAM se gestisci autonomamente i tuoi ruoli RBAC personalizzati Kubernetes.

Quando è necessario utilizzare i bind del ruolo cluster personalizzati e i bind del ruolo?

Potresti voler autorizzare chi può creare e aggiornare i pod nel tuo cluster. Con le politiche di sicurezza dei pod (PSP), è possibile utilizzare i collegamenti ai ruoli del cluster già presenti nel proprio cluster oppure crearne di propri.

Potresti anche voler integrare componenti aggiuntivi al tuo cluster. Ad esempio, quando si configura Helm nel cluster.

Creazione di autorizzazioni RBAC personalizzate per utenti, gruppi o account di servizio

I ruoli di cluster “ view ”, “ edit ”, “ admin ” e “ cluster-admin ” vengono creati automaticamente quando si assegna il corrispondente ruolo di accesso al servizio IAM “ IBM Cloud ”. Ha bisogno che le tue politiche di accesso al cluster siano più dettagliate di quelle permesse dalle autorizzazioni predefinite? Nessun problema! Puoi creare ruoli cluster e ruoli RBAC personalizzati.

Puoi assegnare ruoli del cluster e ruoli RBAC personalizzati a singoli utenti, gruppi di utenti o account del servizio. Quando viene creato, un bind per un gruppo influenza qualsiasi utente aggiunto a, o rimosso da, tale gruppo. Quando aggiungi utenti a un gruppo, questi ottengono i diritti di accesso del gruppo oltre a eventuali singoli diritti di accesso che concedi loro. Se viene rimosso, il suo accesso viene revocato. Si noti che non è possibile aggiungere account di servizio ai gruppi di accesso.

Se si desidera assegnare i diritti di accesso a un processo containerizzato in esecuzione all’interno di pod, come ad esempio una catena di strumenti di distribuzione continua, è possibile utilizzare Kubernetes ServiceAccounts. Per seguire un tutorial che illustra come configurare gli account di servizio per Travis e Jenkins e come assegnare ruoli RBAC personalizzati a tali account, consulta il post sul blog Kubernetes ServiceAccounts per l'utilizzo in sistemi automatizzati.

Per evitare modifiche che comportino incompatibilità, non modificare i ruoli di cluster predefiniti view, edit, admin e cluster-admin. I ruoli RBAC personalizzati si aggiungono a quelli esistenti e non modificano né sovrascrivono eventuali ruoli RBAC associati ai ruoli di accesso al servizio IAM di IBM Cloud.

• Accesso allo spazio dei nomi: per consentire a un utente, gruppo di accesso o account di servizio di accedere a una risorsa all'interno di uno specifico spazio dei nomi, scegli una delle seguenti combinazioni:

  • Crea un ruolo e applicalo con un bind del ruolo. Questa opzione è utile per controllare l'accesso a un'unica risorsa presente solo in uno spazio dei nomi, come una distribuzione dell'applicazione.
  • Crea un ruolo cluster e applicalo con un bind del ruolo. Questa opzione è utile per controllare l'accesso a risorse generali in uno spazio dei nomi, come i pod.

• Accesso a livello di cluster: per consentire a un utente o a un gruppo di accesso di accedere a risorse a livello di cluster o a risorse in tutti gli spazi dei nomi, crea un ruolo cluster e applicalo con un bind del ruolo cluster. Questa opzione è utile per controllare l'accesso alle risorse che non rientrano nell'ambito degli spazi dei nomi, come i nodi di lavoro, o alle risorse in tutti gli spazi dei nomi nel tuo cluster, come i pod in ogni spazio dei nomi.

• Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

• Assicurarsi di avere il ruolo di accesso al servizio IAM Manager per tutti i namespace o il ruolo di piattaforma Amministratore.

• Per assegnare l'accesso a singoli utenti o a gruppi di utenti, assicurarsi che all'utente o al gruppo sia stato assegnato almeno un ruolo di accesso alla piattaforma IAM a livello del servizio " IBM Cloud Kubernetes Service ".

Per creare autorizzazioni RBAC personalizzate,

1. Creare un file .yaml simile al seguente per definire role o cluster role.

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

   Comprendere i parametri YAML

   Parametro	Descrizione
   kind	Utilizza Role per concedere l'accesso alle risorse all'interno di uno specifico spazio dei nomi. Utilizza ClusterRole per concedere l'accesso alle risorse a livello di cluster, come i nodi di lavoro, o alle risorse con ambito delimitato agli spazi dei nomi, come i pod, in tutti gli spazi dei nomi.
   metadata.namespace	Solo per il tipo Role: specifica lo spazio dei nomi Kubernetes a cui è concesso l'accesso.
   rules.apiGroups	Specificare i gruppi API di Kubernetes con cui si desidera che gli utenti possano interagire, ad esempio "apps", "batch" o "extensions". Per l'accesso al gruppo API principale nel percorso REST api/v1, lascia il gruppo vuoto: [""].
   rules.resources	Specificare i tipi di risorse di Kubernetes a cui si desidera concedere l'accesso, ad esempio "daemonsets", "deployments", "events" o "ingresses". Se specifichi "nodes", il tipo deve essere ClusterRole.
   rules.verbs	Specificare i tipi di azioni che si desidera gli utenti possano eseguire, ad esempio "get", "list", "describe", "create" o "delete".

2. Crea il ruolo o il ruolo cluster nel tuo cluster.

   kubectl apply -f my_role.yaml
   

3. Verifica che il ruolo o il ruolo cluster sia stato creato.

   • Ruolo:

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

4. Collegare gli utenti al ruolo o al ruolo cluster creando un file .yaml. Nota l'URL univoco da utilizzare per il nome di ogni soggetto.

   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
   

   Comprendere i parametri YAML

   Parametro	Descrizione
   kind	Specificare RoleBinding per un Role o ClusterRole specifico per un namespace. Specifica ClusterRoleBinding per un ClusterRole a livello di cluster.
   apiVersion	Utilizzare rbac.authorization.k8s.io/v1.
   metadata.namespace	Per il tipo RoleBinding: specificare lo spazio dei nomi Kubernetes a cui viene concesso l'accesso. Per il tipo ClusterRoleBinding: non utilizzare il campo namespace.
   metadata.name	Fornisci un nome per il bind del ruolo o il bind del ruolo cluster.
   subjects.kind	Specifica il tipo come uno dei seguenti: User: Esegui il bind del ruolo RBAC o del ruolo cluster a un singolo utente nel tuo account. Group: esegui il bind del ruolo RBAC o del ruolo cluster a un IBM Cloud gruppo di accessi IAM nel tuo account. ServiceAccount: esegui il bind del ruolo RBAC o del ruolo cluster a un account del servizio in uno spazio dei nomi nel tuo cluster.
   subjects.name	User: Aggiungere l'indirizzo e-mail del singolo utente a IAM# come segue: IAM#user@email.com. Group: Specificare il nome del gruppo di accesso IAM IBM Cloud nel proprio account. Per ServiceAccount: specifica il nome dell'account di servizio.
   subjects.apiGroup	User o Group: Utilizzare rbac.authorization.k8s.io. Per ServiceAccount: non includere questo campo.
   subjects.namespace	ServiceAccount solo: specificare il nome dello spazio dei nomi Kubernetes in cui è distribuito l'account di servizio.
   roleRef.kind	Immetti lo stesso valore del kind nel file .yaml del ruolo: Role o ClusterRole.
   roleRef.name	Immetti il nome del file .yaml del ruolo.
   roleRef.apiGroup	Utilizzare rbac.authorization.k8s.io.

5. Crea la risorsa di bind del ruolo o bind del ruolo cluster nel tuo cluster.

   kubectl apply -f my_role_binding.yaml
   

6. Verifica che il bind sia stata creato.

   kubectl get rolebinding -n <namespace>
   

7. Facoltativo: per applicare lo stesso livello di accesso utente in altri spazi dei nomi, puoi copiare i bind del ruolo per quei ruoli o ruoli cluster negli altri spazi dei nomi.

   1. Copia il bind del ruolo da uno spazio dei nomi a un altro spazio dei nomi.

       kubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -
       ```
       Ad esempio, copiare il binding del ruolo " `custom-role` " dallo spazio dei nomi " `default` " allo spazio dei nomi " `testns` ".
       ```sh {: pre}
       kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
       ```
   2. Verifica che il bind del ruolo sia stato copiato. Se hai aggiunto un gruppo di accesso IBM Cloud IAM al bind del ruolo, ogni utente in quel gruppo viene aggiunto singolarmente, non come un ID di gruppo di accesso.
   ```sh {: pre}
       kubectl get rolebinding -n <namespace_2>
       ```
   

Ora che hai creato e associato un ruolo RBAC o un ruolo cluster Kubernetes personalizzato, occupati degli utenti. Chiedi loro di testare un'azione per la quale dispongono dell'autorizzazione grazie al ruolo, come l'eliminazione di un pod.

Estensione delle autorizzazioni esistenti aggregando i ruoli del cluster

Puoi estendere le autorizzazioni esistenti dei tuoi utenti aggregando o combinando i ruoli cluster con altri ruoli cluster. Quando si assegna a un utente un ruolo di accesso al servizio IBM Cloud, l'utente viene aggiunto al corrispondente ruolo RBAC del cluster Kubernetes. Tuttavia, potresti voler consentire ad alcuni utenti di eseguire un maggior numero di operazioni.

Ad esempio, un utente con il ruolo di cluster “ admin ” a livello di namespace non può utilizzare il comando “ kubectl top pods ” per visualizzare le metriche relative a tutti i pod presenti nel namespace. Puoi aggregare un ruolo cluster in modo che gli utenti nel ruolo cluster admin siano autorizzati a eseguire il comando top pods. Per ulteriori informazioni, consultare la documentazione di 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"

Controllo dei ruoli RBAC

Verificare l'accesso del servizio RBAC personalizzato o IAM sincronizzato ai ruoli RBAC nel cluster IBM Cloud Kubernetes Service.

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

Ruoli di accesso del servizio Kubernetes e ruoli RBAC corrispondenti

La tabella seguente illustra le autorizzazioni relative alla risorsa " Kubernetes " concesse da ciascun ruolo di accesso al servizio e dal corrispondente ruolo RBAC.