# GCP - Informazioni di base

{{#include ../../../banners/hacktricks-training.md}}

## **Gerarchia delle risorse**

Google Cloud utilizza una [gerarchia delle risorse](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) 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.

<figure><img src="../../../images/image (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption><p><a href="https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg">https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg</a></p></figcaption></figure>

## **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**](https://medium.com/google-cloud/migrating-a-project-from-one-organization-to-another-gcp-4b37a86dd9e6).

## **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**](https://cloud.google.com/resource-manager/docs/organization-policy/overview#constraints), 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**.

<figure><img src="../../../images/image (217).png" alt=""><figcaption><p><a href="https://cloud.google.com/resource-manager/img/org-policy-concepts.svg">https://cloud.google.com/resource-manager/img/org-policy-concepts.svg</a></p></figcaption></figure>

#### Casi d'uso comuni <a href="#common_use_cases" id="common_use_cases"></a>

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

<figure><img src="../../../images/image (172).png" alt=""><figcaption></figcaption></figure>

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**](https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)**.**

### **Politiche dell'Organizzazione Predefinite**

<details>

<summary>Queste sono le politiche che Google aggiungerà per impostazione predefinita quando configuri la tua organizzazione GCP:</summary>

**Politiche di Gestione degli Accessi**

- **Contatti con dominio ristretto:** Impedisce di aggiungere utenti ai Contatti Essenziali al di fuori dei domini specificati. Questo limita i Contatti Essenziali a consentire solo identità utente gestite nei domini selezionati di ricevere notifiche della piattaforma.
- **Condivisione con dominio ristretto:** Impedisce di aggiungere utenti alle politiche IAM al di fuori dei domini specificati. Questo limita le politiche IAM a consentire solo identità utente gestite nei domini selezionati di accedere alle risorse all'interno di questa organizzazione.
- **Prevenzione dell'accesso pubblico:** Impedisce che i bucket di Cloud Storage siano esposti al pubblico. Questo garantisce che uno sviluppatore non possa configurare i bucket di Cloud Storage per avere accesso a Internet non autenticato.
- **Accesso uniforme a livello di bucket:** Impedisce le liste di controllo degli accessi (ACL) a livello di oggetto nei bucket di Cloud Storage. Questo semplifica la gestione degli accessi applicando le politiche IAM in modo coerente su tutti gli oggetti nei bucket di Cloud Storage.
- **Richiedere accesso OS:** Le VM create in nuovi progetti avranno l'accesso OS abilitato. Questo ti consente di gestire l'accesso SSH alle tue istanze utilizzando IAM senza dover creare e gestire singole chiavi SSH.

**Politiche di sicurezza aggiuntive per gli account di servizio**

- **Disabilita le concessioni IAM automatiche**: Impedisce che gli account di servizio predefiniti di App Engine e Compute Engine ricevano automaticamente il ruolo IAM Editor su un progetto al momento della creazione. Questo garantisce che gli account di servizio non ricevano ruoli IAM eccessivamente permissivi al momento della creazione.
- **Disabilita la creazione di chiavi per account di servizio**: Impedisce la creazione di chiavi pubbliche per account di servizio. Questo aiuta a ridurre il rischio di esposizione di credenziali persistenti.
- **Disabilita il caricamento di chiavi per account di servizio**: Impedisce il caricamento di chiavi pubbliche per account di servizio. Questo aiuta a ridurre il rischio di materiali di chiave trapelati o riutilizzati.

**Politiche di configurazione sicura della rete VPC**

- **Definisci IP esterni consentiti per le istanze VM**: Impedisce la creazione di istanze Compute con un IP pubblico, che può esporle al traffico Internet.

* **Disabilita la virtualizzazione nidificata delle VM**: Impedisce la creazione di VM nidificate su VM di Compute Engine. Questo riduce il rischio di sicurezza di avere VM nidificate non monitorate.

- **Disabilita la porta seriale delle VM:** Impedisce l'accesso alla porta seriale delle VM di Compute Engine. Questo impedisce l'input alla porta seriale di un server utilizzando l'API di Compute Engine.

* **Limita le reti autorizzate sulle istanze Cloud SQL:** Impedisce a intervalli di rete pubblici o non interni di accedere ai tuoi database Cloud SQL.

- **Limita l'inoltro dei protocolli in base al tipo di indirizzo IP:** Impedisce l'inoltro dei protocolli VM per indirizzi IP esterni.

* **Limita l'accesso IP pubblico sulle istanze Cloud SQL:** Impedisce la creazione di istanze Cloud SQL con un IP pubblico, che può esporle al traffico Internet.

- **Limita la rimozione del vincolo del progetto VPC condiviso:** Impedisce l'eliminazione accidentale dei progetti host VPC condivisi.

* **Imposta l'impostazione DNS interna per i nuovi progetti su DNS Zonale Solo:** Impedisce l'uso di un'impostazione DNS legacy che ha ridotto la disponibilità del servizio.

- **Salta la creazione della rete predefinita:** Impedisce la creazione automatica della rete VPC predefinita e delle risorse correlate. Questo evita regole firewall predefinite eccessivamente permissive.

* **Disabilita l'uso di IPv6 esterni VPC:** Impedisce la creazione di subnet IPv6 esterne, che possono essere esposte a accessi non autorizzati a Internet.

</details>

## **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**](https://cloud.google.com/iam/docs/understanding-roles#predefined_roles).
- **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**](https://cloud.google.com/iam/docs/permissions-reference) e vedere quali ruoli lo hanno.

Puoi anche [**cercare qui i ruoli predefiniti**](https://cloud.google.com/iam/docs/understanding-roles#product_specific_documentation) **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**](https://cloud.google.com/iam/docs/custom-roles-permissions-support)**.**

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

## Utenti <a href="#default-credentials" id="default-credentials"></a>

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**](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:

<table data-header-hidden><thead><tr><th width="299.3076923076923"></th><th></th></tr></thead><tbody><tr><td><strong>Gruppo</strong></td><td><strong>Funzione</strong></td></tr><tr><td><strong><code>gcp-organization-admins</code></strong><br><em>(gruppo o account individuali richiesti per la checklist)</em></td><td>Amministrare qualsiasi risorsa che appartiene all'organizzazione. Assegna questo ruolo con parsimonia; gli admin dell'organizzazione hanno accesso a tutte le tue risorse Google Cloud. In alternativa, poiché questa funzione è altamente privilegiata, considera di utilizzare account individuali invece di creare un gruppo.</td></tr><tr><td><strong><code>gcp-network-admins</code></strong><br><em>(richiesto per la checklist)</em></td><td>Creare reti, subnet, regole firewall e dispositivi di rete come Cloud Router, Cloud VPN e bilanciatori di carico cloud.</td></tr><tr><td><strong><code>gcp-billing-admins</code></strong><br><em>(richiesto per la checklist)</em></td><td>Impostare conti di fatturazione e monitorare il loro utilizzo.</td></tr><tr><td><strong><code>gcp-developers</code></strong><br><em>(richiesto per la checklist)</em></td><td>Progettare, codificare e testare applicazioni.</td></tr><tr><td><strong><code>gcp-security-admins</code></strong><br></td><td>Stabilire e gestire politiche di sicurezza per l'intera organizzazione, inclusa la gestione degli accessi e <a href="https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints">politiche di vincolo dell'organizzazione</a>. Vedi la <a href="https://cloud.google.com/architecture/security-foundations/authentication-authorization#users_and_groups">guida alle fondamenta di sicurezza di Google Cloud</a> per ulteriori informazioni sulla pianificazione della tua infrastruttura di sicurezza Google Cloud.</td></tr><tr><td><strong><code>gcp-devops</code></strong></td><td>Creare o gestire pipeline end-to-end che supportano integrazione e distribuzione continue, monitoraggio e provisioning di sistemi.</td></tr><tr><td><strong><code>gcp-logging-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-logging-viewers</code></strong></td><td></td></tr><tr><td><strong><code>gcp-monitor-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-billing-viewer</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Monitorare la spesa sui progetti. I membri tipici fanno parte del team finanziario.</td></tr><tr><td><strong><code>gcp-platform-viewer</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Esaminare le informazioni sulle risorse nell'organizzazione Google Cloud.</td></tr><tr><td><strong><code>gcp-security-reviewer</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Esaminare la sicurezza del cloud.</td></tr><tr><td><strong><code>gcp-network-viewer</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Esaminare le configurazioni di rete.</td></tr><tr><td><strong><code>grp-gcp-audit-viewer</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Visualizzare i registri di audit.</td></tr><tr><td><strong><code>gcp-scc-admin</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Amministrare il Security Command Center.</td></tr><tr><td><strong><code>gcp-secrets-admin</code></strong><br><em>(non più per impostazione predefinita)</em></td><td>Gestire i segreti in Secret Manager.</td></tr></tbody></table>

## **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.

<figure><img src="../../../images/image (20).png" alt=""><figcaption></figcaption></figure>

<figure><img src="../../../images/image (22).png" alt=""><figcaption></figcaption></figure>

## **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**](https://www.reddit.com/r/googlecloud/comments/f0ospy/service_account_keys_observations/) 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](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) 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:**
```bash
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**](https://developers.google.com/identity/protocols/googlescopes)**.**

Se hai le credenziali del browser **`gcloud`**, è possibile **ottenere un token con altri scopi,** facendo qualcosa come:
```bash
# 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](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://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](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy)

{{#include ../../../banners/hacktricks-training.md}}
