Jste enterprise firma a myslíte to s cloudem vážně? Pak určitě budete chtít dobře řídit governance - kdo co smí, co komu patří, jaké politiky se mají vynutit, jak si rozdělit práci, jak řídit náklady. V tomto seriálu se na to zaměříme.
Dnes se podíváme na jemné řízení přístupu k zdrojům v Azure a také na vytváření provozních politik.
Detailní demo k dnešnímu tématu najdete na mém GitHubu zde: https://github.com/tkubica12/azure-policy-rbac-demo
Role-based-access-control vs. Azure Policy
Nejprve se vysvětleme to, co mají administrátoři zprvu problém odlišit. RBAC vs. provozní politika. Důležitá zpráva na začátek - obě se implementují na nízkoúrovňových přístupech (API resp. ARM), čili fungují pro všechny typy přístupu - portál, CLI, PowerShell, ARM šablona, SDK, Ansible či Terraform.
Role based access control je o tom, co který uživatel smí dělat. Funguje to na úrovni API, tedy jakou část stromu prostředků a akcí nad nimi smí využívat. Každá akce v Azure (API volání) je vlastně něco jako URL cesta začínající providerem (například Compute, Storage, Networking), následuje identifikací subscription, pak resource group, pak samotného zdroje a nakonec je akce (start, stop, ...). Na této úrovni lze tedy přístup řídit velmi jemně.
RBAC tedy znamená, že řeknete které subscriptions, resource groups nebo jednotlivé zdroje uživatel vidí, do kterých může i zapisovat a jaké akce s nimi může provádět.
Azure Policy je něco jiného, je to o definici pravidel pro práci se zdroji, které musí všichni uživatelé ctít. Funguje na úrovni ARM a můžete v politice reagovat na přítomnost určitých políček v ARM šabloně a omezit jejich hodnoty. Lze tak například v subscription omezit možnosti používání diskových obrazů jen na ty, které vytvořila a schválila securita. Nebo dokážete vynutit přítomnost metadat, tedy tagování zdrojů tak, že musí obsahovat třeba kontaktní osobu, typ prostředí nebo kategorii zpracovávaných dat. Dá se také uzamknout virtuální stroje v nějaké resource group do konkrétního subnetu a zabránit tak přemostění připravených síťařských pravidel a zařízení.
Azure Policy definuje provozní pravidla platná pro všechny zdroje, ke kterým jsou přiřazena (třeba Resource Group) bez ohledu na to, kdo je uživatel. Tato pravidla řeší nejen co, ale i jak, protože vidí do obsahu akcí (například jaký konkrétně subnet se uživatel snaží přiřadit ke své VM).
RBAC v Azure
Pokud si vystačíte se zabudovanými rolemi můžete tohle všechno provádět přímo v portálu. U každého zdroje či Resource Group najdete panel Access Control (IAM).
Můžete přiřazovat klasické identity (uživatelské účty či skupiny například nasynchronizované z vašeho Active Directory), ale také service principály (servisní účty). Je tu ještě jedna zajímavá možnost a to je automatické vytvoření účtu pro virtuální mašinu (Managed Service Identity). Účet je automaticky založen a zevnitř VM jste schopni ho použít (s využitím API na localhost), přesto to není tak, že máte uvnitř VM přímý přístup k jménu a heslu. To je velmi zajímavé a zevnitř VM tak můžete například dealokovat sebe sama, požádat VM Scale Set o vytvoření dalších kolegů, ovládat zdroje v Azure či využít tuto identitu na přístupu do Azure SQL.
A to není všechno - v Azure lze využít Privileged Identity Management. Ten vám umožní nastavit proces kolem elevace práv. Například váš kontraktor má pouze monitorovací práva, ale čas od času mu pro řešení incidentu potřebujete dát práva zapisovací. V PIM je celý proces jak o elevaci práv zažádat, je tam mechanismus schvalování a navýšení práv může být časově omezeno.
Daleko víc podrobností o RBAC najdete v mém demu: https://github.com/tkubica12/azure-policy-rbac-demo/blob/master/docs/rbac.md
Azure Policy
Jak už jsem vysvětloval, politika funguje na úrovni kontroly parametrů v ARM engine, tedy umožňuje řešit i "jak". Nejen tedy povolit určitou akci (například vytvoření VM), ale i kontrolovat parametry tohoto objektu - má tagy? Nemá přiřazenou public IP na síťovce? Je ve vámi povolené virtuální síti a subnetu? Používá pouze vaše korporátní schválené diskové obrazy?
Podstatné tedy je, že politika se týká zdrojů v rámci scope (Resource Group, subscription nebo skupina subscription) bez ohledu na to, kdo je uživatel. Dokážete tak zajistit, aby nedošlo k nechtěným konfiguracím (například omylem), které by třeba kompromitovaly bezpečnost (obejítí síťové ochrany, zdroje bez firewallu, přímý přístup do Internetu místo průchodu WAFkou, použití nekorporátních diskových obrazů) nebo narušovaly administrativní procesy (chybějící kontaktní informace, nesprávné zařazení do nákladového střediska, neoznačení typu prostředí dev/test/prod).
Nově můžete použít GUI.
Prohlédněte si zabudované definice politik, jejich počet se neustále rozšiřuje.
Takhle vypadá definice vlastního pravidla.
Jednotlivá pravidla pak přiřadíte k Subscription či Resource Group. Existuje zákadní Azure Policy zdarma, která se hodí na vynucení pravidel. Máte ale také možnost pořídit si lepší (placenou) variantu, která navíc umí auditní režim. Politika tedy není natvrdo vynucena (můžete zdroje založit i pokud pravidla nedodržíte), ale systém to sleduje a reportuje všechny situace, které neodpovídají pravidlům.
To je ideální režim například pro existující už vytvořené zdroje nebo pro situace, kdy zpočátku nemáte jasnou představu o potřebách daného týmu a příliš restriktivní řešení do začátku by je nadměrně omezovalo. Přes auditní reporty následně zjistíte kde se tým odchýlil a můžete s nimi diskutovat zda je to nutné či se dají věci dělat jinak.
Azure Policy je velmi mocný nástroj - podrobnosti najdete v mém demu zde: https://github.com/tkubica12/azure-policy-rbac-demo/blob/master/docs/policy.md
Jak vidíte Azure vám umožňuje nasadit dobrou governance nad celým prostředím. Dnes jsme si ukázali jemné řízení přístupu a vynucení provozních politik. V příštích dílech se podíváme na další aspekty jako je návrh subscription, virtuální datové centrum či Azure Security Center.