GCP - Osnovne informacije

Reading time: 15 minutes

Hijerarhija resursa

Google Cloud koristi Hijerarhiju resursa koja je konceptualno slična tradicionalnom fajl sistemu. Ovo pruža logički radni tok roditelj/dete sa specifičnim tačkama vezivanja za politike i dozvole.

Na visokom nivou, izgleda ovako:

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

A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.

Migracija projekata

Moguće je migrirati projekat bez organizacije u organizaciju sa dozvolama roles/resourcemanager.projectCreator i roles/resourcemanager.projectMover. Ako je projekat unutar druge organizacije, potrebno je kontaktirati GCP podršku da prvo presele projekat iz organizacije. Za više informacija pogledajte ovo.

Politike organizacije

Omogućavaju centralizaciju kontrole nad resursima vaše organizacije u oblaku:

• Centralizujte kontrolu da konfigurišete ograničenja o tome kako se resursi vaše organizacije mogu koristiti.
• Definišite i uspostavite ograničenja za vaše razvojne timove kako bi ostali unutar granica usklađenosti.
• Pomoć vlasnicima projekata i njihovim timovima da brzo deluju bez brige o kršenju usklađenosti.

Ove politike mogu biti kreirane da uticaju na celu organizaciju, folder(e) ili projekat(e). Potomci ciljanog čvora hijerarhije resursa nasleđuju politiku organizacije.

Da biste definisali politiku organizacije, birate ograničenje, što je određena vrsta ograničenja prema Google Cloud usluzi ili grupi Google Cloud usluga. Konfigurišete to ograničenje sa željenim ograničenjima.

Uobičajeni slučajevi korišćenja

• Ograničite deljenje resursa na osnovu domena.
• Ograničite korišćenje naloga za upravljanje identitetom i pristupom.
• Ograničite fizičku lokaciju novokreiranih resursa.
• Onemogućite kreiranje naloga za usluge.

Postoji mnogo drugih ograničenja koja vam daju preciznu kontrolu nad resursima vaše organizacije. Za više informacija, pogledajte spisak svih ograničenja politike organizacije.

Podrazumevane politike organizacije

IAM Uloge

Ove su slične IAM politikama u AWS-u jer svaka uloga sadrži skup dozvola.

Međutim, za razliku od AWS-a, ne postoji centralizovani repozitorij uloga. Umesto toga, resursi daju X pristupne uloge Y principima, a jedini način da saznate ko ima pristup resursu je korišćenje get-iam-policy metode nad tim resursom.
To može biti problem jer to znači da je jedini način da saznate koje dozvole ima princip da pitate svaki resurs kome dodeljuje dozvole, a korisnik možda neće imati dozvole da dobije dozvole od svih resursa.

Postoje tri tipa uloga u IAM:

• Osnovne/Primitivne uloge, koje uključuju Vlasnika, Urednika i Gledaoca uloge koje su postojale pre uvođenja IAM-a.
• Predefinisane uloge, koje pružaju granularan pristup za određenu uslugu i kojima upravlja Google Cloud. Postoji mnogo predefinisanih uloga, možete videti sve njih sa privilegijama koje imaju ovde.
• Prilagođene uloge, koje pružaju granularan pristup prema listi dozvola koju je odredio korisnik.

Postoje hiljade dozvola u GCP-u. Da biste proverili da li uloga ima dozvolu, možete pretražiti dozvolu ovde i videti koje uloge je imaju.

Takođe možete pretražiti ovde predefinisane uloge koje nudi svaki proizvod. Imajte na umu da neke uloge ne mogu biti dodeljene korisnicima i samo SA-ima zbog nekih dozvola koje sadrže.
Pored toga, imajte na umu da će dozvole imati efekat samo ako su priključene relevantnoj usluzi.

Ili proverite da li prilagođena uloga može koristiti određenu dozvolu ovde.

GCP - IAM, Principals & Org Policies Enum

Korisnici

U GCP konzoli ne postoji upravljanje Korisnicima ili Grupama, to se obavlja u Google Workspace. Iako možete sinhronizovati različitog provajdera identiteta u Google Workspace.

Možete pristupiti korisnicima i grupama Workspaces na https://admin.google.com.

MFA može biti prinudna za korisnike Workspaces, međutim, napadač može koristiti token za pristup GCP putem CLI-a koji neće biti zaštićen MFA (biće zaštićen MFA samo kada se korisnik prijavi da ga generiše: gcloud auth login).

Grupe

Kada se organizacija kreira, nekoliko grupa je snažno preporučeno da se kreiraju. Ako upravljate bilo kojom od njih, mogli ste kompromitovati sve ili važan deo organizacije:

Podrazumevana politika lozinki

• Sprovodite jake lozinke
• Između 8 i 100 karaktera
• Bez ponovne upotrebe
• Bez isteka
• Ako ljudi pristupaju Workspace-u putem treće strane, ovi zahtevi se ne primenjuju.

