Autorizzazione e controllo degli accessi

Identity and Access Management (IAM) in Google Distributed Cloud (GDC) con air gap ti consente di controllare chi ha accesso a quali risorse e quali azioni può eseguire su queste risorse.

Comprendere il funzionamento di IAM in GDC ti aiuta a gestire l'accesso in modo efficace, assicurandoti che i membri dispongano delle autorizzazioni necessarie per svolgere i propri ruoli, mantenendo al contempo la sicurezza dell'ambiente con air gap.

Questo documento è destinato al pubblico dei gruppi di amministratori della piattaforma e operatori delle applicazioni (ad esempio amministratori IT, security engineer o sviluppatori di applicazioni) che vogliono comprendere l'autorizzazione e il controllo dell'accesso in GDC con air gap. Questo documento aiuta anche gli operatori dell'infrastruttura a comprendere i concetti di base del controllo dell'accesso. Per saperne di più, consulta la sezione Pubblico della documentazione di GDC con air gap.

Il modello di controllo dell'accesso

GDC struttura l'accesso intorno a tre componenti principali: membri (chi), ruoli (cosa) e ambito risorsa (dove).

Il modello di controllo dell'accesso

Il controllo dell'accesso è costituito da due fasi distinte: dimostrare chi sei (autenticazione) e determinare cosa puoi fare (autorizzazione):

  • Autenticazione: GDC non archivia account utente o password. GDC si connette al provider di identità (IdP) della tua organizzazione in modo che tu possa accedere con le tue credenziali aziendali.
  • Autorizzazione: dopo l'autenticazione, GDC IAM controlla i ruoli assegnati per determinare a quali risorse puoi accedere e quali azioni puoi eseguire.

Membri

Un membro è un'identità a cui puoi concedere l'accesso alle risorse. GDC raggruppa i membri in due categorie principali in base a dove li gestisci: identità umane e identità non umane.

Identità umane

Le identità umane sono gli utenti e i gruppi che accedono a GDC. Anziché archiviare account utente o password, GDC si connette ai sistemi di accesso esistenti della tua organizzazione o agli IdP (come Active Directory, LDAP o Okta) utilizzando protocolli di federazione delle identità standard come OpenID Connect (OIDC) o SAML 2.0.

Esistono due tipi di identità umane:

  • Utenti: singoli utenti umani che accedono al sistema utilizzando le proprie credenziali aziendali.
  • Gruppi: raccolte di utenti umani gestite all'interno dell'IdP della tua organizzazione. La concessione di un ruolo a un gruppo lo concede automaticamente a tutti i membri del gruppo.

GDC utilizza gli IdP per identificare in modo univoco le identità umane. Poiché il tuo ambiente può connettersi a più IdP (ad esempio, se reparti diversi utilizzano sistemi di accesso diversi), GDC distingue tra gli IdP per assicurarsi di concedere l'accesso alla persona corretta.

Quando gestisce l'accesso, GDC antepone automaticamente un prefisso IdP univoco a tutti i nomi utente e i gruppi esterni:

  • Formato: idpprefix-username@domain.com (o idpprefix-group-name per i gruppi).
  • Esempio: se l'IdP della tua organizzazione è configurato con il prefisso agency-a, e accedi come alice@example.com, GDC IAM ti riconosce come agency-a-alice@example.com.

Identità non umane

Le identità non umane sono chiamate identità di servizio (o service account). Puoi crearle e gestirle direttamente in GDC (come risorse ProjectServiceAccount) per consentire ad applicazioni, script o workload automatizzati di interagire con le API in modo sicuro.

Poiché i service account sono gestiti internamente da GDC, non utilizzano prefissi IdP. Vengono invece identificati dal progetto e dal nome (ad esempio, serviceAccount:projectName:serviceAccountName quando si utilizza gdcloud CLI).

Per saperne di più, consulta la sezione Proteggere le account di servizio account.

Autorizzazioni e ruoli

