Ako v kóde nastavovať práva na zdroje Azure vyvojárom a ITčkárom.


Služby, ktoré Microsoft Azure ponúka vývojárskym tímom, dokážu pokryť všetky časti aplikačnej architektúry.  Ich paleta je široká a ak sa nad nimi rozbehne viac projektov, ktoré vyvíjajú viacerí vývojári a spravujú viacerí ITčkári, treba dohliadnuť na to, kto a na čo má právo na Azure portále.

Nebudem ospevovať možnosti Azure, ale sa sústredím na “role based access control” (RBAC) pre technických používateľov, čiže na prideľovanie práv pri správe a využívaní Azure. A ak som načal dôležitosť RBAC v viacčlenných tímoch, nebudem plytvať popisom, ako sa to robí cez Azure portál. Nastavenia práv na projektoch, na ktorých sa strieda/účastní viac členov sa vo vývojárskych firmách rieši vlastnou aplikáciou zabudovanou do intranetu s integráciou na ďaľšie monitorovacie systémy. Zjednodušene popísané, projektový manažér pridá do tímu nového vývojára a potrebuje si byť istý, že aj v rámci Azure zdrojov sa bude nováčik pohybovať iba tam, kde sú združené služby využívané jeho projektom. Nebude si môcť v Azure vytvárať, čo ho napadne, nebude “načumovať” do služieb iných projektov, a ani nemysliac na to, že by sa mu pošťastilo zmazať nejaký virtuál iného projektu. Proste, RBAC umožní členov tímu držať len na tom poli, kde majú niečo dopestovať.

Prvé verzie API na správu Azure s označením Azure Service Management pracovali s starším modelom založeným na overovacích certifikátoch. Kto mal taký certifikát sa mohol správať ako administrátor celej Azure subskripcie. A naviac, ak chcel prideliť prístup na Azure portál kolegovi, nemal inú možnosť ako urobiť z neho ďalšieho administrátora s minimálnym oklieštením práv.

Nový model Azure založený na zdrojoch popísateľných šablónami, tzv. Azure Resource Management, využíva skutočnosť, že s každou Azure subskripciou je asociovaná Azure Active Directory (AAD). Ak používateľ (vývojár, IT správca) existuje v tejto AAD, dajú sa mu prideliť granulárne a limitované práva na Azure služby, s čím reálne súvisia aj jeho možnosti správy cez Azure portál (portal.azure.com) a Azure Resource Management API. Nebudem v zvyšnej časti článku popisovať šablóny Azure zdrojov (ARM template). Pohľad na šablóny je výborne popísaný v inom našom blogpost-e. Prenesiem nás do stavu, keď si ARM šablóny už splnili svoju rolu, všetko beží, ale treba nastaviť na bežiace projektové skupiny zdrojov (na Azure portále označované ako “Resource grupy”) práva vývojárom a “systémakom”. A chceme to urobiť vlastnou aplikáciou, v ktorej nepotrebujeme vidieť kompletný obsah “resource grúp”. Potrebujeme vyriešiť základnú úlohu : kto – kam – s akými právami.

 

Prvým úspechom administračnej aplikácie sú správne autorizačné tokeny voči API na správu Azure.

Administračná aplikácia musí mať dostatočné práva na správu cez Azure Resource Management API. Musí teda bežať pod servisným účtom s autorizáciou pre API, ktoré bude volať. Kedže servisný účet pre aplikáciu vytvárate len raz, najjednoduchší spôsob vidím v použití PowerShell-u alebo CLI. Na nasledujúcich riadkoch je príklad v Powershell-e, v ktorom vytvoríte servisný účet aplikácie použitím hesla pre servisný účet a zároveň získate ID aplikácie (ApplicationId) :

Login - AzureRmAccount
get - azuresubscription
$azureAdApplication = New-AzureRMADApplication -DisplayName "<Nazov aplikacie >" -HomePage "https://mojaadapp.com" -IdentifierUris "https://mojaadapp.com"  -Password "<NejakeHesloPreServisnyUcet>"
New-AzureRmADServicePrincipal -ApplicationId $azureAdApplication.ApplicationId
New-AzureRMRoleAssignment -RoleDefinitionName Owner -ServicePrincipalName "https://mojaadapp.com"

