Před deseti lety PaaS běžela výhradně v “Internetu” a na mnoho použití to vůbec nevadilo. V posledních letech ale Azure nabídl dva způsoby těsnější integrace do privátní sítě zákazníka - vystavení PaaS přímo ve VNETu nebo promítnutí PaaS služby do zákaznického VNETu přes Private Link technologii. S některými službami nastupuje nová generace nasazování uvnitř VNETu. Proč? Jak to funguje? Kdy se to hodí a kdy je lepší Private Link? Jaké služby už to využívají?
Platformní služba je většinou dost komplexní IT systém, nikoli nějaké jednoduché VM. Vezměme si například aplikační platformu Application Services nebo příbuzné Azure Functions. Jasně, jsou tam nody, na kterých běží vaše aplikace, to je zřejmé. Kromě toho ale před tím je nějaký frontend, který zajišťuje routing a bezpečnost. Do platformy chcete nasazovat přímo kód, takže je potřeba komponenta, která na změny kódu dokáže reagovat, stáhnout si je (nebo jí je pošlete), ona to projede, zajistí bezpečné nasazení za provozu. Pokud chci škálovat, potřebuji komponentu, která bude vyčítat potřebnou telemetrii a reagovat na základě mých požadavků podle zátěže, denních pravidel apod. K tomu všemu nějaké dohlížedlo, samoopravovadlo a upgradovadlo. Zkrátka je to komplexní platforma.
Teď vezměme v úvahu, že Microsoft nemůže jen tak vstoupit do vašeho VNETu a posílat vám tam pakety jak se mu zlíbí nebo jej proděravět a bez vašeho vědomí otevřít někam jinam. Jenže principem “managed služby” je to, že je “managed” - takže Microsoft tam nějak přistupovat musí. Jinak by to byla jen obyčejná šablona - mnozí private cloud hráči považují chybně šablonu za PaaS, ale ve skutečnosti je to jen chytřejší “skriptík”, který vám nepomůže, když se něco rozbije později.
Prvním řešením tedy je nechat PaaS běžet kompletně v zabezpečeném prostředí Microsoftu, ale pro vaše přístupy k němu tyto endpointy namapovat do VNETu. Takhle to dělá Private Endpoint (Private Link technologie) a je to skvělé pro služby, které konzumujete a používáte jen směr od vás k nim (například využívám databázi v PaaS). Druhé řešení je aktuální generace VNET injection - tedy compute v prostředí Microsoft, ale síťovou kartu promapovat do zákaznického VNETu. Podívejme se na to trochu blíž.
V tomto scénáři běží celý PaaS šelmostroj v subskripci Microsoftu a to včetně zabezpečené sítě, která nemá s vaším VNETem nic společného. Tím pádem vás vůbec netrápí kolik je tam komponent, jak spolu komunikují a tak podobně - tohle včetně zabezpečení těchto toků na sebe bere Microsoft a pro vás je to něco, co nevidíte, neřešíte. Služba ale má nějaký interface, něco, co vám umožňuje její služby konzumovat. Možná je to DB protokol, endpoint pro zasílání a vyzvedávání zpráv a tak podobně. Služba tam má nějaký frontend, FQDN, na kterém poslouchá a zajišťuje ověření uživatele (klíč, AAD token) a směrování na příslušnou instanci služby. Private Link umožňuje vaší instanci služby vypnout na veřejném FQDN a říct frontend komponentě, že pro tuto instanci má poslouchat pouze na private linku - představme si to jako VPN tunel (technologicky to tak zcela není, ale to zatím neřešme). Zákazník ve VNETu vytvoří private endpoint a ten si představme jako virtuální síťovou kartu, která nabírá privátně provoz a dostane ho bezpečně na frontend PaaS služby a tento tunel má unikátní ID, takže služba ví, že tohle je provoz z vaší sítě a ne nějaké jiné.
Mimochodem u PaaS služby se potkáte pouze s vaší stranou (Private Endpoint v zákaznickém VNETu), ale to co je použito na straně služby je standardní technologie Private Link Service. Jinak řečeno i vy můžete provozovat vlastní služby, které někdo jiný může konzumovat přes Private Endpoint. Pokud nabízíte například nějakou PaaS/SaaS platformu nad Azure, je vám to k dispozici pro vaše zákazníky. Nebo možná potřebujete ve své firmě vytvořit aplikační řešení, které je schválně izolované od firemní sítě, ale nabízí nějaké API, které chcete ve vaší síti konzumovat - u této služby použijte Private Link Service a tím si vaši kolegové mohou vytvořit Private Link ve svém VNETu.
Proč bych měl vůbec chtít něco jiného? Potíž je, že tahle technologie propojí frontend služby s vaším VNETem. Můžete tedy ke službě přistupovat. Ale služba samotná samozřejmě neběží na tom frontendu (můžete si představit také jako chytrý router). Co když přímo služba potřebuje přistupovat do vaší sítě - tedy ne vy se ptáte služby, ale služba se ptá vás? Třeba je to aplikace běžící v PaaS, která se potřebuje doptávat on-prem databáze nebo jde o datové řešení (Spark, ETL proces), které kontaktuje on-prem zdroje. Pak vám Private Endpoint nepomůže - proto čtěte dál.
Které služby podporují Private Endpoint? Je jich hodně: https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview#private-link-resource
Pokud potřebujete, aby worker node v PaaS službě (např. Spark node nebo Application Gateway) mohl komunikovat do VNETu, tak nezbude, než tento node ve formě VM skutečně v této síti nasadit. Azure PaaS dokáže udělat zajímavý trik - toto VM je vidět v Microsoft subskripci, ale jeho síťová karta je napojena do zákaznického VNETu, u kterého je tohle explicitně povoleno (subnet delegation).
Tohle řešení skvěle funguje, ale přináší jednu komplikaci. Ve vaší síti se ocitne kousek PaaS služby a o tu chcete, aby se vám staral Microsoft. Jak se k ní ale dostane? Jak tam bude fungovat sledovadlo, upgradovadlo, nasazovadlo, škálovadlo a tak podobně? Je na vás ujistit se, že tam Microsoft bude mít přístup.
U některých služeb je to celkem bezbolestné, protože fungují na principu “call home”. Tedy služba se probere a zavolá domů s dotazem “co mám dělat, jak se mám nastavit?”. Takhle funguje třeba AKS worker none nebo self-hosted gateway Azure API Managementu. V dokumentaci takové služby najdete jaká komunikace musí být povolená. V ideálním případě jako je právě GW API Managementu stačí outbound 443 na endpoint management serveru (public adresa), což není problém na vašich firewalech zajistit a obvykle s tím jsou všichni v pohodě. U AKS nodů je to zase 443, ale také port 9000 - ale tam zas pomůže to, že AKS umí management server promítnout do VNETu přes Private Endpoint.
U většiny služeb je to ale komplikovanější. Aby Microsoft dokázal službu monitorovat a držet její SLA, tak vyžaduje schopnost se na ní “dopingnout”. Tedy nejen, že si služba zavolá domů, ale Microsoft management systémy ji potřebují aktivně kontaktovat. Jde tedy o Inbound směr. To také znamená, že nebude fungovat nějaký váš firewall v cestě (management server by oslovil instanci na přímo, ale ta by odpověděla přes firewall - ten tak neuvidí celou session a dropne to). Proto musíte do svých směrovacích pravidel dát výjimku - provoz na management server jde na přímo, ne přes váš firewall (UDR pravidlo do “Internetu”). Pokud je management server na konkrétní IP, tak to je celkem OK (např. u Azure Databricks), ale obvyklejší je, že jde o poměrně rozsáhlou sadu IP, které se navíc v čase mění. Proto byla do preview uvedena možnost dávat do UDR tagy - to hodně pomůže. Služby, které mají tyto požadavky zahrnují například Application Gateway v2, Azure SQL Managed Instance, Application Services Environment v2, Azure Databricks
Sečteno a podtrženo - VNET injection sice skvěle funguje, ale z principu věci potřebuje, abyste Microsoft pustili do své sítě a to enterprise sítí není běžný postup, takže vás čeká hodně diskusí se security oddělením. Nemyslím, že povolení potřebných pravidel představuje jakékoli riziko, protože management servery jsou řešeny velmi robustně s přísnou autentizací a Microsoft je na to pravidelně dost brutálně auditován, ale otázky, které bezpečnost klade jsou legitimní a jejich odpovězení zkrátka zabere dost času a energie všech zúčastněných.
Než se pustíme dál podívejme se na novou síťovou funkci AKS, která využívá právě nových síťových možností, které se budou hodit i pro PaaS služby, jak uvidíte dále.
Konkrétně mluvme o AKS s Azure CNI pluginem, tedy situací, kdy Pod (kontejnery) běží přímo ve vaše VNETu místo obvyklých ztřeštěností jako je různé NATování nebo overlay. Jak to funguje? AKS node si pro sebe zabere víc jak jednu adresu, třeba 32 adres, které můžeme považovat za sekundární interface. Node samotný má adresu primární, ale pro jednotlivé Pody přiděluje adresy sekundární. Díky síťařině pod tím to z pohledu VNETu vypadá, jako kdyby Pod měl svou vlastní síťovou kartu a protože tato je promapována až do VNETu tak skutečně jiný stroj ve VNETu může kontaktovat Pod na přímo. Toho efektivně využívá Azure Application Gateway v roli Ingress kontroleru a snižuje tak významně latenci (balancuje přímo na Pody, ne přes Nody a jejich iptables).
Novou funkcí v preview je možnost alokovat pro Pod jiný subnet, než pro node. Tím dojde k oddělení. Node si nealokuje adresy dopředu a běží jinde. Pody si berou adresy z jiného subnetu - a to bez ohledu na to, na kterém Nodu běží. Díky tomu se dá lépe hospodařit s IP rozsahy, pružněji je přidávat a tak podobně. Tohle je hodně zajímavé. Máte VM a v ní kontejnery a přitom VM běží v jiném subnetu, než kontejnery, které jsou hostované v tom VM.
Řekněme si teď dva zajímavé atributy, co se nám budou hodit:
Naprostá většina PaaS řešení vždy byla VM. Jakmile ji nasadíte v zákaznickém VNETu, musíte se o ni starat po síti a tedy přijít s nutností tam Microsoft pustit. Nová generace VNET integrace by mohla nechat celé řešení včetně worker VM v prostředí Microsoftu (kde není problém řídit komunikaci management plane bez požadavků na zákaznický VNET) a k zákazníkovi promítnout až kontejner s procesem (třeba DB engine). Díky tomu, že kontejner lze monitorovat a spravovat z hostitele, tak by už nebylo potřeba, aby zákaznický VNET nastavil všechny ty prostupy na management systémy. To by umožnilo bezpečnou integraci do VNETu, která ale nebude nutit zákazníky nastavovat výjimky v jejich pravidlech nebo je nutit obcházet jejich firewall.
Najdete už dnes nějaké služby, které těchto principů využívají? Ano, například Application Service Environment v3. Porovnejte dost brutální seznam výjimek v2 s novou v3, která už je v obecné dostupnosti. Kolik výjimek a prostupů je potřeba na NSG, firewallu a UDR u v3? Žádná! Totéž platí pro Azure Database for MySQL a PostgreSQL v režimu Flexbile Server (aktuálně v preview). Azure Function Premium jsou v obecné dostupnost a také tam platí, že běhat svoje funkce můžete uvnitř VNET bez nějakých nároků na změnu směrování nebo prostupů pro platformu jako takovou (řešíte tedy jen kam chcete dát přístup vašemu kódu, ne nějaké management vrstvě cloudu). Co jsem slyšel, tak další služby budou následovat.
Vždy tedy budou služby, kde řešením bude Private Endpoint. Zejména půjde o ty, kde využíváte výnosů z rozsahu na nějakém obrovském multi-tenantním clusteru jako v případě Azure Cosmos DB, Azure Monitor a promítnutí vaší části celého clusteru do VNET ve formě Private Endpoint je ideální postup. U služeb, které pouze odebíráte, ale ony sami nepotřebují komunikovat do VNETu je Private Endpoint také naprosto dostatečný (např. Azure SQL). Služby, které ale potřebují mluvit do vašeho VNETu a samy si pro něco sahat (například Synapse, App Service, Logic Apps, Data Factory, Application Gateway) jsou ideálním kandidátem na novou integraci. ASEv3, ACI, Functions a Azure Database for MySQL/PostgreSQL Flexible Server si můžete vyzkoušet už dnes a některé jsou dokonce už v GA.