Questa pagina è stata tradotta dall'API Cloud Translation.

Controllo dell'accesso

Autopilot Standard

Questa pagina spiega le differenze tra Identity and Access Management (IAM) e controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes in Google Kubernetes Engine per aiutarti a gestire l'accesso alle risorse all'interno del tuo progetto.

Questa pagina è rivolta agli esperti di sicurezza che controllano l'accesso alle autorizzazioni e vogliono comprendere le differenze e le sovrapposizioni tra IAM e RBAC. 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.

Quando crei un progetto Google Cloud , sei l'unico utente del progetto. Per impostazione predefinita, nessun altro utente ha accesso al tuo progetto o alle sue risorse, incluse le risorse Google Kubernetes Engine (GKE). GKE supporta più opzioni per gestire l'accesso alle risorse all'interno del progetto e dei relativi cluster utilizzando controllo dell'accesso basato sui ruoli (RBAC).

Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

Questi meccanismi hanno una sovrapposizione funzionale, ma sono destinati a diversi tipi di risorse. Ciascuna opzione è spiegata in una sezione dedicata di questa pagina, ma in breve:

Kubernetes RBAC è integrato in Kubernetes e concede autorizzazioni granulari agli oggetti all'interno dei cluster Kubernetes. Le autorizzazioni esistono come oggetti ClusterRole o Role all'interno del cluster. Gli oggetti RoleBinding concedono ruoli a utenti Kubernetes, utenti Google Cloud , service account IAM o Google Gruppi.

Se utilizzi principalmente GKE e hai bisogno di autorizzazioni granulari per ogni oggetto e operazione all'interno del cluster, Kubernetes RBAC è la scelta migliore.
IAM gestisce le risorse Google Cloud , inclusi cluster e tipi di oggetti all'interno dei cluster. Le autorizzazioni vengono assegnate alle entità IAM.

Non esiste un meccanismo per concedere autorizzazioni per oggetti Kubernetes specifici in IAM. Ad esempio, puoi concedere a un utente l'autorizzazione per creare CustomResourceDefinitions (CRD), ma non puoi concedere all'utente l'autorizzazione per creare una sola CustomResourceDefinition specifica o limitare la creazione a uno spazio dei nomi specifico o a un cluster specifico nel progetto. Un ruolo IAM concede privilegi in tutti i cluster del progetto o in tutti i cluster di tutti i progetti secondari se il ruolo viene applicato a livello di cartella.

Se utilizzi più Google Cloud componenti e non devi gestire autorizzazioni granulari specifiche di Kubernetes, IAM è una buona scelta.

Kubernetes RBAC

Kubernetes offre il supporto integrato per RBAC, che consente di creare ruoli granulari che esistono all'interno del cluster Kubernetes. Un ruolo può essere limitato a un oggetto Kubernetes specifico o a un tipo di oggetto Kubernetes e definisce quali azioni (chiamate verbi) il ruolo concede in relazione a quell'oggetto. Un RoleBinding è anche un oggetto Kubernetes e concede ruoli agli utenti. Un utente GKE può essere:

Google Cloud user
Account di servizio IAM
ServiceAccount Kubernetes
Utente di Google Workspace
Gruppo Google Google Workspace
Utenti autenticati tramite certificati client X.509

Per saperne di più, consulta la sezione Controllo degli accessi basato sui ruoli.

IAM

IAM ti consente di concedere ruoli alle entità. Un ruolo è una raccolta di autorizzazioni e, se concesso a un'entità, controlla l'accesso a una o più Google Cloud risorse. Puoi utilizzare i seguenti tipi di ruoli:

I ruoli di base forniscono autorizzazioni grossolane limitate a Proprietario, Editor e Visualizzatore.
I ruoli predefiniti, come i ruoli predefiniti per GKE, forniscono un accesso più granulare rispetto ai ruoli di base e coprono molti casi d'uso comuni.
I ruoli personalizzati ti consentono di creare combinazioni uniche di autorizzazioni.

Un principal può essere uno dei seguenti:

Account utente
Service account
Gruppo Google Google Workspace
Dominio Google Workspace
Dominio Cloud Identity

Tipi di criteri IAM

IAM supporta i seguenti tipi di criteri:

Policy di autorizzazione: concedono ruoli alle entità. Per maggiori dettagli, vedi Criteri di autorizzazione.
Criteri di negazione: impediscono alle entità di utilizzare autorizzazioni IAM specifiche indipendentemente dai ruoli concessi. Per i dettagli, consulta Policy di negazione.

Utilizza i criteri di negazione per impedire a entità specifiche di eseguire azioni specifiche nel progetto, nella cartella o nell'organizzazione, anche se un criterio di autorizzazione IAM concede a queste entità un ruolo che contiene le autorizzazioni pertinenti.

Suggerimenti IAM

Prendi in considerazione l'utilizzo dei seguenti ruoli IAM predefiniti per facilitare gli scenari comuni:

Visualizzatore dei cluster Kubernetes Engine (roles/container.clusterViewer): DevOps, ingegneri e sviluppatori di applicazioni che devono solo connettersi al cluster.
Kubernetes Engine Cluster Admin (roles/container.clusterAdmin): amministratori della piattaforma e operatori del cluster che devono gestire uno o più cluster in un progetto Google Cloud .

Per un elenco dei ruoli IAM predefiniti disponibili, consulta Ruoli GKE predefiniti.

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account nodo devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) sul tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Interazione di IAM con Kubernetes RBAC

IAM e Kubernetes RBAC collaborano per gestire l'accesso al tuo cluster. RBAC controlla l'accesso a livello di cluster e spazio dei nomi, mentre IAM funziona a livello di progetto. Un'entità deve disporre di autorizzazioni sufficienti a uno dei due livelli per lavorare con le risorse nel cluster.