# GCP - Basiese Inligting

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

## **Hulpbron hiërargie**

Google Cloud gebruik 'n [Hulpbron hiërargie](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) wat konseptueel soortgelyk is aan dié van 'n tradisionele lêerstelsel. Dit bied 'n logiese ouer/kind werksvloei met spesifieke aanhegpunte vir beleide en toestemmings.

Op 'n hoë vlak lyk dit soos volg:
```
Organization
--> Folders
--> Projects
--> Resources
```
'n Virtuele masjien (genoem 'n Compute Instance) is 'n hulpbron. 'n Hulpbron woon in 'n projek, waarskynlik langs ander Compute Instances, stoor emmers, ens.

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

## **Projek Migrasie**

Dit is moontlik om 'n **projek sonder enige organisasie** na 'n organisasie met die toestemmings `roles/resourcemanager.projectCreator` en `roles/resourcemanager.projectMover` te **migreer**. As die projek binne 'n ander organisasie is, is dit nodig om GCP-ondersteuning te kontak om **eerstens uit die organisasie te beweeg**. Vir meer inligting, kyk na [**hierdie**](https://medium.com/google-cloud/migrating-a-project-from-one-organization-to-another-gcp-4b37a86dd9e6).

## **Organisasie Beleide**

Laat jou toe om sentrale beheer oor jou organisasie se wolkhulpbronne te hê:

- Sentrale beheer om **beperkings** te konfigureer oor hoe jou organisasie se hulpbronne gebruik kan word.
- Definieer en stel **grenslyne** vas vir jou ontwikkelingspan om binne nakomingsgrense te bly.
- Help projek eienaars en hul spanne om vinnig te beweeg sonder om bekommerd te wees oor die oortreding van nakomings.

Hierdie beleide kan geskep word om **die hele organisasie, vouer(s) of projek(te)** te **affekteer**. Afstammelinge van die geteikende hulpbron hiërargie node **erf die organisasie beleid**.

