Autorizzazione e controllo degli accessi

Identity and Access Management (IAM) nell'appliance air-gapped di Google Distributed Cloud (GDC) 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 che i membri dispongano delle autorizzazioni necessarie per svolgere i propri ruoli, mantenendo al contempo la sicurezza dell'ambiente air-gapped.

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 la propria identità (autenticazione) e determinare cosa si può fare (autorizzazione):

  • Autenticazione: GDC non archivia account utente o password. GDC può sfruttare il provider di identità (IdP) Keycloak in bundle o connettersi all'IdP della tua organizzazione in modo da poter accedere con le tue credenziali.
  • 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 può sfruttare l'IdP Keycloak in bundle o connettersi ai sistemi di accesso 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.
  • Gruppi: raccolte di utenti umani gestite all'interno di Keycloak o 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 in modo sicuro con le API.

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ù, vedi 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 di lavoro specifici (che vanno da ruoli ampi 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 cumulative; 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.

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.

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).

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 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 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, vedi Accedere e generare un file kubeconfig.

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

In che modo IAM di GDC con air gap differisce da 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 air-gapped basata su Kubernetes.

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

Funzionalità Descrizione GDC air-gapped Google Cloud
Identità utente (autenticazione) Sistema di identità utilizzato per autenticare gli utenti umani. Federato con l'IdP esterno o gestito con l'IdP Keycloak in bundle, 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. 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 i membri vengono mappati 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 cumulative. 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 multilivello: organizzazione > cartelle > progetti
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 In che modo 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