Cloud üzemeltetés ügyfél számára

Projektek általános

Milyen módon illik egyfajta service provider-ként az ügyfél tulajdonában lévő cloud környezetet üzemeltetni?

Jelenleg mindhárom nagy cloud-ban vannak saját dolgaink, emellett vannak szintén saját szolgáltatások, amiket ügyfelek számára üzemeltetünk. Ezek az adott cloud-ra jellemző legalsó szintű objektumok a mi saját struktúránkban, pl. AWS esetén a mi root accountunk alatt van egy ügyfelek OU és ebben minden ügyfélnek 1-1 account. Nekik ide semmi közük üzemeltetés szempontból, ha használni akarják az itt lévő szolgáltatásukat, akkor a saját környezetükből (ami vagy cloud vagy DC vagy valami branch office) valahogy - több támogatott opció is van - becsattannak ide hálózaton.

Most felmerült az, hogy az ügyfél meglévő környezetébe tegyünk le dolgokat, és erre keresek valami well-architected framework-öt, de csak Azure-hoz találtam (Lighthouse) ajánlásokat identity és account management-re valamit access control-ra.

Hogyak kell ezt jól csinálni AWS-ben/GCP-ben? IAM/RBAC és ennyi, nincs más? Az Azure Lighthouse jó?

Köszi.

  • 481 megtekintés

( Tassadar v | 2022. 05. 10., k – 14:04 )

Szerkesztve: 2022. 05. 10., k – 14:06

Én átadnám az erőforrást létrehozó kódot, hozzák létre ők - akár CI/CD Pipeline-ban.

Köszi. Cloud-native CI/CD-vel nincs tapasztalatom, csak on-prem GitLab-al és Jenkins-el, szóval hogyan tud ez a megoldás skálázható identity és access management-et nyújtani? Más szavakkal én nem egy tool-t keresek, ami valahogy lerakja a cuccot az ügyfél környezetébe (az van), hanem jogosultság és hozzáférés kezelést, valamint account management-et.

( fdeyso | 2022. 05. 10., k – 20:00 )

Az Azure lighthouse lehet overkill. Az ugyfel Azurejaban letrehoz egy resource groupot amihez hozzaadjak a ti fiokotokat(ez lehet a sajat fiokod guest-kent meghivva, vagy a sajat tenantben egy fiok) contributornak (de eleg csak contributor eligible, aztan PIM el lehet contributorkodni amikor kell, amugy meg csak reader role). GYK a lighthouse csak egy overkill framework ami a PIMen alapul meg egy automata report. (elnezest kerek az angol kifejezesekert de sose hasznaltam meg Azure-t magyarul)

( Mik v | 2022. 05. 10., k – 21:20 )

Hát, ezt a kedves ügyfélnek illene tudni. AWShez van központi management de az inkább enterprise cucc és lehet nem egyszerűbb mint az IAM.

IAM pont erre is való. Bonyolultabb esetben ember legyen aki beállítja, de ezt ugye az ügyfélnek illene megoldani. Mondjuk abban tudsz segíteni, hogy kikeresed, hogy neked mi kell esetleg tagekkel játszani...

Nálunk körberöhögnének már az ötlet hallatán is. Egy kivétel van: pentest. Ők egy köztes accounton ("jumphost") keresztül be tudnak jönni időkorlátosan, irányítottan. A control mindig nálunk van. Mi van ha a cégetek compromittálódik? Az összes ügyfél mindenféle vackához szabad lesz a bejárás? 

Jogos kérdések, de pont ennek a minimalizálását várnám egy ilyen feature-től. Számtalan service provider kínál managelt cloud-ot és gondolom valahogy ők is megoldják ezt (vagy ez is csak kamu mint a cloud témakörök fele :D).

  • auditált identity management nálunk
  • principle of least privilege - olyan policy amivel csak azt tudom csinálni az ügyfél account-ban, amire szerződtünk
  • IP alapon szűrés honnan jöhet API call (IAM ezt pont tudja), erre a jump host-ra rendszeres audit, a jump host ügyfél sepcifikus
  • attribute based access control ahol törölni/módosítani csak olyan objektumot tudok, amin az én tag-em van (tehát én hoztam létre)

Úgy látom válaszok alapján IAM lehet a megoldás, mert Lighthouse-hoz hasonló nincs az AWS/GCP-ben. Beszélek ügyfél security embereivel és ha ők sem tudnak jobbat, akkor marad IAM + RBAC/ABAC.

( gabrielakos v | 2022. 05. 10., k – 23:25 )

Ha az ügyfélnek van organization-je akkor csinálhatna pl plusz egy accountot nektek és onnantól egyrészt ő megmondhatja hogy az accountban mi hogy lehet, másrészt accounton belül nektek az lehet pont ugyanolyan mint a sajátotok most.

https://aws.amazon.com/organizations/faqs/

IAM policy-k segítségével lehet accountokon átnyúló dolgokat is csinálni, de ez már elég spéci (és szopó) terület, én se ismerem.

Az is szolgáltatása válogatja h accounton átnyúlóan mit lehet -  és az mennyire bugos :)

Két független account között is lehet átjárásokat csinálni de organization-ön belüli két account között valahogy magától értetődőbb. 
Nem tudom h van-e konkrétan eltérés.

zászló, zászló, szív