Autorizza azioni nei cluster utilizzando il controllo dell'accesso basato sui ruoli

Questa pagina mostra come autorizzare le azioni sulle risorse in Cluster Google Kubernetes Engine (GKE) che utilizzano il controllo dell'accesso integrato basato sui ruoli meccanismo RBAC in Kubernetes.

RBAC è una funzionalità di sicurezza di base di Kubernetes che ti consente di creare autorizzazioni granulari per gestire le azioni che utenti e carichi di lavoro possono eseguire sulle risorse dei tuoi cluster. In qualità di amministratore di piattaforma, puoi creare ruoli RBAC e associare quei ruoli agli soggetti, ovvero gli utenti autenticati, come o Gruppi. Kubernetes RBAC è abilitato per impostazione predefinita.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente 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 per Kubernetes; fornisce l'identità per più prodotti Google Cloud e opera principalmente presso del progetto Google Cloud.

  • Kubernetes RBAC è un componente fondamentale di Kubernetes e ti 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 la presenza di un criterio RBAC. Se non è presente un criterio RBAC, GKE controlla le autorizzazioni IAM.

In GKE, IAM e Kubernetes RBAC sono integrati per autorizzare gli utenti a eseguire azioni se dispongono delle autorizzazioni sufficienti in base a entrambi gli strumenti. Questa è una parte importante del bootstrap cluster GKE, poiché per impostazione predefinita gli utenti Google Cloud un RoleBinding RBAC di Kubernetes.

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

In quasi tutti i casi, è possibile utilizzare Kubernetes RBAC al posto di 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 altre ruoli con privilegi più elevati. L'autorizzazione container.clusters.get è obbligatoria 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ò essere fornita da IAM o Kubernetes RBAC.

Definire e assegnare le autorizzazioni

Puoi definire regole RBAC negli oggetti ClusterRole e Role, quindi assegnarle con gli oggetti ClusterRoleBinding e RoleBinding come segue:

  • 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 un gruppo per tutti gli spazi dei nomi del cluster.
  • RoleBinding: assegna un Role o un ClusterRole a un utente o a un gruppo all'interno 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 invece un ClusterRoleBinding.

Definire le autorizzazioni utilizzando i ruoli o i ClusterRole

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

I ruoli e i ClusterRole hanno la stessa sintassi. Ognuno ha una sezione rules, in cui devi definire le risorse a cui si applica la regola e le operazioni consentite per 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"]

Fai riferimento al Ruolo e ClusterRole Documentazione dell'API 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 ClusterRoles per controllare l'accesso a diversi tipi di risorse puoi farlo con i Ruoli. Queste includono:

  • Risorse con ambito cluster come i nodi
  • Endpoint REST non di risorse, ad esempio /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 RoleBindings o ClusterRoleBindings

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

Tipo di soggetto Valore per kind Valore per name
Account utente Google Cloud User Indirizzo email registrato in Google Cloud
Service account Kubernetes ServiceAccount Il nome di un oggetto ServiceAccount di Kubernetes nel cluster
Service account IAM User Indirizzo email dell'account di servizio IAM generato automaticamente
Indirizzo del gruppo Google su un dominio verificato Group Indirizzo email di un gruppo Google Workspace che è membro del gruppo gke-security-groups. Per istruzioni su come configurare Google Gruppi per RBAC, vedi Configurare Google Gruppi per RBAC.

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 all'API utilizzando kubectl

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

Quando esegui il comando kubectl auth can-i senza il flag --as, Identity and Access Management (IAM) esegue l'autorizzazione. Invece, quando aggiungi il flag --as, Kubernetes RBAC esegue l'autorizzazione. Pertanto, dovrai creare le risorse Role e RoleBinding oggetti per RBAC.

Per ulteriori informazioni, consulta Verificare l'accesso all'API.

Utilizzo delle API ed esempi

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

Risoluzione dei problemi e debug

Per eseguire il debug dei problemi relativi a RBAC, utilizza la classe log di controllo delle attività di amministrazione, che è abilitato su tutti i cluster per impostazione predefinita. Se l'accesso a una risorsa o a un'operazione negata poiché in mancanza di autorizzazioni sufficienti, il server API registra un RBAC DENY insieme a informazioni aggiuntive quali i dati impliciti e esplicita appartenenza al gruppo. Se utilizzi Google Gruppi per RBAC, google groups viene visualizzato nel messaggio di log.

Limitazioni

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

Ruoli di discovery predefiniti

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

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

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

Per visualizzare gli endpoint API consentiti dall'oggetto ClusterRole system:discovery, esegui il seguente comando:

kubectl get clusterroles system:discovery -o yaml

Errore Forbidden per gli account di servizio nelle istanze VM Google Cloud

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

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 a Google Cloud l'identità associata al token di accesso, riceve l'ID univoco dell'account di servizio, non l'indirizzo email dell'account di servizio.

Per eseguire correttamente l'autenticazione, crea una nuova VM con userinfo-email l'ambito o crea una nuova associazione di ruolo che utilizza l'ID univoco.

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

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

Per creare una nuova associazione di ruolo che utilizzi l'ID univoco dell'account di servizio per una VM esistente:

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

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Ad esempio, l'output seguente mostra uniqueId per l'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 ruolo utilizzando il uniqueId dell'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 solo un ruolo o un'associazione di ruoli con autorizzazioni specifiche 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 avere già lo stesso alle autorizzazioni concesse nel ruolo associato, con lo stesso l'ambito come associazione del ruolo. In alternativa, devi disporre dell'autorizzazione per eseguire il verbo bind sul ruolo a cui fai riferimento.

Se le autorizzazioni che stai concedendo nel ruolo ti sono state originariamente concesse utilizzando un criterio di autorizzazione IAM anziché RBAC, la richiesta del ruolo o dell'associazione del ruolo potrebbe non riuscire. Ad esempio, considera successiva a una richiesta di creazione del ruolo, da un utente a cui è stato concesso 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 le autorizzazioni solo tramite 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 mitigare questo limite, concedi al chiamante le autorizzazioni nel tramite RBAC al posto di IAM.

In alternativa, puoi utilizzare RBAC o IAM per concedere chiama il verbo escalate, il verbo bind o entrambi. Tuttavia, GKE sconsiglia questo approccio, perché l'utente chiamante può concedere qualsiasi autorizzazione a qualsiasi ruolo.

Passaggi successivi