Nalozi za usluge

Ovo su principi koje resursi mogu imati priključene i pristupiti kako bi lako interagovali sa GCP-om. Na primer, moguće je pristupiti auth tokenu naloga za usluge priključenom VM-u u metapodacima.
Moguće je naići na neke sukobe kada koristite i IAM i pristupne opsege. Na primer, vaš nalog za usluge može imati IAM ulogu compute.instanceAdmin, ali instanca koju ste kompromitovali ima ograničenje opsega https://www.googleapis.com/auth/compute.readonly. Ovo bi vam onemogućilo da napravite bilo kakve promene koristeći OAuth token koji je automatski dodeljen vašoj instanci.

Slično je IAM ulogama iz AWS-a. Ali ne kao u AWS-u, bilo koji nalog za usluge može biti priključen bilo kojoj usluzi (ne mora to da dozvoli putem politike).

Nekoliko naloga za usluge koje ćete pronaći su zapravo automatski generisani od strane GCP-a kada počnete da koristite uslugu, kao:

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

Međutim, takođe je moguće kreirati i povezati se sa resursima custom service accounts, koji će izgledati ovako:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Ključevi i Tokeni

Postoje 2 glavna načina za pristup GCP kao servisni nalog:

• Putem OAuth tokena: Ovo su tokeni koje ćete dobiti sa mesta kao što su metapodaci ili krađom http zahteva i ograničeni su opsegom pristupa.
• Ključevi: Ovo su javni i privatni parovi ključeva koji će vam omogućiti da potpišete zahteve kao servisni nalog i čak generišete OAuth tokene za izvršavanje akcija kao servisni nalog. Ovi ključevi su opasni jer ih je teže ograničiti i kontrolisati, zato GCP preporučuje da ih ne generišete.
• Imajte na umu da svaki put kada se kreira SA, GCP generiše ključ za servisni nalog kojem korisnik ne može pristupiti (i neće biti naveden u web aplikaciji). Prema ovoj temi ovaj ključ je interno korišćen od strane GCP da omogući metapodacima pristup za generisanje dostupnih OAuth tokena.

Opsezi pristupa

Opsezi pristupa su priključeni generisanim OAuth tokenima za pristup GCP API krajnjim tačkama. Oni ograničavaju dozvole OAuth tokena.
To znači da ako token pripada vlasniku resursa, ali nema u opsegu tokena pristup tom resursu, token ne može biti korišćen za (zlo)upotrebu tih privilegija.

Google zapravo preporučuje da se opsezi pristupa ne koriste i da se potpuno oslanjaju na IAM. Web portal za upravljanje zapravo to sprovodi, ali opsezi pristupa se i dalje mogu primeniti na instance koristeći prilagođene servisne naloge programatski.

Možete videti koji su opsezi dodeljeni upitom:

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

Prethodni opsezi su oni generisani podrazumevano koristeći gcloud za pristup podacima. To je zato što kada koristite gcloud prvo kreirate OAuth token, a zatim ga koristite za kontaktiranje krajnjih tačaka.

Najvažniji opseg od tih potencijalno je cloud-platform, što u osnovi znači da je moguće pristupiti bilo kojoj usluzi u GCP.

Možete pronaći listu svih mogućih opsega ovde.

Ako imate gcloud kredencijale za pretraživač, moguće je dobiti token sa drugim opsezima, radeći nešto poput:

# 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 Politike, Povezivanja i Članstva

Kao što je definisano od strane terraform-a u https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam, korišćenjem terraform-a sa GCP postoje različiti načini za dodeljivanje pristupa principalu nad resursom:

• Članstva: Postavljate principale kao članove uloga bez ograničenja nad ulogom ili principima. Možete staviti korisnika kao člana uloge, a zatim staviti grupu kao člana iste uloge i takođe postaviti te principe (korisnika i grupu) kao članove drugih uloga.
• Povezivanja: Nekoliko principala može biti povezano sa ulogom. Ti principali mogu i dalje biti povezani ili članovi drugih uloga. Međutim, ako je principal koji nije povezan sa ulogom postavljen kao član povezane uloge, sledeći put kada se povezivanje primeni, članstvo će nestati.
• Politike: Politika je autoritativna, ukazuje na uloge i principe i tada, ti principi ne mogu imati više uloga i te uloge ne mogu imati više principa osim ako ta politika nije izmenjena (čak ni u drugim politikama, povezivanjima ili članstvima). Stoga, kada je uloga ili principal specificiran u politici, sve njegove privilegije su ograničene tom politikom. Očigledno, ovo se može zaobići u slučaju da principal dobije opciju da izmeni politiku ili dozvole za eskalaciju privilegija (kao što je kreiranje novog principala i povezivanje sa novom ulogom).

Reference

• 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