GCP - Informazioni di base

Reading time: 17 minutes

Gerarchia delle risorse

Google Cloud utilizza una gerarchia delle risorse che è concettualmente simile a quella di un filesystem tradizionale. Questo fornisce un flusso di lavoro logico genitore/figlio con punti di attacco specifici per politiche e permessi.

A un livello alto, appare così:

Organization
--> Folders
--> Projects
--> Resources

Una macchina virtuale (chiamata Compute Instance) è una risorsa. Una risorsa risiede in un progetto, probabilmente insieme ad altre Compute Instances, bucket di archiviazione, ecc.

Migrazione dei Progetti

È possibile migrare un progetto senza alcuna organizzazione a un'organizzazione con i permessi roles/resourcemanager.projectCreator e roles/resourcemanager.projectMover. Se il progetto si trova all'interno di un'altra organizzazione, è necessario contattare il supporto GCP per spostarlo fuori dall'organizzazione prima. Per ulteriori informazioni, controlla questo.

Politiche dell'Organizzazione

Consentono di centralizzare il controllo sulle risorse cloud della tua organizzazione:

• Centralizza il controllo per configurare restrizioni su come possono essere utilizzate le risorse della tua organizzazione.
• Definisci e stabilisci guardrail per i tuoi team di sviluppo per rimanere all'interno dei confini di conformità.
• Aiuta i proprietari dei progetti e i loro team a muoversi rapidamente senza preoccuparsi di violare la conformità.

Queste politiche possono essere create per influenzare l'intera organizzazione, la cartella o il progetto. I discendenti del nodo della gerarchia delle risorse mirate ereditano la politica dell'organizzazione.

Per definire una politica dell'organizzazione, scegli un vincolo, che è un particolare tipo di restrizione contro un servizio Google Cloud o un gruppo di servizi Google Cloud. Configuri quel vincolo con le restrizioni desiderate.

Casi d'uso comuni

• Limitare la condivisione delle risorse in base al dominio.
• Limitare l'uso degli account di servizio di Identity and Access Management.
• Limitare la posizione fisica delle risorse appena create.
• Disabilitare la creazione di account di servizio.

Ci sono molti altri vincoli che ti danno un controllo dettagliato sulle risorse della tua organizzazione. Per maggiori informazioni, vedere la lista di tutti i vincoli del Servizio Politica dell'Organizzazione.

Politiche dell'Organizzazione Predefinite

Ruoli IAM

Questi sono simili alle politiche IAM in AWS poiché ogni ruolo contiene un insieme di permessi.

Tuttavia, a differenza di AWS, non esiste un repository centralizzato di ruoli. Invece, le risorse danno X ruoli di accesso a Y principi, e l'unico modo per scoprire chi ha accesso a una risorsa è utilizzare il metodo get-iam-policy su quella risorsa.
Questo potrebbe essere un problema perché significa che l'unico modo per scoprire quali permessi ha un principio è chiedere a ogni risorsa a chi sta dando permessi, e un utente potrebbe non avere permessi per ottenere permessi da tutte le risorse.

Ci sono tre tipi di ruoli in IAM:

• Ruoli di base/primitive, che includono i ruoli Owner, Editor e Viewer che esistevano prima dell'introduzione di IAM.
• Ruoli predefiniti, che forniscono accesso granulare per un servizio specifico e sono gestiti da Google Cloud. Ci sono molti ruoli predefiniti, puoi vedere tutti loro con i privilegi che hanno qui.
• Ruoli personalizzati, che forniscono accesso granulare secondo un elenco di permessi specificato dall'utente.

Ci sono migliaia di permessi in GCP. Per controllare se un ruolo ha un permesso puoi cercare il permesso qui e vedere quali ruoli lo hanno.

Puoi anche cercare qui i ruoli predefiniti offerti da ciascun prodotto. Nota che alcuni ruoli non possono essere assegnati agli utenti e solo agli SA a causa di alcuni permessi che contengono.
Inoltre, nota che i permessi avranno effetto solo se sono assegnati al servizio pertinente.

Oppure controlla se un ruolo personalizzato può utilizzare un permesso specifico qui.

GCP - IAM, Principals & Org Policies Enum

Utenti

Nella console GCP non c'è gestione di Utenti o Gruppi, che avviene in Google Workspace. Anche se potresti sincronizzare un diverso provider di identità in Google Workspace.

Puoi accedere agli utenti e gruppi di Workspaces in https://admin.google.com.