Om 'n **organisasie beleid** te **definieer**, **kies jy 'n** [**beperking**](https://cloud.google.com/resource-manager/docs/organization-policy/overview#constraints), wat 'n spesifieke tipe beperking teenoor 'n Google Cloud diens of 'n groep Google Cloud dienste is. Jy **konfigureer daardie beperking met jou gewenste beperkings**.

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

#### Algemene gebruiksgevalle <a href="#common_use_cases" id="common_use_cases"></a>

- Beperk hulpbrondeling gebaseer op domein.
- Beperk die gebruik van Identiteit en Toegang Bestuur diens rekeninge.
- Beperk die fisiese ligging van nuut geskepte hulpbronne.
- Deaktiveer diensrekening skepping.

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

Daar is baie meer beperkings wat jou fyn beheer oor jou organisasie se hulpbronne gee. Vir **meer inligting, sien die** [**lys van alle Organisasie Beleid Diens beperkings**](https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)**.**

### **Standaard Organisasie Beleide**

<details>

<summary>Dit is die beleide wat Google standaard sal byvoeg wanneer jy jou GCP-organisasie opstel:</summary>

**Toegang Bestuur Beleide**

- **Domein beperkte kontakte:** Voorkom die toevoeging van gebruikers aan Essensiële Kontakte buite jou gespesifiseerde domeine. Dit beperk Essensiële Kontakte om slegs bestuurde gebruikersidentiteite in jou geselekteerde domeine toe te laat om platform kennisgewings te ontvang.
- **Domein beperkte deling:** Voorkom die toevoeging van gebruikers aan IAM beleide buite jou gespesifiseerde domeine. Dit beperk IAM beleide om slegs bestuurde gebruikersidentiteite in jou geselekteerde domeine toe te laat om hulpbronne binne hierdie organisasie te benader.
- **Publieke toegang voorkoming:** Voorkom dat Cloud Storage emmers aan die publiek blootgestel word. Dit verseker dat 'n ontwikkelaar nie Cloud Storage emmers kan konfigureer om nie-geverifieerde internet toegang te hê nie.
- **Uniform emmer vlak toegang:** Voorkom objek-vlak toegang beheer lyste (ACLs) in Cloud Storage emmers. Dit vereenvoudig jou toegang bestuur deur IAM beleide konsekwent oor alle objek in Cloud Storage emmers toe te pas.
- **Vereis OS aanmelding:** VM's wat in nuwe projekte geskep word, sal OS Aanmelding geaktiveer hê. Dit laat jou toe om SSH toegang tot jou instansies te bestuur met behulp van IAM sonder om individuele SSH sleutels te moet skep en bestuur.

**Addisionele sekuriteitsbeleide vir diensrekeninge**

- **Deaktiveer outomatiese IAM toekennings**: Voorkom dat die standaard App Engine en Compute Engine diensrekeninge outomaties die Redigeerder IAM rol op 'n projek by skepping toegeken word. Dit verseker dat diensrekeninge nie oormatig permissiewe IAM rolle ontvang nie.
- **Deaktiveer diensrekening sleutel skepping**: Voorkom die skepping van publieke diensrekening sleutels. Dit help om die risiko van blootstelling van volgehoue akrediteer te verminder.
- **Deaktiveer diensrekening sleutel opgelaai**: Voorkom die opgelaai van publieke diensrekening sleutels. Dit help om die risiko van gelekte of hergebruikte sleutel materiaal te verminder.

**Veilige VPC netwerk konfigurasie beleide**

- **Definieer toegelate eksterne IP's vir VM instansies**: Voorkom die skepping van Compute instansies met 'n publieke IP, wat hulle aan internetverkeer kan blootstel.

* **Deaktiveer VM geneste virtualisering**: Voorkom die skepping van geneste VM's op Compute Engine VM's. Dit verminder die sekuriteitsrisiko van onopgemerkte geneste VM's.

- **Deaktiveer VM seriële poort:** Voorkom seriële poort toegang tot Compute Engine VM's. Dit voorkom invoer na 'n bediener se seriële poort met behulp van die Compute Engine API.

* **Beperk geautoriseerde netwerke op Cloud SQL instansies:** Voorkom dat publieke of nie-interne netwerkreekse toegang tot jou Cloud SQL databasisse verkry.

- **Beperk Protokol Oorgang gebaseer op tipe IP Adres:** Voorkom VM protokol oorgang vir eksterne IP adresse.

* **Beperk Publieke IP toegang op Cloud SQL instansies:** Voorkom die skepping van Cloud SQL instansies met 'n publieke IP, wat hulle aan internetverkeer kan blootstel.

- **Beperk gedeelde VPC projek lien verwydering:** Voorkom die toevallige verwydering van Gedeelde VPC gasheer projekte.

* **Stel die interne DNS instelling vir nuwe projekte op Zonal DNS Slegs:** Voorkom die gebruik van 'n erflike DNS instelling wat diens beskikbaarheid verminder het.

- **Slaan standaard netwerk skepping oor:** Voorkom outomatiese skepping van die standaard VPC netwerk en verwante hulpbronne. Dit vermy oormatig permissiewe standaard vuurmuur reëls.

* **Deaktiveer VPC Eksterne IPv6 gebruik:** Voorkom die skepping van eksterne IPv6 subnetwerke, wat aan nie-geautoriseerde internet toegang blootgestel kan word.

</details>

## **IAM Rolle**

Hierdie is soos IAM beleide in AWS aangesien **elke rol 'n stel toestemmings bevat.**

Echter, anders as in AWS, is daar **geen gesentraliseerde repo** van rolle nie. In plaas daarvan, **gee hulpbronne X toegang rolle aan Y prinsipes**, en die enigste manier om uit te vind wie toegang tot 'n hulpbron het, is om die **`get-iam-policy` metode oor daardie hulpbron** te gebruik.\
Dit kan 'n probleem wees omdat dit beteken dat die enigste manier om uit te vind **watter toestemmings 'n prinsipe het, is om elke hulpbron te vra wie dit toestemming gee**, en 'n gebruiker mag nie toestemming hê om toestemming van alle hulpbronne te kry nie.

Daar is **drie tipes** rolle in IAM:

- **Basiese/Primitive rolle**, wat die **Eienaar**, **Redigeerder**, en **Kykers** rolle insluit wat voor die bekendstelling van IAM bestaan het.
- **Vooraf gedefinieerde rolle**, wat fyn toegang bied vir 'n spesifieke diens en deur Google Cloud bestuur word. Daar is baie vooraf gedefinieerde rolle, jy kan **almal daarvan met die voorregte wat hulle het** [**hier**](https://cloud.google.com/iam/docs/understanding-roles#predefined_roles) sien.
- **Pasgemaakte rolle**, wat fyn toegang bied volgens 'n gebruiker-gespesifiseerde lys van toestemmings.

Daar is duisende toestemmings in GCP. Om te kyk of 'n rol 'n toestemming het, kan jy [**hier die toestemming soek**](https://cloud.google.com/iam/docs/permissions-reference) en sien watter rolle dit het.

Jy kan ook [**hier vooraf gedefinieerde rolle soek**](https://cloud.google.com/iam/docs/understanding-roles#product_specific_documentation) **wat deur elke produk aangebied word.** Let daarop dat sommige **rolle** nie aan gebruikers geheg kan word nie en **slegs aan SA's omdat sommige toestemmings** wat hulle bevat.\
Boonop, let daarop dat **toestemmings** slegs **in werking sal tree** as hulle **aan die relevante diens geheg is.**

Of kyk of 'n **pasgemaakte rol 'n** [**spesifieke toestemming hier kan gebruik**](https://cloud.google.com/iam/docs/custom-roles-permissions-support)**.**

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

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

In **GCP-konsol** is daar **geen Gebruikers of Groepe** bestuur nie, dit word in **Google Workspace** gedoen. Alhoewel jy 'n ander identiteitsverskaffer in Google Workspace kan sinkroniseer.

Jy kan Workspaces **gebruikers en groepe in** [**https://admin.google.com**](https://admin.google.com/) benader.

**MFA** kan **gedwonge** word vir Workspaces gebruikers, egter, 'n **aanvaller** kan 'n token gebruik om GCP **via cli te benader wat nie deur MFA beskerm sal word nie** (dit sal slegs deur MFA beskerm word wanneer die gebruiker aanmeld om dit te genereer: `gcloud auth login`).

## Groepe

Wanneer 'n organisasie geskep word, word verskeie groepe **sterk aanbeveel om geskep te word.** As jy enige van hulle bestuur, mag jy al die of 'n belangrike deel van die organisasie gecompromitteer het:

<table data-header-hidden><thead><tr><th width="299.3076923076923"></th><th></th></tr></thead><tbody><tr><td><strong>Groep</strong></td><td><strong>Funksie</strong></td></tr><tr><td><strong><code>gcp-organization-admins</code></strong><br><em>(groep of individuele rekeninge benodig vir kontrolelys)</em></td><td>Bestuur enige hulpbron wat aan die organisasie behoort. Ken hierdie rol spaarzaam toe; org admins het toegang tot al jou Google Cloud hulpbronne. Alternatiewelik, omdat hierdie funksie hoogs bevoeg is, oorweeg om individuele rekeninge te gebruik eerder as om 'n groep te skep.</td></tr><tr><td><strong><code>gcp-network-admins</code></strong><br><em>(benodig vir kontrolelys)</em></td><td>Skep netwerke, subnetwerke, vuurmuur reëls, en netwerk toestelle soos Cloud Router, Cloud VPN, en wolk laaibalansers.</td></tr><tr><td><strong><code>gcp-billing-admins</code></strong><br><em>(benodig vir kontrolelys)</em></td><td>Stel faktuur rekeninge op en monitor hul gebruik.</td></tr><tr><td><strong><code>gcp-developers</code></strong><br><em>(benodig vir kontrolelys)</em></td><td>Ontwerp, kodeer, en toets toepassings.</td></tr><tr><td><strong><code>gcp-security-admins</code></strong><br></td><td>Stel en bestuur sekuriteitsbeleide vir die hele organisasie, insluitend toegang bestuur en <a href="https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints">organisasie beperking beleide</a>. Sien die <a href="https://cloud.google.com/architecture/security-foundations/authentication-authorization#users_and_groups">Google Cloud sekuriteitsfondasies gids</a> vir meer inligting oor die beplanning van jou Google Cloud sekuriteitsinfrastruktuur.</td></tr><tr><td><strong><code>gcp-devops</code></strong></td><td>Skep of bestuur end-to-end pyplyne wat deurlopende integrasie en aflewering, monitering, en stelsels voorsiening ondersteun.</td></tr><tr><td><strong><code>gcp-logging-admins</code></strong><td></td></tr><tr><td><strong><code>gcp-logging-viewers</code></strong><td></td></tr><tr><td><strong><code>gcp-monitor-admins</code></strong><td></td></tr><tr><td><strong><code>gcp-billing-viewer</code></strong><br><em>(nie meer standaard nie)</em></td><td>Monitor die besteding op projekte. Tipiese lede is deel van die finansiële span.</td></tr><tr><td><strong><code>gcp-platform-viewer</code></strong><br><em>(nie meer standaard nie)</em></td><td>Herbekend hulpbron inligting oor die Google Cloud organisasie.</td></tr><tr><td><strong><code>gcp-security-reviewer</code></strong><br><em>(nie meer standaard nie)</em></td><td>Herbekend wolk sekuriteit.</td></tr><tr><td><strong><code>gcp-network-viewer</code></strong><br><em>(nie meer standaard nie)</em></td><td>Herbekend netwerk konfigurasies.</td></tr><tr><td><strong><code>grp-gcp-audit-viewer</code></strong><br><em>(nie meer standaard nie)</em></td><td>Bekyk oudit logs.</td></tr><tr><td><strong><code>gcp-scc-admin</code></strong><br><em>(nie meer standaard nie)</em></td><td>Bestuur Sekuriteitsopdrag Sentrum.</td></tr><tr><td><strong><code>gcp-secrets-admin</code></strong><br><em>(nie meer standaard nie)</em></td><td>Bestuur geheime in Secret Manager.</td></tr></tbody></table>

## **Standaard Wagwoord Beleid**

- Handhaaf sterk wagwoorde
- Tussen 8 en 100 karakters
- Geen hergebruik
- Geen vervaldatum
- As mense toegang tot Workspace deur 'n derdeparty verskaffer, word hierdie vereistes nie toegepas nie.

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

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

## **Diensrekeninge**

Dit is die prinsipes wat **hulpbronne** kan **he** **geheg** en toegang het om maklik met GCP te interaksie. Byvoorbeeld, dit is moontlik om die **auth token** van 'n Diensrekening **geheg aan 'n VM** in die metadata te benader.\
Dit is moontlik om 'n paar **konflikte** te ondervind wanneer jy beide **IAM en toegang skope** gebruik. Byvoorbeeld, jou diensrekening mag die IAM rol van `compute.instanceAdmin` hê, maar die instansie wat jy gecompromitteer het, is beperk met die skopbeperking van `https://www.googleapis.com/auth/compute.readonly`. Dit sal jou verhinder om enige veranderinge te maak met die OAuth token wat outomaties aan jou instansie toegeken word.

Dit is soortgelyk aan **IAM rolle van AWS**. Maar nie soos in AWS nie, kan **enige** diensrekening aan **enige diens** geheg word (dit hoef nie via 'n beleid toegelaat te word nie).

Verskeie van die diensrekeninge wat jy sal vind, is eintlik **outomaties gegenereer deur GCP** wanneer jy 'n diens begin gebruik, soos:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com
```
Dit is egter ook moontlik om **aangepaste diensrekeninge** te skep en aan hulpbronne te koppel, wat soos volg sal lyk:
```
SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com
```
### **Sleutels & Tokens**

Daar is 2 hoof maniere om GCP as 'n diensrekening te benader:

- **Via OAuth tokens**: Dit is tokens wat jy sal ontvang van plekke soos metadata eindpunte of deur http versoeke te steel en hulle is beperk deur die **toegang skope**.
- **Sleutels**: Dit is publieke en private sleutelpare wat jou sal toelaat om versoeke as die diensrekening te teken en selfs OAuth tokens te genereer om aksies as die diensrekening uit te voer. Hierdie sleutels is gevaarlik omdat dit meer ingewikkeld is om te beperk en te beheer, daarom beveel GCP aan om hulle nie te genereer nie.
- Let daarop dat elke keer as 'n SA geskep word, **GCP 'n sleutel vir die diensrekening genereer** wat die gebruiker nie kan toegang nie (en nie in die webtoepassing gelys sal word nie). Volgens [**hierdie draad**](https://www.reddit.com/r/googlecloud/comments/f0ospy/service_account_keys_observations/) word hierdie sleutel **intern deur GCP gebruik** om metadata eindpunte toegang te gee om die toeganklike OAuth tokens te genereer.

### **Toegang skope**

Toegang skope is **aangewend op gegenereerde OAuth tokens** om toegang tot die GCP API eindpunte te verkry. Hulle **beperk die toestemmings** van die OAuth token.\
Dit beteken dat as 'n token aan 'n Eienaar van 'n hulpbron behoort, maar nie die in die token skoop het om daardie hulpbron te benader nie, die token **nie gebruik kan word om (mis)bruik van daardie voorregte te maak nie**.

Google beveel eintlik [aan](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) dat **toegang skope nie gebruik word nie en heeltemal op IAM staatgemaak word**. Die webbestuursportaal handhaaf dit eintlik, maar toegang skope kan steeds op instansies toegepas word deur middel van pasgemaakte diensrekeninge programmaties.

Jy kan sien watter **skope** **toegeken** is deur **te vra:**
```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"
}
```
Die vorige **scopes** is diegene wat **per ongeluk** gegenereer is met **`gcloud`** om toegang tot data te verkry. Dit is omdat wanneer jy **`gcloud`** gebruik, jy eers 'n OAuth-token skep, en dit dan gebruik om die eindpunte te kontak.

Die belangrikste scope van hulle is waarskynlik **`cloud-platform`**, wat basies beteken dat dit moontlik is om **toegang tot enige diens in GCP** te verkry.

Jy kan **'n lys van** [**alle moontlike scopes hier vind**](https://developers.google.com/identity/protocols/googlescopes)**.**

As jy **`gcloud`** blaaierskredensies het, is dit moontlik om **'n token met ander scopes te verkry,** deur iets soos te doen:
```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>"
```
## **Terraform IAM Beleide, Bindings en Lidmaatskappe**

Soos gedefinieer deur 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) gebruik maak van terraform met GCP, is daar verskillende maniere om 'n prinsiep toegang tot 'n hulpbron te gee:

- **Lidmaatskappe**: Jy stel **prinsipes as lede van rolle** **sonder beperkings** oor die rol of die prinsipes. Jy kan 'n gebruiker as 'n lid van 'n rol stel en dan 'n groep as 'n lid van dieselfde rol stel en ook daardie prinsipes (gebruiker en groep) as lede van ander rolle stel.
- **Bindings**: Verskeie **prinsipes kan aan 'n rol gebind word**. Daardie **prinsipes kan steeds aan ander rolle gebind of lede daarvan wees**. As 'n prinsiep wat nie aan die rol gebind is nie, as **lid van 'n gebinde rol** gestel word, sal die volgende keer wanneer die **binding toegepas word, die lidmaatskap verdwyn**.
- **Beleide**: 'n beleid is **geauthoritief**, dit dui rolle en prinsipes aan en dan, **kan daardie prinsipes nie meer rolle hê nie en daardie rolle kan nie meer prinsipes hê nie** tensy daardie beleid gewysig word (nie eers in ander beleide, bindings of lidmaatskappe nie). Daarom, wanneer 'n rol of prinsiep in 'n beleid gespesifiseer word, is al sy voorregte **beperk deur daardie beleid**. Dit kan natuurlik omseil word as die prinsiep die opsie gegee word om die beleid of voorregte-eskalasie toestemmings te wysig (soos om 'n nuwe prinsiep te skep en hom aan 'n nuwe rol te bind).

## Verwysings

- [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}}
