Tagování v cloudu: jak z něj vytěžit maximum

Na tagování záleží! Které tagy ale dávají smysl a jak z jejich používání v cloudu vytěžit maximum?

Kamil Kovář

Tagování prostředků v cloudu vypadá jako ta nejjednodušší disciplína. Cloud nás nesvazuje – můžeme si pojmenovat tag (neboli značku), jak se nám zachce, a dát mu jakoukoli hodnotu, která nás napadne. Nemusíme tag použít vůbec, anebo se můžeme vyžívat a „olepit“ každý prostředek, každý virtuální stroj, sítě, databáze, load balancery nebo kontejnery spoustou „papírků“. Které tagy ale dávají smysl? Ukažme si, jakou strategii zvolit, abychom tuto funkcionalitu maximálně využili.

Co jsou tagy a proč je používáme?

Tagy, správně česky značky, jsou štítky, cedulky nebo chcete-li nálepky, kterými si polepujeme naše cloudové prostředky. Štítkujeme si virtuální stroje, databáze, virtuální sítě, load balancery, polepujeme si zkrátka všechno. Tagy nám pomáhají rozlišovat, ale i seskupovat, tj. organizovat, cloudové prostředky a zdroje.

Vnímáme-li cloudový prostředek jako konfigurační položku naší konfigurační databáze (CMDB), jsou tagy metadata vlastností. Například si označíme, zda je systém produkční, nebo testovací.

A na co jsou dobré? Díky tagům můžeme s prostředky hromadně pracovat, mazat, upravovat, optimalizovat, přiřazovat politiky, licencovat a hlavně automatizovat. Usnadňují nám práci.

Tag se vždy skládá ze dvou částí. První je jeho jméno, které si můžeme libovolně volit. Příkladem budiž „Prostředí“. K tagu napíšu jeho hodnotu, v tomto příkladě „Produkční“. Pokud ale kolega druhý den vytvoří další virtuální stroj a přidá k němu tag „Environment“ s hodnotou „Production“ a další kolega „Env“ o hodnotě “TST“, budou mít štítky na prostředcích velmi malou hodnotu.

Syntaxe

Základem budoucího uspořádání tagů je stanovení syntaxe a její přísné dodržování. Syntaxe by měla mít podobně závazná pravidla jako samotné přidělování názvů prostředkům. Tagy a jejich hodnoty jsou case sensitive, mohou být předávány různými skripty a nástroji. Proto je vhodné vyhýbat se mezerám, diakritice a zvláštním znakům. Nejlepším řešením je mít pro maximum tagů pevné číselníky shodné s konfigurační databází. Například pro prostředí bude stanoveno „Dev, Test, Pre-prod, Prod“.

Povinné i nepovinné

Tagy mohou být povinné, podmínečně povinné a nepovinné.

Povinné tagy, jako například vlastník objektu, musí být vyplněné vždy. Jejich absence může totiž vést k závažným problémům v poskytování služeb nebo v jejich vyhodnocování.

Podmínečně povinné tagy jsou potřebné pro správný technický provoz, například ke stanovení bezpečnostní politiky anebo způsobu zálohování.

Nepovinné tagy jsou orientační, nahrazují například dohledávání informací v CMDB nebo jiných zdrojích informací, když je možné je vidět přímo v UI nebo zobrazit v příkazovém řádku. Integrace tagování s firemní konfigurační databází je obecně preferovanou variantou pro všechna větší prostředí, ať ji realizujeme obousměrně nebo jedním směrem.

Automaticky je lepší než ručně

Abychom zajistili přítomnost povinných tagů, je vhodné tyto vložit jako proměnné parametry skriptů v AWS Cloud Formation, ARM templatech, Terraform skriptech apod. To obvykle zajistí pokrytí pro všechny technické údaje pro daný prostředek nebo celý stack.

Stejně automatizovaně dále kontrolujeme přítomnost povinných tagů nástroji jako AWS Config nebo skrze Azure Policy.

Správným přístupem je dědění některých tagů ze skupiny prostředků (resource group). Například značka jména aplikace nebo vlastníka je obvykle společná pro celou skupinu. To usnadňuje celou práci a zajišťuje konzistenci tagů díky politikám zobrazujícím compliance stav a vestavěným nápravným opatřením, která automaticky chybějící tagy doplní ze skupiny prostředků.

Při správné implementaci ITSM postupu při žádosti o vytvoření prostředku nebo celého prostředí by mělo být vyžadováno úplné vyplnění budoucích prostředků v žádosti anebo zkopírování jejich vlastností z již existujícího prostředí. Automatizační proces pak vytvoří všechny tagy, které jsou potřeba pro správnou organizaci prostředků – businessové a hlavně bezpečnostní.

Množství tagů na jednom prostředku je pro AWS i Azure stanoveno na přibližně 50 položek, proto při integraci s konfigurační databází je třeba opatrně některé položky mapovat a rozhodovat, zda potřebujeme všechna data v obou zdrojích.

Kdo může měnit a měl by?

Není možné stanovit tag jako mandatorní a nechat jej nevyplněný. Tento stav, který může vytvořit „rogue“ prostředek, je dobré automaticky prověřovat. Politiky rovněž umožňují vynucení vyplnění tagu při tvorbě prostředku, a to bez ohledu na způsob jeho tvorby.

Pokud tagy používáme pro bezpečnostní politiky, musíme zajistit, aby nebylo možné jejich změnou dosáhnout obcházení bezpečnosti dat a aplikací.

Například v Azure může tagy měnit role Tag Contributor přes API a Contributor přes uživatelské rozhraní. Restriktivním odebráním práv měnit tagy můžeme například vývojářům zabránit měnit vlastnosti a přístupy k produkčnímu prostředí.

Hromadná změna

V průběhu vylepšování systému tagování se stává, že potřebujeme tag přejmenovat nebo změnit celý číselník. Následná hromadná změna tagů může probíhat více způsoby. AWS nabízí Tag Editor v rámci rozhraní, ale i Resource Tagging API. V Azure bychom sáhli po Powershellu. Raději označovat přes skupiny prostředků hromadně než jednotlivě. Existují i specializované nástroje třetích stran jako Tag Manager, které rozšiřují nabídku a dělají správu tagů komfortnější.

Citlivá data

Tagy jsou široce dostupné dalším službám. Umístit do tagu heslo může znamenat, že se objeví plně čitelné a dostupné v billing reportu jako jedna další skupina. Z tohoto důvodu se doporučuje neumisťovat do hodnot tagů žádná citlivá data.

Podobně musíme počítat s tím, že tagy se mohou objevit v různých reportech a exportech, se kterými jsme při jejich budování nepočítali. Mohou se objevit v aplikacích třetích stran, které mají přístup k datům o zdrojích, například nákladově optimalizační nástroje jako je Densify. Je tedy vhodné vyhýbat se osobním datům, která nejsou nezbytně nutná pro provoz, a raději se držet anonymních identifikátorů tam, kde je potřeba vytvořit vazbu na osobu a její osobní data.

Vlastnictví

V pracovním prostředí je velmi dobré, aby pro všechno existovala jasná jmenná odpovědnost. Proto jednou ze základních vlastností každého prostředku je jeho určený vlastník – z hlediska businessu, aplikační správy i správy infrastruktury. Vlastník je zodpovědný za životní cyklus prostředku.

Typy tagů

Pokud bychom si chtěli tagy rozdělit na několik typů, mohli bychom jako kritérium použít způsob užití. Zjednodušeně tak dostaneme tagy/značky:

Technické
Business
Bezpečnostní
Automatizační

Rozdělení není limitující. Je výhodou, pokud můžeme použít stejnou značku pro více účelů. Například označení „Produkční“ prostředek správně zařadí v billingu, současně na něj uplatní bezpečnostní politiku na citlivá data, nastaví správný způsob monitorování, znemožní vypínání během víkendu a zamkne přístup pro deployment a manipulaci daty vývojářům.

Na konci článku si vyjmenujeme nejčastěji používané tagy, ale vysvětleme si jejich rozdělení podle funkce:

Technické tagy

Technické tagy označují parametry, které se týkají technického provozu. K jakému aplikačnímu prostředí (Environment) a celku (FinancialApps) zdroj náleží, zda se jedná o sdílený zdroj mezi aplikacemi (SharedRes), jaký má identifikátor v konfigurační databázi (CMDBKey), který provozní tým (OpsTeam) se stará o prostředek. Dále je možné zde určit úroveň logování (LogLevel), parametry zálohování (BackupType) nebo monitoringu podle tagu o kritičnosti aplikace (Criticality, SLA, etc.) a potřebné podpoře (SupportHours).

Business tagy

Business tagy nejsou vázané na technický provoz, ale jedná se o metadata důležitá pro určení podpory aplikační logiky (pro správnou alokaci nákladů), pro určení nákladového centra (CostCenter) nebo business unit (BU), pro mapování vlastníka aplikace (BizOwner), projektu (OrigProject), stavu migrace (MigrationStatus) apod.

Jejich hlavním použitím je seskupovaní a filtrování v reportingu, možnost oddělovat reporty pro jednotlivá oddělení nebo nákladová centra, ale také při řízení nákladů.

Tyto značky jsou obvykle shodné s konfigurační databází a je vhodné je takto jednosměrně vůči cloudovému prostředku propojit. Jejich správnost je klíčová například pro rozúčtování nákladů nebo nalezení vlastníka.

Obrázek 1 – Billing podle tagů: příklad použití při rozdělování nákladů u Microsoft Azure (Zdroj: https://docs.microsoft.com/cs-cz/azure/cost-management-billing/costs/get-started-partners)

Bezpečnostní tagy

Bezpečnostní tagy umožňují automaticky aplikovat security politiky nad prostředky, zdroji, přístupy a samotnými daty. Jedná se o velkou zbraň, kterou ovšem musíme dostatečně zabezpečit, neboť změnou tagu můžeme dosáhnout změny přístupů a otevřít kritická data nepovolaným osobám.

Mezi běžné tagy patří označení kritičnosti dat (DataSensitivity), jejich omezení na danou geografickou zónu (AllowedZone). Dále informace, zda a na jakou úroveň zapnout bezpečnostní logging (SecLogLevel) nebo auditování změn (AuditOn). Je možné podle potřebných standardů zaznamenat i compliance parametry a podle nich dále automaticky nastavovat preventivní opatření.

Automatizační tagy

Další skupinou tagů jsou automatizační tagy usnadňující správu, integraci, nasazení nebo optimalizaci zdrojů a nákladů. Jejich škála je velmi široká, ale uveďme si nejběžnější, mezi které platí označení, zda prostředek (virtuální stroj) lze mimo pracovní dobu vypínat (ShutdownAllowed), pořadí startu (StartUpOrderInGroup), zda lze prostředek škálovat horizontálně (AddNodes) či vertikálně anebo vůbec (FixedResources).

Jak tedy začít?

Stanovte povinnou syntaxi a číselníky hodnot.
Začněte s méně tagy, které dokážete řídit a kontrolovat.
Nevytvářejte od počátku „tag hell“ množstvím různorodých štítků.
U každého procesu automatizace vynuťte založení povinných hodnot tagů.
Využívejte možné politiky a dědění ze skupin.
Vytvořte ověřovací mechanismus přítomnosti povinných tagů a hodnot neodpovídajících syntaxi a zabraňte tvorbě „rogue“ prostředků.
Propojte systém značek s CMDB již v první fázi alespoň jednostranně.
Rozvíjejte strategie pro technické, bezpečnostní a vývojové scénáře s použitím hodnot tagů.

Detailní informace a návody pro MS Azure si můžete projít zde:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources?tabs=json

A od AWS stojí za to projít si Best practices: https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf