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, garantendo ai membri le autorizzazioni necessarie per svolgere i propri ruoli, mantenendo al contempo la sicurezza del tuo ambiente con air gap.

Questo documento è rivolto ai gruppi di amministratori della piattaforma e Application Operator (come amministratori IT, security engineer o sviluppatori di applicazioni) che vogliono comprendere l'autorizzazione e 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 documentazione relativa ai segmenti di pubblico per GDC con air gap.

Il modello di controllo dell'accesso

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

Il modello di controllo dell'accesso

Il controllo degli accessi è composto da due fasi distinte: la dimostrazione della tua identità (autenticazione) e la determinazione di ciò che puoi fare (autorizzazione):

  • Autenticazione: GDC non memorizza gli account utente o le 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 o agli IdP esistenti della tua organizzazione (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 gestiti all'interno dell'IdP della tua organizzazione. La concessione di un ruolo a un gruppo lo concede automaticamente a tutti i membri di quel 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 garantire che l'accesso venga concesso 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 crearli e gestirli 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 i prefissi IdP. Vengono invece identificati dal progetto e dal nome (ad esempio, serviceAccount:projectName:serviceAccountName quando utilizzi la CLI gdcloud).

Per saperne di più, consulta Proteggi le account di servizio account.

Autorizzazioni e ruoli

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

GDC offre due tipi di ruoli:

  • Ruoli predefiniti: pacchetti di autorizzazioni integrati creati e gestiti da GDC. GDC fornisce una libreria completa di ruoli predefiniti personalizzati per funzioni lavorative e servizi specifici (che vanno da ruoli generici come Project Viewer a ruoli di servizio granulari come Bucket Project Admin o KMS Viewer).
  • Ruoli personalizzati: pacchetti 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 puramente additive: concedono l'accesso, ma non includono regole di negazione. Quando concedi più ruoli a un membro, questo riceve l'unione di tutte le autorizzazioni di questi ruoli. Per limitare o negare l'accesso a servizi specifici nell'intera 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. In ambienti multizona, i ruoli assegnati a uno dei due ambiti vengono applicati automaticamente a tutte le zone per impostazione predefinita.

Puoi concedere i ruoli ai seguenti ambiti delle risorse:

  • Organizzazione: il contenitore 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 confini di sicurezza rigorosi: i ruoli concessi a livello di progetto si applicano solo a quel progetto specifico e alle sue risorse (come macchine virtuali, database e cluster Kubernetes).

Per saperne di più, consulta 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 su ruoli (RBAC). In un modello RBAC, non assegni le autorizzazioni direttamente a singoli utenti o workload. Assegna 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 nell'ambito di un'organizzazione o di un 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 delle risorse personalizzate (file YAML) utilizzando la CLI kubectl.

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 collegando l'identità del membro a un ruolo di visualizzatore. Quando il membro tenta di visualizzare una macchina virtuale, GDC controlla le associazioni dei ruoli attive, conferma che il ruolo assegnato contiene l'autorizzazione richiesta e autorizza la richiesta.

Mentre la console GDC e l'interfaccia a riga di comando gdcloud si connettono automaticamente alle tue risorse, l'accesso diretto all'API tramite l'interfaccia a riga di comando kubectl richiede l'autenticazione al cluster Kubernetes o al server API specifico che ospita la risorsa generando un file kubeconfig. Per maggiori dettagli, consulta Accedi e genera un file kubeconfig.

Per saperne di più sulla gestione delle associazioni dei ruoli, consulta Concedi e revoca l'accesso.

Differenze tra IAM di GDC con air gap e Google Cloud

Se hai esperienza nella gestione degli accessi in Google Cloud, GDC utilizza concetti simili, ma li implementa in modo diverso per operare all'interno di un'infrastruttura air-gapped basata su Kubernetes.

La tabella seguente 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 su ruoli (RBAC) di Kubernetes, in cui le richieste di accesso vengono valutate localmente dal server API rispetto alle associazioni dei 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 in base alle policy di accesso associate a qualsiasi livello della gerarchia delle risorse.
Associazioni di ruoli Come i membri vengono mappati ai ruoli su risorse specifiche. Risorse personalizzate IAMRoleBinding individuali. Ogni associazione è un oggetto che collega i membri a un ruolo. Le autorizzazioni dei ruoli IAM sono puramente 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 di container utilizzata per organizzare le risorse ed ereditare le autorizzazioni. Gerarchia a due livelli: organizzazione > progetti Gerarchia multilivello: organizzazione > cartelle > progetti
Ambito di autorizzazione multizona Come vengono valutate e propagate le autorizzazioni tra zone o regioni di disponibilità. Utilizza il RBAC di Kubernetes gestito da un server API globale, che coordina e replica le associazioni dei ruoli tra i server API di zona in modo che l'accesso venga applicato 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 zone.
Strumenti client Interfacce principali, strumenti CLI e API utilizzati per gestire l'accesso. Console GDC, CLI gdcloud e API KRM. Console Google Cloud , 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 le API. L'accesso diretto all'API tramite l'interfaccia a riga di comando kubectl richiede l'autenticazione al cluster Kubernetes o al server API specifico che ospita la risorsa generando un file kubeconfig. (La console GDC e l'interfaccia a riga di comando gdcloud si connettono automaticamente alle risorse.) L'accesso diretto all'API tramite endpoint gcloud o REST/gRPC utilizza credenziali centralizzate (gcloud auth login) che si applicano a livello globale a tutti i servizi senza richiedere accessi specifici per il cluster.

Passaggi successivi