Autorizzare le azioni nei cluster utilizzando controllo dell'accesso basato sui ruoli

Questa pagina mostra come autorizzare le azioni sulle risorse nei tuoi cluster Google Kubernetes Engine (GKE) utilizzando il meccanismo di controllo dell'accesso basato sui ruoli (RBAC) integrato in Kubernetes. RBAC di Kubernetes è abilitato per impostazione predefinita, offrendoti un controllo granulare sull'accesso al cluster.

Imparerai a definire e assegnare autorizzazioni precise, creare ruoli e associazioni di ruoli per gestire l'accesso degli utenti, verificare l'accesso API per controllare il livello di accesso, risolvere i problemi comuni e comprendere le limitazioni quando utilizzi RBAC in GKE.

Questa pagina è rivolta a specialisti della sicurezza e operatori che vogliono utilizzare RBAC per migliorare la sicurezza nei cluster GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE Enterprise.

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

• Panoramica di Kubernetes RBAC
• Best practice per RBAC in GKE per linee guida per migliorare la progettazione delle tue norme RBAC.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Interazione con Identity and Access Management

Puoi utilizzare sia Identity and Access Management (IAM) che Kubernetes RBAC per controllare l'accesso al tuo cluster GKE:

• IAM non è specifico di Kubernetes; fornisce la gestione delle identità per più prodotti e opera principalmente a livello di progetto. Google Cloud Google Cloud

• Kubernetes RBAC è un componente principale di Kubernetes e consente di creare e concedere ruoli (set di autorizzazioni) per qualsiasi oggetto o tipo di oggetto all'interno del cluster.

• Per autorizzare un'azione, GKE controlla prima un criterio RBAC. Se non esiste una policy RBAC, GKE controlla le autorizzazioni IAM.

In GKE, IAM e Kubernetes RBAC sono integrati per autorizzare gli utenti a eseguire azioni se dispongono di autorizzazioni sufficienti in base a uno dei due strumenti. Si tratta di una parte importante del bootstrapping di un cluster GKE, poiché per impostazione predefinita gli utenti non dispongono di alcun RoleBinding RBAC di Kubernetes. Google Cloud

Per autorizzare gli utenti che utilizzano account Google Cloud , il client deve essere configurato correttamente per l'autenticazione utilizzando prima questi account. Ad esempio, se utilizzi kubectl, devi configurare il comando kubectl per l'autenticazione a Google Cloud prima di eseguire qualsiasi comando che richieda l'autorizzazione.

In quasi tutti i casi, è possibile utilizzare Kubernetes RBAC anziché IAM. Gli utenti GKE richiedono almeno l'autorizzazione IAM container.clusters.get nel progetto che contiene il cluster. Questa autorizzazione è inclusa nel ruolo container.clusterViewer e in altri ruoli con privilegi più elevati. L'autorizzazione container.clusters.get è necessaria per consentire agli utenti di autenticarsi nei cluster del progetto, ma non li autorizza a eseguire azioni all'interno di questi cluster. L'autorizzazione può quindi essere fornita da IAM o Kubernetes RBAC.

Definisci e assegna le autorizzazioni

Puoi definire le regole RBAC negli oggetti ClusterRole e Role e poi assegnarle con gli oggetti ClusterRoleBinding e RoleBinding nel seguente modo:

• ClusterRole: un raggruppamento a livello di cluster di risorse e operazioni consentite che puoi assegnare a un utente o a un gruppo utilizzando un RoleBinding o un ClusterRoleBinding.
• Ruolo: un raggruppamento con spazio dei nomi di risorse e operazioni consentite che puoi assegnare a un utente o a un gruppo di utenti utilizzando un RoleBinding.
• ClusterRoleBinding: assegna un ClusterRole a un utente o a un gruppo per tutti gli spazi dei nomi nel cluster.
• RoleBinding: assegna un Role o un ClusterRole a un utente o a un gruppo all'interno di uno spazio dei nomi specifico.