Un'autorizzazione è l'autorità per eseguire un'azione specifica su una risorsa (ad esempio, creare una VM o eliminare un database). Non concedi le autorizzazioni direttamente ai membri. GDC raggruppa invece le autorizzazioni in ruoli.

GDC offre due tipi di ruoli:

  • Ruoli predefiniti: bundle di autorizzazioni integrate create e gestite da GDC. GDC fornisce una libreria completa di ruoli predefiniti personalizzati per funzioni e servizi specifici (che vanno da ruoli generici come Visualizzatore progetto a ruoli di servizio granulari come Amministratore progetto bucket o Visualizzatore KMS).
  • Ruoli personalizzati: bundle di autorizzazioni definiti dall'utente che puoi creare quando i ruoli predefiniti esistenti non soddisfano le esigenze della tua organizzazione.

Le autorizzazioni concesse tramite i ruoli IAM sono esclusivamente additive; concedono l'accesso, ma non includono regole di negazione. Quando concedi più ruoli a un membro, il membro riceve l'unione di tutte le autorizzazioni in questi ruoli. Per limitare o negare l'accesso a servizi specifici all'interno della tua organizzazione, puoi configurare le policy dell'organizzazione.

Ambito risorsa

Concedi sempre l'accesso a un livello specifico della gerarchia delle risorse GDC. L'ambito determina le risorse a cui il membro può accedere. Negli ambienti multizona, i ruoli assegnati a uno dei due ambiti vengono applicati automaticamente a tutte le zone per impostazione predefinita.

Puoi concedere i ruoli nei seguenti ambiti delle risorse:

  • Organizzazione: il container di primo livello per il tuo ambiente. I ruoli concessi a livello di organizzazione si applicano all'intera organizzazione, ereditando automaticamente tutti i progetti e le risorse al suo interno.
  • Progetto: un container all'interno dell'organizzazione utilizzato per raggruppare le risorse per team o applicazioni specifici. I progetti fungono da limiti di sicurezza rigorosi: i ruoli concessi a livello di progetto si applicano solo a quel progetto specifico e alle relative risorse (come macchine virtuali, database e cluster Kubernetes).

Per saperne di più, consulta le sezioni Gerarchia delle risorse e Controllo delle autorizzazioni per un universo multizona.

Come viene autorizzato l'accesso

GDC gestisce e autorizza l'accesso principalmente utilizzando un modello di controllo dell'accesso basato sui ruoli (RBAC). In un modello RBAC, non assegni le autorizzazioni direttamente a singoli utenti o workload. Assegni invece i ruoli ai membri in un ambito di risorse specifico per determinare l'accesso.

GDC implementa RBAC utilizzando le seguenti risorse personalizzate di Kubernetes:

  • IAMRole: definisce un bundle specifico di autorizzazioni.
  • IAMRoleBinding: collega un membro (un utente umano, un gruppo o un account di servizio) a un IAMRole a livello di organizzazione o progetto.

Per concedere l'accesso alle risorse dell'organizzazione o del progetto, puoi creare un IAMRoleBinding utilizzando la console GDC, la CLI gdcloud o applicando manifest di risorse personalizzate (file YAML) utilizzando kubectl CLI.

Ad esempio, per consentire a un membro del team di visualizzare le macchine virtuali all'interno di un progetto, puoi creare un IAMRoleBinding nell'ambito del progetto che collega l'identità del membro a un ruolo di visualizzatore. Quando il membro tenta di visualizzare una macchina virtuale, GDC controlla le associazioni di ruoli attive, verifica che il ruolo assegnato contenga l'autorizzazione richiesta e autorizza la richiesta.

Mentre la console GDC e la CLI gdcloud si connettono automaticamente alle risorse, l'accesso diretto all'API utilizzando kubectl CLI richiede l'autenticazione al cluster Kubernetes o al server API specifico che ospita la risorsa generando un file kubeconfig. Per maggiori dettagli, consulta la sezione Accedere e generare un file kubeconfig.