“Id” aplikácie a heslo servisného účtu umožnia vašej administračnej aplikácii vytvárať autorizačné tokeny voči Microsoft Graph API a Azure Resource Management API. (Detail kódu nájdete v projekte na github-e v metódach “GetAuthorizationHeader“ a „GetOAuth2Token“ v súbore „Program.cs“.) Autorizačné tokeny voči Microsoft Graph API (získané z „https://graph.windows.net“) a voči Azure Resource Manager API (získané z „https://management.azure.com/“ ) sa odlišujú.

 

API na správu Azure majú rady “guid-y”.

Komplexnejšie API, ktoré identifikujú objekty cez “guid-y” sú svižnejšie. Nečakajte teda, že API na správu Azure podáte informáciu o mene používateľa v AAD a ono mu priradí príslušné práva. Administračné API pri používateľoch pracujú s “ObjectId” používateľa v AAD, roly identifikujú cez “RoleId” a aj skupiny zdrojov, ku ktorým sa majú prideliť práva, sa jednoznačne identifikujú cez “resourceId”. Ak chcete použiť napr. v intranetovej aplikácii zrozumiteľné prideľovanie práv na Azure služby, musíte si z API (Microsoft Graph, Azure Resource Management) dotiahnuť vždy minimálne dvojicu údajov – popisný názov a identifikátor. (Detail kódu nájdete v projekte na github-e v metódach “listAADUsers“ pre získanie zoznamu používateľov z AAD, „listResorceGroupRoles“ pre získanie rolí použiteľných pre „resource group“  v súbore „Program.cs“.)

Prideliť vývojárovi nejaké právo, znamená vziať si jeho “ObjectId”, následne “RoleId” roly, ktorú mu chcete priradiť a vytvoriť z týchto informácií samotné priradenie práv, tzv. “Role Assignment”.  (Opäť sa odkážem na projekt na github-e a konkrétne na metódu “addRBACroleAssignment“ v „Program.cs“.) Ak budete chcieť zbaviť vývojára nejakého práva, musíte mu odobrať príslušné priradenie roly. Buď identifikátor priradenia roly poznáte, alebo si ho nájdete v zozname, ktoré vám poskytne Azure Resource Management API (viď metóda „listResorceGroupRoleAssignments“ v github projekte pre získanie zoznamu priradení, metóda „deleteRBACRoleAssignment“ pre zmazanie vybraného priradenia roly.)

 

Kód na správu RBAC k Azure službám/zdrojom nemusí byť detailista.

Microsoft Graph API a Azure Resource Management API vám na požiadanie vrátia množstvo informácií, ktoré nemajú pre vašu administračnú aplikáciu veľký význam. Lepšie je obratne držať v   aplikácii len potrebné informácie v stručných dátových modeloch. Meno a “ObjectID” pre používateľa z AAD (simplifiedUser.cs v projekte), názov a identifikátor roly pre zoznam rolí (simplifiedRole.cs) , “id” používateľa, “id” roly a “id” priradenia práv  pre zoznam priradení práv (simplifiedRoleAssignment.cs). Kedže REST volania API z Azure vracajú výsledky volaní v JSON formáte, príjemný pomocníkom na ich prekonvertovanie do dátových modelov je JSON Linq.

 

Rekapitulácia.

Zhrňme si ako bežne prebieha pridelenie napr. práva “Contributor” konkrétnej osobe z AAD známej pod meno napr. “mkkm” pre “resource group-u” napr. “rg_moj_projekt”. ( Detailný kód opäť nájdeme v referenčnom github projekte.):

1. Získanie zoznamu používateľov z asociovanej AAD:

obr2b

2. Získanie zoznamu rolí evidovaných v resource group rg_moj_projekt:

obr3

3. Priradenie práva Contributor používateľovi mkkm (volaním metódy “addRBACroleAssignment“ s parametrami, ktoré sme získali v kroku 1. a 2.). Následné overenie priradenia na portal.azure.com na úrovni skupiny zdrojov “rg_moj_projekt”:

obr4b

4. Získanie identifikátora priradenia práva „Contributor“ používateľa „mkkm“ (volaním metódy listResorceGroupRoleAssignments ) pre prípadné odstránenie práv:

obr3b

5.   “Mkkm” sa prihlási na portal.azure.com a vidí iba tú “resource grupu”, do ktorej mu bolo pridelené právo:

obr7

6. “Mkkm” sa neúspešne pokúsi vytvoríť napr. virtuálny server a zadať pritom inú resource grupu ako je jeho “domovská”:

obr6

 

Využitie “role based access control” vám dáva záruku, že každý vývojár a IT správca budú v Azure vidieť len to, čo môžu a dostanú sa len k tým projektovým skupinám Azure zdrojov, v ktorých môžu byť užitoční. V github projekte SetRBAConARMmodel som sa zameral na práva na úrovni skupiny zdrojov. Rovnakým postupom môžete prideľovať práva až na úroveň jedného virtuálneho servera. Projekt bol prvým krokom k inovácii administračného systému pre Azure vývojárskej spoločnosti Millennium, s.r.o., ktorá už viac ako 2 roky kompletne beží v Azure.

 

Miroslav Kubovčík

 

Comments (0)

Skip to main content