GCP - Basic Information
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:
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
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 EnumWatumiaji
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 |
| 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. |
| Kuunda mitandao, subneti, sheria za firewall, na vifaa vya mtandao kama Cloud Router, Cloud VPN, na vipakiaji vya mzigo wa wingu. |
| Kuweka akaunti za malipo na kufuatilia matumizi yao. |
| Kubuni, kuandika programu, na kujaribu programu. |
| 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. |
| Kuunda au kusimamia njia za mwisho hadi mwisho zinazosaidia ujumuishaji na utoaji endelevu, ufuatiliaji, na utoaji wa mfumo. |
| |
| |
| |
| Kufuatilia matumizi ya miradi. Wanachama wa kawaida ni sehemu ya timu ya fedha. |
| Kukagua taarifa za rasilimali katika shirika la Google Cloud. |
| Kukagua usalama wa wingu. |
| Kukagua usanidi wa mtandao. |
| Kuangalia magogo ya ukaguzi. |
| Kusimamia Kituo cha Amri za Usalama. |
| 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/
Hata hivyo, pia inawezekana kuunda na kuambatisha kwenye rasilimali custom service accounts, ambazo zitaonekana kama hii:
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:
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:
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
Last updated