Per saperne di più sulla gestione delle associazioni di ruoli, consulta la sezione Concedere e revocare l'accesso.

Differenze tra GDC con air gap e IAM Google Cloud

Se hai esperienza nella gestione dell'accesso in Google Cloud, GDC utilizza concetti simili, ma li implementa in modo diverso per operare all'interno di un'infrastruttura con air gap basata su Kubernetes.

La seguente tabella fornisce un confronto tra IAM in GDC e Google Cloud:

Funzionalità Descrizione GDC con air gap Google Cloud
Identità utente (autenticazione) Sistema di identità utilizzato per autenticare gli utenti umani. Federato con l'IdP esterno utilizzando i prefissi IdP richiesti (ad esempio, idpprefix-user@domain.com). Account Google (come Gmail) o identità aziendali federate tramite Cloud Identity o Google Workspace.
Motore di autorizzazione Il sistema sottostante che valuta e applica le autorizzazioni. Principalmente controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes, in cui le richieste di accesso vengono valutate localmente dal server API rispetto alle associazioni di ruoli. Puoi utilizzare le policy dell'organizzazione per impostare le limitazioni delle risorse. Il servizio Cloud IAM globale di Google. Valuta le richieste API a livello centrale rispetto alle policy di accesso associate a qualsiasi livello della gerarchia delle risorse.
Associazioni di ruoli Come vengono mappati i membri ai ruoli su risorse specifiche. Singole risorse personalizzate IAMRoleBinding. Ogni associazione è un oggetto che collega i membri a un ruolo. Le autorizzazioni dei ruoli IAM sono esclusivamente additive (le regole di negazione possono essere configurate separatamente tramite le policy dell'organizzazione). Una singola policy di accesso IAM associata a ogni risorsa, cartella o organizzazione. Contiene più associazioni che mappano i membri ai ruoli e supporta regole condizionali o regole di negazione.
Service account Identità non umane utilizzate da applicazioni e workload automatizzati. Service account locali creati all'interno di un progetto specifico (ProjectServiceAccount). Le chiavi pubbliche vengono archiviate nel cluster, mentre le chiavi private vengono gestite e protette localmente dal client. Identità globali gestite centralmente da Google. Le credenziali possono essere gestite automaticamente da Google o scaricate come file di chiavi per l'autenticazione da qualsiasi luogo.
Gerarchia delle risorse Struttura dei container utilizzata per organizzare le risorse ed ereditare le autorizzazioni. Gerarchia a due livelli: organizzazione > progetti Gerarchia a più livelli: organizzazione > cartelle > progetti
Ambito delle autorizzazioni multizona Come vengono valutate e propagate le autorizzazioni tra zone di disponibilità o regioni. Utilizza RBAC di Kubernetes gestito da un server API globale, che coordina e replica le associazioni di ruoli tra i server API zonali in modo che l'accesso si applichi a tutte le zone per impostazione predefinita. Utilizza un servizio IAM globale completamente gestito. Le autorizzazioni assegnate a qualsiasi livello di risorsa sono intrinsecamente globali e si applicano automaticamente a tutte le regioni e le zone.
Strumenti client Interfacce principali, strumenti CLI e API utilizzati per gestire l'accesso. Console GDC, CLI gdcloud e API KRM. Google Cloud console, gcloud CLI e API REST o gRPC.
Accesso diretto all'API Come gli strumenti e gli script si autenticano per gestire le risorse direttamente utilizzando API. L'accesso diretto all'API utilizzando kubectl CLI richiede l'autenticazione al cluster Kubernetes o al server API specifico che ospita la risorsa generando un file kubeconfig. (La console GDC e la CLI gdcloud si connettono automaticamente alle risorse.) L'accesso diretto all'API utilizzando gcloud o gli endpoint REST/gRPC utilizza credenziali centralizzate (gcloud auth login) che si applicano a livello globale a tutti i servizi senza richiedere accessi specifici del cluster.

Passaggi successivi