GCP - Basic Information

Support HackTricks

Hierarkia ya Rasilimali

Google Cloud inatumia Hierarkia ya Rasilimali ambayo ni sawa, kidhana, na ile ya mfumo wa faili wa jadi. Hii inatoa mtiririko wa mzazi/mwana na sehemu maalum za kuambatisha sera na ruhusa.

Kwa kiwango cha juu, inaonekana hivi:

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

Mashine pepe (inayoitwa Compute Instance) ni rasilimali. Rasilimali inakaa kwenye mradi, pengine pamoja na Compute Instances zingine, ndoo za kuhifadhi, nk.

Uhamishaji wa Miradi

Inawezekana kuhamisha mradi bila shirika lolote kwenda kwenye shirika lenye ruhusa za roles/resourcemanager.projectCreator na roles/resourcemanager.projectMover. Ikiwa mradi uko ndani ya shirika lingine, inahitajika kuwasiliana na msaada wa GCP ili kuwatoa kwanza kwenye shirika. Kwa maelezo zaidi angalia hii.

Sera za Shirika

Zinaruhusu kuunganisha udhibiti juu ya rasilimali za wingu za shirika lako:

  • Kuunganisha udhibiti wa kuweka vizuizi juu ya jinsi rasilimali za shirika lako zinavyoweza kutumika.

  • Kufafanua na kuanzisha miongozo kwa timu zako za maendeleo kubaki ndani ya mipaka ya kufuata sheria.

  • Kusaidia wamiliki wa miradi na timu zao kusonga haraka bila wasiwasi wa kuvunja sheria za kufuata.

Sera hizi zinaweza kuundwa ili kuathiri shirika lote, folda(s) au mradi(s). Wanaoshuka kutoka kwenye nodi ya uongozi wa rasilimali inayolengwa hurithi sera ya shirika.

Ili kufafanua sera ya shirika, unachagua kizuizi, ambacho ni aina fulani ya kizuizi dhidi ya huduma ya Google Cloud au kundi la huduma za Google Cloud. Unachagua kizuizi hicho na vizuizi unavyotaka.

Matumizi ya kawaida

  • Kuzuia kushiriki rasilimali kulingana na kikoa.

  • Kuzuia matumizi ya akaunti za huduma za Identity and Access Management.

  • Kuzuia eneo la kimwili la rasilimali mpya zilizoundwa.

  • Kuzima uundaji wa akaunti za huduma

Kuna vizuizi vingi zaidi vinavyokupa udhibiti wa kina wa rasilimali za shirika lako. Kwa maelezo zaidi, angalia orodha ya vizuizi vyote vya Huduma ya Sera ya Shirika.

Sera za Shirika za Kawaida

Hizi ni sera ambazo Google itaongeza kwa chaguo-msingi wakati wa kuanzisha shirika lako la GCP:

Sera za Usimamizi wa Ufikiaji

  • Mawasiliano yaliyowekewa vikwazo vya kikoa: Inazuia kuongeza watumiaji kwenye Mawasiliano Muhimu nje ya vikoa ulivyobainisha. Hii inazuia Mawasiliano Muhimu kuruhusu tu vitambulisho vya watumiaji vilivyodhibitiwa katika vikoa ulivyoviteua kupokea arifa za jukwaa.

  • Kushiriki kwa kikoa kilichowekewa vikwazo: Inazuia kuongeza watumiaji kwenye sera za IAM nje ya vikoa ulivyobainisha. Hii inazuia sera za IAM kuruhusu tu vitambulisho vya watumiaji vilivyodhibitiwa katika vikoa ulivyoviteua kufikia rasilimali ndani ya shirika hili.

  • Kuzuia ufikiaji wa umma: Inazuia ndoo za Cloud Storage kufichuliwa kwa umma. Hii inahakikisha kuwa msanidi programu hawezi kusanidi ndoo za Cloud Storage kuwa na ufikiaji wa mtandao usioidhinishwa.

  • Ufikiaji wa kiwango cha ndoo sare: Inazuia orodha za udhibiti wa ufikiaji wa kiwango cha kitu (ACLs) katika ndoo za Cloud Storage. Hii inarahisisha usimamizi wako wa ufikiaji kwa kutumia sera za IAM kwa usawa kwenye vitu vyote katika ndoo za Cloud Storage.

  • Kuhitaji kuingia kwa OS: VMs zilizoundwa katika miradi mipya zitakuwa na OS Login imewezeshwa. Hii inakuwezesha kusimamia ufikiaji wa SSH kwa matukio yako kwa kutumia IAM bila kuhitaji kuunda na kusimamia funguo za SSH za kibinafsi.

Sera za ziada za usalama kwa akaunti za huduma

  • Kuzima ruhusa za IAM za kiotomatiki: Inazuia akaunti za huduma za App Engine na Compute Engine kupewa kiotomatiki jukumu la Mhariri wa IAM kwenye mradi wakati wa uundaji. Hii inahakikisha akaunti za huduma hazipati majukumu ya IAM yenye ruhusa nyingi wakati wa uundaji.

  • Kuzima uundaji wa funguo za akaunti za huduma: Inazuia uundaji wa funguo za akaunti za huduma za umma. Hii husaidia kupunguza hatari ya kufichua vitambulisho vya kudumu.

  • Kuzima upakiaji wa funguo za akaunti za huduma: Inazuia upakiaji wa funguo za akaunti za huduma za umma. Hii husaidia kupunguza hatari ya kufichua au kutumia tena nyenzo za funguo.

Sera za usanidi wa mtandao wa VPC salama

  • Kufafanua IPs za nje zinazokubalika kwa matukio ya VM: Inazuia uundaji wa matukio ya Compute yenye IP ya umma, ambayo inaweza kuyafichua kwa trafiki ya mtandao.

  • Kuzima uhalisia wa VM nested: Inazuia uundaji wa VMs nested kwenye VMs za Compute Engine. Hii inapunguza hatari ya usalama ya kuwa na VMs nested zisizofuatiliwa.

  • Kuzima bandari ya serial ya VM: Inazuia ufikiaji wa bandari ya serial kwa VMs za Compute Engine. Hii inazuia pembejeo kwa bandari ya serial ya seva kwa kutumia Compute Engine API.

  • Kuzuia mitandao iliyoidhinishwa kwenye matukio ya Cloud SQL: Inazuia safu za mtandao wa umma au zisizo za ndani kufikia hifadhidata zako za Cloud SQL.

  • Kuzuia Uhamishaji wa Itifaki kulingana na aina ya Anwani ya IP: Inazuia uhamishaji wa itifaki ya VM kwa anwani za IP za nje.

  • Kuzuia ufikiaji wa IP ya umma kwenye matukio ya Cloud SQL: Inazuia uundaji wa matukio ya Cloud SQL yenye IP ya umma, ambayo inaweza kuyafichua kwa trafiki ya mtandao.

  • Kuzuia kuondolewa kwa lien ya mradi wa VPC iliyoshirikiwa: Inazuia kufutwa kwa bahati mbaya kwa miradi ya mwenyeji wa VPC iliyoshirikiwa.

  • Kuweka mipangilio ya DNS ya ndani kwa miradi mipya kuwa Zonal DNS Pekee: Inazuia matumizi ya mipangilio ya zamani ya DNS ambayo ina upatikanaji mdogo wa huduma.

  • Kuruka uundaji wa mtandao wa chaguo-msingi: Inazuia uundaji wa kiotomatiki wa mtandao wa VPC wa chaguo-msingi na rasilimali zinazohusiana. Hii huepuka sheria za firewall za chaguo-msingi zenye ruhusa nyingi.

  • Kuzima matumizi ya IPv6 ya nje ya VPC: Inazuia uundaji wa subnet za nje za IPv6, ambazo zinaweza kufichuliwa kwa ufikiaji wa mtandao usioidhinishwa.

IAM Roles

Hizi ni kama sera za IAM katika AWS kwani kila jukumu lina seti ya ruhusa.

Hata hivyo, tofauti na AWS, hakuna repo ya kati ya majukumu. Badala yake, rasilimali zinatoa X majukumu ya ufikiaji kwa Y principals, na njia pekee ya kujua nani ana ufikiaji wa rasilimali ni kutumia get-iam-policy method juu ya rasilimali hiyo. Hii inaweza kuwa tatizo kwa sababu hii inamaanisha njia pekee ya kujua ni ruhusa gani principal anazo ni kuuliza kila rasilimali inampa nani ruhusa, na mtumiaji anaweza asiwe na ruhusa za kupata ruhusa kutoka kwa rasilimali zote.

Kuna aina tatu za majukumu katika IAM:

  • Majukumu ya Msingi/Primitive, ambayo yanajumuisha majukumu ya Owner, Editor, na Viewer yaliyokuwepo kabla ya kuanzishwa kwa IAM.

  • Majukumu yaliyofafanuliwa awali, ambayo yanatoa ufikiaji wa kina kwa huduma maalum na yanadhibitiwa na Google Cloud. Kuna majukumu mengi yaliyofafanuliwa awali, unaweza kuona yote na ruhusa walizonazo hapa.

  • Majukumu maalum, ambayo yanatoa ufikiaji wa kina kulingana na orodha ya ruhusa iliyobainishwa na mtumiaji.

Kuna maelfu ya ruhusa katika GCP. Ili kuangalia kama jukumu lina ruhusa unaweza kutafuta ruhusa hapa na kuona ni majukumu gani yanayo.

Unaweza pia kutafuta hapa majukumu yaliyofafanuliwa awali yanayotolewa na kila bidhaa. Kumbuka kuwa baadhi ya majukumu hayawezi kuambatanishwa kwa watumiaji na ni kwa SAs pekee kwa sababu ya ruhusa fulani wanazozihusisha. Zaidi ya hayo, kumbuka kuwa ruhusa zitachukua athari tu ikiwa zimeambatanishwa kwa huduma husika.

Au angalia kama jukumu maalum linaweza kutumia ruhusa maalum hapa.

GCP - IAM, Principals & Org Policies Enum

Watumiaji

Katika GCP console hakuna usimamizi wa Watumiaji au Vikundi, hiyo inafanywa katika Google Workspace. Ingawa unaweza kusawazisha mtoa kitambulisho tofauti katika Google Workspace.

Unaweza kufikia watumiaji na vikundi vya Workspaces katika https://admin.google.com.

MFA inaweza kulazimishwa kwa watumiaji wa Workspaces, hata hivyo, mshambuliaji anaweza kutumia tokeni kufikia GCP kupitia cli ambayo haitalindwa na MFA (italindwa na MFA tu wakati mtumiaji anapoingia ili kuizalisha: gcloud auth login).

Vikundi

Wakati shirika linaundwa vikundi kadhaa vinapendekezwa sana kuundwa. Ikiwa unasimamia yoyote kati yao unaweza kuwa umedhibiti shirika lote au sehemu muhimu ya shirika:

Kikundi

Kazi

gcp-organization-admins (kikundi au akaunti za kibinafsi zinazohitajika kwa orodha ya ukaguzi)

Kusimamia rasilimali yoyote inayomilikiwa na shirika. Peana jukumu hili kwa uangalifu; wasimamizi wa shirika wana ufikiaji wa rasilimali zote za Google Cloud. Vinginevyo, kwa sababu kazi hii ina ruhusa nyingi, fikiria kutumia akaunti za kibinafsi badala ya kuunda kikundi.

gcp-network-admins (inayohitajika kwa orodha ya ukaguzi)

Kuunda mitandao, subneti, sheria za firewall, na vifaa vya mtandao kama Cloud Router, Cloud VPN, na vipakiaji vya mzigo wa wingu.

gcp-billing-admins (inayohitajika kwa orodha ya ukaguzi)

Kuweka akaunti za malipo na kufuatilia matumizi yao.

gcp-developers (inayohitajika kwa orodha ya ukaguzi)

Kubuni, kuandika programu, na kujaribu programu.

gcp-security-admins

Kuweka na kusimamia sera za usalama kwa shirika lote, ikiwa ni pamoja na usimamizi wa ufikiaji na sera za vizuizi vya shirika. Angalia mwongozo wa misingi ya usalama wa Google Cloud kwa maelezo zaidi kuhusu kupanga miundombinu yako ya usalama ya Google Cloud.

gcp-devops

Kuunda au kusimamia njia za mwisho hadi mwisho zinazosaidia ujumuishaji na utoaji endelevu, ufuatiliaji, na utoaji wa mfumo.

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (sio tena kwa chaguo-msingi)

Kufuatilia matumizi ya miradi. Wanachama wa kawaida ni sehemu ya timu ya fedha.

gcp-platform-viewer (sio tena kwa chaguo-msingi)

Kukagua taarifa za rasilimali katika shirika la Google Cloud.

gcp-security-reviewer (sio tena kwa chaguo-msingi)

Kukagua usalama wa wingu.

gcp-network-viewer (sio tena kwa chaguo-msingi)

Kukagua usanidi wa mtandao.

grp-gcp-audit-viewer (sio tena kwa chaguo-msingi)

Kuangalia magogo ya ukaguzi.

gcp-scc-admin (sio tena kwa chaguo-msingi)

Kusimamia Kituo cha Amri za Usalama.

gcp-secrets-admin (sio tena kwa chaguo-msingi)

Kusimamia siri katika Secret Manager.

Sera ya Nenosiri ya Kawaida

  • Kulazimisha nywila zenye nguvu

  • Kati ya herufi 8 na 100

  • Hakuna matumizi tena

  • Hakuna muda wa kuisha

  • Ikiwa watu wanapata Workspace kupitia mtoa huduma wa tatu, mahitaji haya hayatumiki.

Akaunti za huduma

Hizi ni principals ambazo rasilimali zinaweza kuwa nazo zilizounganishwa na ufikiaji wa kuingiliana kwa urahisi na GCP. Kwa mfano, inawezekana kufikia tokeni ya uthibitisho ya Akaunti ya Huduma iliyowekwa kwenye VM katika metadata. Inawezekana kukutana na migogoro wakati wa kutumia IAM na access scopes. Kwa mfano, akaunti yako ya huduma inaweza kuwa na jukumu la IAM la compute.instanceAdmin lakini tukio ulilovamia limewekewa kikomo na upeo wa `https://www.googleapis.com/auth/

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

Hata hivyo, pia inawezekana kuunda na kuambatisha kwenye rasilimali custom service accounts, ambazo zitaonekana kama hii:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Access scopes

Access scope ni ambatanishwa na tokeni za OAuth zilizotengenezwa ili kufikia ncha za API za GCP. Zinazuia ruhusa za tokeni za OAuth. Hii inamaanisha kwamba ikiwa tokeni ni ya Mmiliki wa rasilimali lakini haina katika upeo wa tokeni kufikia rasilimali hiyo, tokeni haiwezi kutumika (ab)kutumia haki hizo.

Google kwa kweli inapendekeza kwamba access scopes zisitumike na kutegemea kabisa IAM. Portal ya usimamizi wa wavuti kwa kweli inatekeleza hili, lakini access scopes bado zinaweza kutumika kwa instances kwa kutumia custom service accounts kwa njia ya programu.

Unaweza kuona ni scopes gani zimekuwa assigned kwa kuuliza:

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

Scopes zilizotangulia ni zile zinazozalishwa kwa default kwa kutumia gcloud kufikia data. Hii ni kwa sababu unapotumia gcloud kwanza unaunda token ya OAuth, kisha kuitumia kuwasiliana na endpoints.

Scope muhimu zaidi kati ya hizo ni cloud-platform, ambayo kimsingi inamaanisha kwamba inawezekana kufikia huduma yoyote katika GCP.

Unaweza kupata orodha ya scopes zote zinazowezekana hapa.

Kama una gcloud browser credentials, inawezekana kupata token na scopes nyingine, kwa kufanya kitu kama:

# 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 Policies, Bindings and Memberships

Kama ilivyofafanuliwa na terraform katika https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam kutumia terraform na GCP kuna njia tofauti za kumpa principal ufikiaji wa rasilimali:

  • Memberships: Unaweka principals kama wanachama wa roles bila vikwazo juu ya role au principals. Unaweza kumweka mtumiaji kama mwanachama wa role na kisha kuweka kikundi kama mwanachama wa role hiyo hiyo na pia kuweka hao principals (mtumiaji na kikundi) kama wanachama wa roles nyingine.

  • Bindings: Kadhaa principals wanaweza kufungamanishwa na role. Hao principals bado wanaweza kufungamanishwa au kuwa wanachama wa roles nyingine. Hata hivyo, ikiwa principal ambaye hajafungamanishwa na role amewekwa kama mwanachama wa role iliyofungamanishwa, wakati ujao binding inapowekwa, uanachama utatoweka.

  • Policies: Sera ni mamlaka, inaonyesha roles na principals na kisha, hao principals hawawezi kuwa na roles zaidi na hizo roles haziwezi kuwa na principals zaidi isipokuwa sera hiyo ibadilishwe (hata katika sera nyingine, bindings au memberships). Kwa hivyo, wakati role au principal inapotajwa katika sera, haki zake zote ni zimepunguzwa na sera hiyo. Ni wazi, hii inaweza kupitishwa ikiwa principal amepewa chaguo la kubadilisha sera au ruhusa za kupandisha haki (kama kuunda principal mpya na kumfungamanisha na role mpya).

Marejeleo

Support HackTricks

Last updated