Quando utilizzi un RoleBinding per assegnare un ClusterRole a un utente o a un gruppo, questi utenti e gruppi possono accedere solo alle risorse nello spazio dei nomi specificato nel RoleBinding. Se vuoi che gli utenti o i gruppi accedano alla risorsa in tutti gli spazi dei nomi, utilizza un ClusterRoleBinding.

Definisci le autorizzazioni utilizzando Roles o ClusterRoles

Definisci le autorizzazioni all'interno di un oggetto Role o ClusterRole. Un ruolo definisce l'accesso alle risorse all'interno di un singolo spazio dei nomi, mentre un ClusterRole definisce l'accesso alle risorse nell'intero cluster.

Role e ClusterRole hanno la stessa sintassi. Ognuna ha una sezione rules, in cui definisci le risorse a cui si applica la regola e le operazioni consentite per il ruolo. Ad esempio, il seguente ruolo concede l'accesso in lettura (get, watch e list) a tutti i pod nello spazio dei nomi accounting:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Consulta la documentazione dell'API relativa a Role e ClusterRole per un elenco completo dei campi consentiti.

Role rispetto a ClusterRole

Poiché le autorizzazioni concesse da un ClusterRole si applicano all'intero cluster, puoi utilizzare i ClusterRole per controllare l'accesso a diversi tipi di risorse rispetto a quanto puoi fare con i ruoli. Questi includono:

• Risorse con ambito cluster come i nodi
• Endpoint REST non di risorse come /healthz
• Risorse con spazio dei nomi in tutti gli spazi dei nomi (ad esempio, tutti i pod nell'intero cluster, indipendentemente dallo spazio dei nomi)

Assegnare ruoli utilizzando RoleBinding o ClusterRoleBinding

Dopo aver creato un ruolo o un ClusterRole, lo assegni a un utente o a un gruppo di utenti creando un RoleBinding o un ClusterRoleBinding. Gli utenti e i gruppi sono chiamati subjects e possono essere uno dei seguenti:

Il seguente RoleBinding concede il ruolo pod-reader a un utente, a un account di servizio Kubernetes, a un account di servizio IAM e a un gruppo Google:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verifica l'accesso API utilizzando kubectl

kubectl fornisce il sottocomando auth can-i per interrogare rapidamente il livello di autorizzazione API. In qualità di amministratore della piattaforma, potresti dover impersonare gli utenti per determinare quali azioni possono eseguire. Puoi utilizzare auth can-i e passare un flag --as aggiuntivo.

Quando esegui il comando kubectl auth can-i senza il flag --as, l'autorizzazione viene eseguita da Identity and Access Management (IAM). Quando aggiungi il flag --as, Kubernetes RBAC esegue l'autorizzazione. Pertanto, dovrai creare gli oggetti Role e RoleBinding necessari per il controllo dell'accesso basato sui ruoli.

Per maggiori informazioni, consulta Verificare l'accesso API.

Utilizzo e esempi di API

Per informazioni complete sull'utilizzo dell'API Kubernetes per creare gli oggetti Role, ClusterRole, RoleBinding e ClusterRoleBinding necessari per RBAC, consulta Utilizzo dell'autorizzazione del controllo dell'accesso basato sui ruoli nella documentazione di Kubernetes.

Risolvere i problemi relativi a RBAC

Per eseguire il debug dei problemi relativi al controllo degli accessi basato su ruoli (RBAC), utilizza il log di controllo dell'attività di amministrazione, che è abilitato per impostazione predefinita su tutti i cluster. Se l'accesso a una risorsa o a un'operazione viene negato a causa della mancanza di autorizzazioni sufficienti, il server API registra un errore RBAC DENY, insieme a informazioni aggiuntive come l'appartenenza implicita ed esplicita dell'utente al gruppo. Se utilizzi Google Gruppi per RBAC, nel messaggio di log viene visualizzato google groups.

Limitazioni

Le sezioni seguenti descrivono interazioni che potrebbero non sembrare ovvie quando utilizzi RBAC e IAM di Kubernetes.

Ruoli di discovery predefiniti

I cluster vengono creati con un insieme di ClusterRole e ClusterRoleBinding predefiniti. Le richieste effettuate con credenziali valide vengono inserite nel gruppo system:authenticated, mentre tutte le altre rientrano in system:unauthenticated.

Il ClusterRole system:basic-user consente agli utenti di eseguire SelfSubjectAccessReviews per testare le proprie autorizzazioni nel cluster. Il ruolo system:discovery consente agli utenti di leggere le API di rilevamento, che possono rivelare informazioni su CustomResourceDefinitions aggiunti al cluster.

Gli utenti anonimi (system:unauthenticated) ricevono invece il ClusterRole system:public-info-viewer, che concede l'accesso di sola lettura alle API /healthz e /version.

Per visualizzare gli endpoint API consentiti da ClusterRole system:discovery, esegui il seguente comando:

kubectl get clusterroles system:discovery -o yaml

Errore di accesso negato per i service account sulle istanze VM Google Cloud

Può verificarsi il seguente errore quando l'istanza VM non ha l'ambito userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Ad esempio, supponiamo che la VM abbia l'ambito cloud-platform, ma non l'ambito userinfo-email. Quando la VM riceve un token di accesso, Google Cloud associa il token all'ambito cloud-platform. Quando il server dell'API Kubernetes chiede Google Cloud l'identità associata al token di accesso, riceve l'ID univoco del account di servizio, non la sua email.

Per eseguire l'autenticazione correttamente, crea una nuova VM con l'ambito userinfo-email o crea un nuovo binding del ruolo che utilizza l'ID univoco.

Per creare una nuova istanza VM con l'ambito userinfo-email, esegui questo comando:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Per creare un nuovo binding del ruolo che utilizza l'ID univoco dell'account di servizio per una VM esistente, segui questi passaggi:

1. Identifica l'ID univoco del account di servizio:

   gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL
   

   Ad esempio, l'output seguente mostra uniqueId per il account di servizio my-iam-account@somedomain.com:

   displayName: Some Domain IAM service account
   email: my-iam-account@somedomain.com
   etag: BwWWja0YfJA
   name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
   oauth2ClientId: '123456789012345678901'
   projectId: project-name
   uniqueId: '123456789012345678901'
   

2. Crea un'associazione di ruoli utilizzando uniqueId del account di servizio:

   kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
       --clusterrole cluster-admin \
       --user UNIQUE_ID
   

Autorizzazione per creare o aggiornare ruoli e associazioni di ruoli

In Kubernetes, puoi creare o aggiornare un ruolo o un'associazione di ruoli con autorizzazioni specifiche solo se soddisfi le seguenti condizioni:

• Crea o aggiorna un ruolo: devi già disporre delle stesse autorizzazioni che vuoi concedere al ruolo. In alternativa, devi disporre dell'autorizzazione per eseguire il verbo escalate sul ruolo.
• Crea o aggiorna un'associazione di ruoli: devi disporre già delle stesse autorizzazioni concesse nel ruolo da associare, con lo stesso ambito dell'associazione di ruoli. In alternativa, devi disporre dell'autorizzazione per eseguire il verbo bind sul ruolo a cui viene fatto riferimento.

Se le autorizzazioni che stai concedendo nel ruolo ti sono state originariamente concesse utilizzando un criterio IAM di tipo Consenti anziché il controllo dell'accesso basato sui ruoli, la tua richiesta di ruolo o associazione di ruolo potrebbe non riuscire. Ad esempio, considera la seguente richiesta di creazione di un ruolo da parte di un utente a cui sono state concesse le autorizzazioni IAM container.pods.* e container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Se all'utente sono state concesse solo le autorizzazioni utilizzando IAM, potrebbe verificarsi il seguente errore:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Per ovviare a questa limitazione, concedi al chiamante le autorizzazioni nel ruolo utilizzando RBAC anziché IAM.

In alternativa, puoi utilizzare RBAC o IAM per concedere al chiamante il verbo escalate, il verbo bind o entrambi. Tuttavia, GKE non consiglia questo approccio, perché il chiamante può quindi concedere qualsiasi autorizzazione a qualsiasi ruolo.

Passaggi successivi

• Scopri come creare policy IAM.
• Scopri come configurare Google Gruppi per RBAC.