MFA può essere forzata per gli utenti di Workspaces, tuttavia, un attaccante potrebbe utilizzare un token per accedere a GCP tramite cli che non sarà protetto da MFA (sarà protetto da MFA solo quando l'utente accede per generarlo: gcloud auth login).

Gruppi

Quando viene creata un'organizzazione, è fortemente consigliato creare diversi gruppi. Se gestisci uno di essi, potresti aver compromesso tutto o una parte importante dell'organizzazione:

Politica di Password Predefinita

• Forzare password forti
• Tra 8 e 100 caratteri
• Nessun riutilizzo
• Nessuna scadenza
• Se le persone accedono a Workspace tramite un provider di terze parti, questi requisiti non vengono applicati.

Account di servizio

Questi sono i principi che le risorse possono avere allegate e accesso per interagire facilmente con GCP. Ad esempio, è possibile accedere al token di autenticazione di un Account di Servizio allegato a una VM nei metadati.
È possibile incontrare alcuni conflitti quando si utilizzano sia IAM che ambiti di accesso. Ad esempio, il tuo account di servizio potrebbe avere il ruolo IAM di compute.instanceAdmin ma l'istanza che hai compromesso è stata limitata con la limitazione dell'ambito di https://www.googleapis.com/auth/compute.readonly. Questo ti impedirebbe di apportare modifiche utilizzando il token OAuth che è automaticamente assegnato alla tua istanza.

È simile ai ruoli IAM di AWS. Ma a differenza di AWS, qualsiasi account di servizio può essere allegato a qualsiasi servizio (non è necessario consentirlo tramite una politica).

Diversi degli account di servizio che troverai sono in realtà generati automaticamente da GCP quando inizi a utilizzare un servizio, come:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Tuttavia, è anche possibile creare e collegare a risorse account di servizio personalizzati, che appariranno in questo modo:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Chiavi e Token

Ci sono 2 modi principali per accedere a GCP come account di servizio:

• Via token OAuth: Questi sono token che otterrai da luoghi come gli endpoint dei metadati o rubando richieste http e sono limitati dagli ambiti di accesso.
• Chiavi: Queste sono coppie di chiavi pubbliche e private che ti permetteranno di firmare richieste come account di servizio e persino generare token OAuth per eseguire azioni come account di servizio. Queste chiavi sono pericolose perché sono più complicate da limitare e controllare, ecco perché GCP raccomanda di non generarle.
• Nota che ogni volta che viene creato un SA, GCP genera una chiave per l'account di servizio a cui l'utente non può accedere (e non sarà elencata nell'applicazione web). Secondo questo thread questa chiave è utilizzata internamente da GCP per dare accesso agli endpoint dei metadati per generare i token OAuth accessibili.

Ambiti di accesso

Gli ambiti di accesso sono allegati ai token OAuth generati per accedere agli endpoint API di GCP. Essi limitano i permessi del token OAuth.
Questo significa che se un token appartiene a un Proprietario di una risorsa ma non ha nell'ambito del token l'accesso a quella risorsa, il token non può essere utilizzato per (ab)usare quei privilegi.

Google in realtà raccomanda che gli ambiti di accesso non vengano utilizzati e di fare totalmente affidamento su IAM. Il portale di gestione web in realtà applica questa regola, ma gli ambiti di accesso possono ancora essere applicati alle istanze utilizzando account di servizio personalizzati programmaticamente.

Puoi vedere quali ambiti sono assegnati eseguendo query:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

I precedenti scopi sono quelli generati per default utilizzando gcloud per accedere ai dati. Questo perché quando usi gcloud crei prima un token OAuth e poi lo usi per contattare gli endpoint.

Lo scopo più importante di quelli potenzialmente è cloud-platform, che fondamentalmente significa che è possibile accedere a qualsiasi servizio in GCP.

Puoi trovare un elenco di tutti i possibili scopi qui.

Se hai le credenziali del browser gcloud, è possibile ottenere un token con altri scopi, facendo qualcosa come:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Politiche IAM di Terraform, Binding e Membri

Come definito da terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, utilizzando terraform con GCP ci sono diversi modi per concedere a un principale accesso a una risorsa:

• Membri: Imposti i principali come membri di ruoli senza restrizioni sul ruolo o sui principali. Puoi mettere un utente come membro di un ruolo e poi mettere un gruppo come membro dello stesso ruolo e anche impostare quei principali (utente e gruppo) come membri di altri ruoli.
• Binding: Diversi principali possono essere legati a un ruolo. Quei principali possono ancora essere legati o essere membri di altri ruoli. Tuttavia, se un principale che non è legato al ruolo è impostato come membro di un ruolo legato, la prossima volta che il binding viene applicato, la membership scomparirà.
• Politiche: Una politica è autoritativa, indica ruoli e principali e poi, quei principali non possono avere più ruoli e quei ruoli non possono avere più principali a meno che quella politica non venga modificata (neanche in altre politiche, binding o membership). Pertanto, quando un ruolo o un principale è specificato nella politica, tutti i suoi privilegi sono limitati da quella politica. Ovviamente, questo può essere eluso nel caso in cui al principale venga data l'opzione di modificare la politica o i permessi di escalation dei privilegi (come creare un nuovo principale e legarlo a un nuovo ruolo).

Riferimenti

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy