Použití služby Azure Firewall k ochraně clusteru Azure Kubernetes Service (AKS)

Azure Firewall
Azure Kubernetes Service (AKS)
Azure Private Link
Azure Virtual Network
Azure DevOps

Tato příručka popisuje, jak vytvořit privátní cluster AKS v hvězdicové síťové topologii pomocí Terraformu a Azure DevOps. Azure Firewall slouží ke kontrole provozu do a z clusteru Azure Kubernetes Service (AKS ). Cluster je hostovaný jednou nebo více paprskovými virtuálními sítěmi, které jsou v partnerském vztahu k virtuální síti centra.

Architektura

Diagram znázorňující architekturu, která má privátní cluster A K S v hvězdicové síťové topologii

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Moduly Terraformu slouží k nasazení nové virtuální sítě se čtyřmi podsítěmi, které hostují:

  • Cluster AKS (AksSubnet).
  • Jump-box virtual machine (VM) a privátní koncové body (VmSubnet).
  • Application Gateway WAF2 (AppGatewaySubnet).
  • Azure Bastion (AzureBastionSubnet).

Cluster AKS používá spravovanou identitu definovanou uživatelem k vytvoření dalších prostředků, jako jsou nástroje pro vyrovnávání zatížení a spravované disky v Azure. Moduly Terraformu umožňují volitelně nasadit cluster AKS s těmito funkcemi:

Cluster AKS se skládá z následujících fondů:

  • Fond systémových uzlů, který hostuje pouze důležité systémové pody a služby
  • Fond uzlů uživatele, který je hostitelem uživatelských úloh a artefaktů

Virtuální počítač je nasazený ve virtuální síti, která je hostitelem clusteru AKS. Když nasadíte AKS jako privátní cluster, můžou správci systému tento virtuální počítač použít ke správě clusteru pomocí nástroje příkazového řádku Kubernetes. Protokoly diagnostiky spouštění virtuálního počítače se ukládají do účtu Azure Storage.

Hostitel Služby Azure Bastion poskytuje vylepšené připojení SSH k virtuálnímu počítači s jump-boxem přes PROTOKOL SSL. Azure Container Registry se používá k vytváření, ukládání a správě imagí kontejnerů a artefaktů (jako jsou grafy Helm).

AKS neposkytuje integrované řešení pro zabezpečení příchozího a výchozího provozu mezi clusterem a externími sítěmi.

Z tohoto důvodu architektura uvedená v tomto článku obsahuje bránu Azure Firewall , která řídí příchozí a odchozí provoz pomocí pravidel DNAT, pravidel sítě a pravidel aplikace. Brána firewall také chrání úlohy pomocí filtrování na základě analýzy hrozeb. Azure Firewall a Bastion se nasadí do centrální virtuální sítě, která je v partnerském vztahu s virtuální sítí hostující privátní cluster AKS. Směrovací tabulka a trasy definované uživatelem směrují odchozí provoz z clusteru AKS do brány Azure Firewall.

Poznámka:

Důrazně doporučujeme používat skladovou položku Premium služby Azure Firewall, protože poskytuje pokročilou ochranu před hrozbami.

Key Vault se používá jako úložiště tajných kódů úlohami, které běží v AKS k načtení klíčů, certifikátů a tajných kódů prostřednictvím ID úloh Microsoft Entra, ovladače CSI úložiště tajných kódů nebo Dapr. Azure Private Link umožňuje úlohám AKS přistupovat ke službám Azure PaaS, jako je Azure Key Vault, přes privátní koncový bod ve virtuální síti.

Topologie zahrnuje privátní koncové body a privátní zóny DNS pro tyto služby:

Existuje propojení virtuální sítě mezi virtuální sítí, která hostuje cluster AKS a privátní zóny DNS popsané výše.

Pracovní prostor služby Log Analytics slouží ke shromažďování diagnostických protokolů a metrik ze služeb Azure.

Komponenty

  • Azure Firewall je služba zabezpečení brány firewall sítě nativní pro cloud, která poskytuje ochranu před hrozbami pro cloudové úlohy, které běží v Azure. Jde o plně stavovou bránu firewall poskytovanou jako služba s integrovanou vysokou dostupností a neomezenou cloudovou škálovatelností. Zajišťuje kontrolu provozu na východ-západ i sever-jih.

  • Container Registry je spravovaná privátní služba registru Dockeru založená na opensourcovém registru Docker Registry 2.0. Registry kontejnerů Azure můžete použít se stávajícími kanály vývoje a nasazení kontejnerů nebo pomocí úloh container Registry vytvářet image kontejnerů v Azure.

  • Azure Kubernetes Service zjednodušuje nasazování spravovaných clusterů Kubernetes v Azure přesměrováním provozní režie do Azure. Azure jako hostovaná služba Kubernetes zpracovává důležité úlohy, jako je monitorování stavu a údržba. Vzhledem k tomu, že hlavní servery Kubernetes spravuje Azure, spravujete a udržujete pouze uzly agenta.

  • Key Vault ukládá a řídí přístup k tajným kódům, jako jsou klíče rozhraní API, hesla, certifikáty a kryptografické klíče s lepším zabezpečením. Key Vault také umožňuje snadno zřizovat, spravovat a nasazovat veřejné a privátní certifikáty TLS/SSL (Transport Layer Security/Secure Sockets Layer) pro použití s Azure a interními připojenými prostředky.

  • Azure Bastion je plně spravovaná platforma jako služba (PaaS), kterou zřídíte ve své virtuální síti. Azure Bastion poskytuje vylepšené připojení protokolu RDP (Remote Desktop Protocol) a SSH (Secure Shell) k virtuálním počítačům ve vaší virtuální síti přímo z webu Azure Portal přes protokol TLS.

  • Azure Virtual Machines poskytuje škálovatelné výpočetní prostředky na vyžádání, které poskytují flexibilitu virtualizace.

  • Azure Virtual Network je základním stavebním blokem privátních sítí Azure. Virtuální síť umožňuje prostředkům Azure (jako jsou virtuální počítače) vzájemně komunikovat, internet a místní sítě s lepším zabezpečením. Virtuální síť Azure je jako tradiční místní síť, ale zahrnuje výhody infrastruktury Azure, jako je škálovatelnost, dostupnost a izolace.

  • Virtuální síťová rozhraní umožňují virtuálním počítačům Azure komunikovat s internetem, Azure a místními prostředky. Do jednoho virtuálního počítače Azure můžete přidat několik síťových karet, aby podřízené virtuální počítače mohly mít svá vlastní vyhrazená zařízení a IP adresy síťového rozhraní.

  • Spravované disky Azure poskytují svazky úložiště na úrovni bloků, které Azure spravuje na virtuálních počítačích Azure. K dispozici jsou disky Úrovně Ultra, disky SSD úrovně Premium, disky SSD úrovně Premium, disky SSD úrovně Standard a disky HDD úrovně Standard.

  • Blob Storage je řešení úložiště objektů pro cloud. Blob Storage je optimalizovaná pro ukládání obrovských objemů nestrukturovaných dat.

  • Private Link umožňuje přístup ke službám Azure PaaS (například Blob Storage a Key Vault) přes privátní koncový bod ve vaší virtuální síti. Můžete ho také použít pro přístup ke službám hostovaným v Azure, které vlastníte nebo které poskytuje partner Microsoftu.

Alternativy

Místo služby Azure Firewall můžete použít bránu firewall třetí strany z Azure Marketplace. Pokud to uděláte, je vaší zodpovědností správně nakonfigurovat bránu firewall tak, aby kontrolovali a povolovali nebo odepřeli příchozí a odchozí provoz z clusteru AKS.

Podrobnosti scénáře

Clustery AKS se nasazují do virtuální sítě, kterou je možné spravovat nebo vlastní. Bez ohledu na to, že cluster má odchozí závislosti na službách mimo virtuální síť. Pro účely správy a provozu potřebují uzly clusteru AKS přístup ke konkrétním portům a plně kvalifikovaným názvům domén přidruženým k těmto odchozím závislostem. To zahrnuje přístup k serveru rozhraní KUBERNEtes API vašeho vlastního clusteru, stahování a instalaci komponent clusteru a vyžádání imagí kontejnerů z Microsoft Container Registry. Tyto odchozí závislosti jsou definované pomocí plně kvalifikovaných názvů domén a nemají statické adresy, což znemožňuje uzamknout odchozí provoz pomocí skupin zabezpečení sítě. Clustery AKS proto mají ve výchozím nastavení neomezený odchozí (odchozí) přístup k internetu, aby uzly a služby měly podle potřeby přístup k externím prostředkům.

V produkčním prostředí je ale obvykle žádoucí chránit cluster Kubernetes před exfiltrací dat a jiným nežádoucím síťovým provozem. Veškerý síťový provoz, příchozí i odchozí, by se měl řídit na základě pravidel zabezpečení. K dosažení tohoto cíle je potřeba omezit odchozí provoz a zároveň povolit přístup k potřebným portům a adresám pro běžné úlohy údržby clusteru, odchozí závislosti a požadavky na úlohy.

Jednoduchým řešením je použít zařízení brány firewall, které může řídit odchozí provoz na základě názvů domén. Brána firewall vytvoří bariéru mezi důvěryhodnou sítí a internetem. Pomocí služby Azure Firewall můžete omezit odchozí provoz na základě plně kvalifikovaného názvu domény cíle, protokolu a portu, který poskytuje podrobné řízení odchozího přenosu dat. Umožňuje také povolit výpis plně kvalifikovaných názvů domén přidružených k odchozím závislostem clusteru AKS, což není možné se skupinami zabezpečení sítě. Kromě toho může filtrování na základě analýzy hrozeb v bráně Azure Firewall nasazené do sdílené hraniční sítě řídit příchozí provoz a zvýšit zabezpečení. Toto filtrování může generovat výstrahy a odepřít provoz do a ze známých škodlivých IP adres a domén.

Privátní cluster AKS můžete vytvořit v hvězdicové síťové topologii pomocí Terraformu a Azure DevOps. Azure Firewall slouží ke kontrole provozu do a z clusteru Azure Kubernetes Service (AKS ). Cluster je hostovaný jednou nebo více paprskovými virtuálními sítěmi, které jsou v partnerském vztahu k virtuální síti centra.

Azure Firewall podporuje tři různé skladové položky pro zajištění široké škály případů použití a preferencí zákazníka:

  • Azure Firewall Premium se doporučuje zabezpečit vysoce citlivé aplikace, jako je zpracování plateb. Podporuje pokročilé možnosti ochrany před hrozbami, jako je malware a kontrola protokolu TLS.
  • Azure Firewall Standard se doporučuje zákazníkům, kteří hledají bránu firewall vrstvy 3–vrstva 7 a potřebují automatické škálování pro zpracování období špičky provozu až 30 Gb/s. Podporuje podnikové funkce, jako jsou analýzy hrozeb, proxy DNS, vlastní DNS a webové kategorie.
  • Azure Firewall Basic se doporučuje pro zákazníky, kteří potřebují propustnost menší než 250 Mb/s.

Následující tabulka uvádí funkce tří skladových položek služby Azure Firewall. Další informace najdete v tématu o cenách služby Azure Firewall.

Snímek obrazovky znázorňující funkce tří skladových položek služby Azure Firewall

Clustery AKS mají ve výchozím nastavení neomezený odchozí přístup k internetu. Tato úroveň síťového přístupu umožňuje uzlům a službám, které běží v clusteru AKS, přístup k externím prostředkům podle potřeby. Pokud chcete omezit odchozí provoz, musí zůstat přístupný omezený počet portů a adres, aby se zachovaly úlohy údržby clusteru, které jsou v pořádku. Nejjednodušší způsob, jak zajistit zabezpečení odchozího provozu z clusteru Kubernetes, jako je AKS, je použít softwarovou bránu firewall, která může řídit odchozí provoz na základě názvů domén. Azure Firewall může omezit odchozí provoz HTTP a HTTPS na základě plně kvalifikovaného názvu domény (FQDN) cíle. Můžete také nakonfigurovat pravidla brány firewall a zabezpečení tak, aby povolovali tyto požadované porty a adresy. Další informace najdete v tématu Řízení výchozího přenosu dat pro uzly clusteru v AKS.

Podobně můžete řídit příchozí provoz a zlepšit zabezpečení tím, že povolíte filtrování na základě analýzy hrozeb na bráně Azure Firewall nasazené ve sdílené hraniční síti. Toto filtrování může poskytovat výstrahy a odepřít provoz do a ze známých škodlivých IP adres a domén.

Potenciální případy použití

Tento scénář řeší potřebu zlepšit zabezpečení příchozího a odchozího provozu do a z clusteru Kubernetes.

Vyhněte se asymetrickým směrováním

V tomto řešení se Azure Firewall nasadí do centrální virtuální sítě a privátní cluster AKS se nasadí do paprskové virtuální sítě. Azure Firewall používá kolekce pravidel sítě a aplikací k řízení odchozího provozu. V této situaci je potřeba nakonfigurovat příchozí provoz do libovolného veřejného koncového bodu vystaveného jakoukoli službou spuštěnou v AKS, abyste mohli vstoupit do systému prostřednictvím jedné z veřejných IP adres používaných službou Azure Firewall.

Pakety přicházejí na veřejnou IP adresu brány firewall, ale vrací se k bráně firewall přes privátní IP adresu (pomocí výchozí trasy). Jedná se o problém. Abyste se tomu vyhnuli, vytvořte další trasu definovanou uživatelem pro veřejnou IP adresu brány firewall, jak je znázorněno v následujícím diagramu. Pakety směrované na veřejnou IP adresu brány firewall se směrují přes internet. Tato konfigurace zabraňuje výchozí trase na privátní IP adresu brány firewall.

Pokud chcete směrovat provoz úloh AKS do služby Azure Firewall ve virtuální síti centra, musíte:

  • Vytvořte a přidružte směrovací tabulku ke každé podsíti, která je hostitelem pracovních uzlů vašeho clusteru.
  • Vytvořte trasu definovanou uživatelem, která přesměruje provoz pro CIDR 0.0.0.0/0 na privátní IP adresu služby Azure Firewall. Zadejte virtuální zařízení pro typ dalšího segmentu směrování.

Další informace najdete v tématu Kurz: Nasazení a konfigurace služby Azure Firewall pomocí webu Azure Portal.

Diagram znázorňující, jak se vyhnout asymetrickým směrováním při použití služby Azure Firewall před úlohami

Další informace naleznete v tématu:

Nasazení úloh do privátního clusteru AKS při použití Azure DevOps

Pokud používáte Azure DevOps, mějte na paměti, že k nasazení úloh do privátního clusteru AKS nemůžete použít agenty hostované Microsoftem v Azure DevOps. Nemají přístup ke svému serveru rozhraní API. Pokud chcete nasadit úlohy do privátního clusteru AKS, musíte zřídit a použít místního agenta Azure DevOps ve stejné virtuální síti jako váš privátní cluster AKS nebo v partnerské virtuální síti. V druhém případě nezapomeňte vytvořit propojení virtuální sítě mezi privátní zónou DNS clusteru AKS ve skupině prostředků uzlu a virtuální sítí, která je hostitelem místního agenta Azure DevOps.

Na virtuální počítač můžete nasadit jednoho agenta Azure DevOps pro Windows nebo Linux nebo můžete použít škálovací sadu virtuálních počítačů. Další informace najdete v tématu Agenti škálovací sady virtuálních počítačů Azure. Alternativně můžete v Azure Pipelines nastavit agenta v místním prostředí tak, aby běžel uvnitř kontejneru Windows Server Core (pro hostitele Windows) nebo kontejneru Ubuntu (pro hostitele s Linuxem) pomocí Dockeru. Nasaďte ho jako pod s jednou nebo více replikami v privátním clusteru AKS. Další informace naleznete v tématu:

Pokud jsou podsítě, které hostují fondy uzlů vašeho privátního clusteru AKS, nakonfigurované tak, aby směrovaly odchozí provoz do brány Azure Firewall přes směrovací tabulku a trasu definovanou uživatelem, nezapomeňte vytvořit správná pravidla aplikace a sítě. Tato pravidla musí agentovi umožnit přístup k externím webům, aby mohl stahovat a instalovat nástroje, jako je Docker, Kubectl, Azure CLI a Helm na virtuálním počítači agenta. Další informace najdete v tématu Spuštění místního agenta v Dockeru.

Diagram znázorňující nasazení úloh do privátního clusteru AKS pro použití s Azure DevOps

Případně můžete ve virtuální síti hostující cluster AKS nebo v partnerské virtuální síti nakonfigurovat spravovaný fond DevOps (MDP ). Spravované fondy DevOps umožňují vývojovým týmům vytvářet fondy agentů Azure DevOps přizpůsobené jejich konkrétním potřebám. Implementuje osvědčené postupy zabezpečení, poskytuje možnosti vyvážení nákladů a výkonu, nabízí cesty pro běžné scénáře a výrazně zkracuje dobu strávenou při vytváření a údržbě vlastních fondů. Další informace najdete v tématu Přehled architektury spravovaných fondů DevOps od Microsoftu.

Ve virtuální síti můžete přidat agenty ze spravovaného fondu DevOps, což umožňuje kanálům CI/CD pracovat se serverem rozhraní Kubernetes API vašeho privátního clusteru AKS a přistupovat k prostředkům Azure, jako je Azure Container Registry, které mají zakázaný přístup k veřejné síti a dají se dosáhnout pouze prostřednictvím privátního koncového bodu definovaného ve stejné virtuální síti nebo partnerské síti. Další informace najdete v tématu Konfigurace sítí spravovaných fondů DevOps.

Použití služby Azure Firewall před veřejným Load Balancerem úrovně Standard

Definice prostředků v modulech Terraformu používají meta-argument životního cyklu k přizpůsobení akcí, když se prostředky Azure změní mimo řízení Terraformu. Argument ignore_changes slouží k pokynu Terraformu, aby ignoroval aktualizace daných vlastností prostředků, jako jsou značky. Definice prostředku služby Azure Firewall Policy obsahuje blok životního cyklu, který brání Terraformu v aktualizaci prostředku při vytvoření, aktualizaci nebo odstranění kolekce pravidel nebo jednoho pravidla. Stejně tak tabulka Směrování Azure obsahuje blok životního cyklu, který brání Terraformu v aktualizaci prostředku při vytvoření, odstranění nebo aktualizaci trasy definované uživatelem. To vám umožní spravovat pravidla DNAT, aplikace a sítě zásad služby Azure Firewall a tras definovaných uživatelem tabulky tras Azure mimo řízení Terraformu.

Ukázka přidružená k tomuto článku obsahuje kanál CD Azure DevOps, který ukazuje, jak nasadit úlohu do privátního clusteru AKS pomocí kanálu Azure DevOps, který běží na místním agentu. Ukázka nasadí webovou aplikaci pro správu projektů Bitnami redmine pomocí veřejného chartu Helm . Tento diagram znázorňuje síťovou topologii ukázky:

Diagram znázorňující službu Azure Firewall před veřejným Load Balancerem úrovně Standard

Tady je tok zpráv:

  1. Požadavek na webovou aplikaci hostované službou AKS se odešle na veřejnou IP adresu, která je zpřístupněná službou Azure Firewall prostřednictvím konfigurace veřejné IP adresy. Veřejná IP adresa i konfigurace veřejné IP adresy jsou vyhrazené pro tuto úlohu.
  2. Pravidlo DNAT služby Azure Firewall přeloží veřejnou IP adresu a port služby Azure Firewall na veřejnou IP adresu a port používaný úlohou ve veřejném Load Balanceru služby Kubernetes úrovně Standard clusteru AKS ve skupině prostředků uzlu.
  3. Nástroj pro vyrovnávání zatížení odešle požadavek na jeden z podů služby Kubernetes, které běží na jednom z uzlů agenta clusteru AKS.
  4. Zpráva odpovědi se odešle zpět původnímu volajícímu přes trasu definovanou uživatelem. Veřejná IP adresa služby Azure Firewall je předpona adresy a internet je typ dalšího segmentu směrování.
  5. Jakékoli odchozí volání iniciované úlohou se směruje na privátní IP adresu služby Azure Firewall ve výchozím uživatelem definované trase. 0.0.0.0/0 je předpona adresy a virtuální zařízení je typ dalšího segmentu směrování.

Další informace najdete v tématu Použití služby Azure Firewall před veřejným Load Balancerem úrovně Standard clusteru AKS.

Použití služby Azure Firewall před interním Load Balancerem úrovně Standard

V ukázce přidružené k tomuto článku je aplikace ASP.NET Core hostovaná jako služba clusterem AKS a před ní kontroler příchozího přenosu dat NGINX. Kontroler příchozího přenosu dat NGINX je vystavený prostřednictvím interního nástroje pro vyrovnávání zatížení, který má privátní IP adresu ve virtuální síti paprsku, která je hostitelem clusteru AKS. Další informace najdete v tématu Vytvoření kontroleru příchozího přenosu dat do interní virtuální sítě v AKS. Když nasadíte kontroler příchozího přenosu dat NGINX nebo obecněji LoadBalancer službu nebo ClusterIP poznámku service.beta.kubernetes.io/azure-load-balancer-internal: "true" v části metadat, vytvoří se v rámci skupiny prostředků uzlu interní kubernetes-internal standardní nástroj pro vyrovnávání zatížení. Další informace najdete v tématu Použití interního nástroje pro vyrovnávání zatížení s AKS. Jak je znázorněno v následujícím diagramu, testovací webová aplikace je vystavená službou Azure Firewall prostřednictvím vyhrazené veřejné IP adresy Azure.

Diagram znázorňující službu Azure Firewall před interním Load Balancerem úrovně Standard

Tady je tok zpráv:

  1. Požadavek na testovací webovou aplikaci hostované službou AKS se odešle na veřejnou IP adresu, která je vystavená bránou Azure Firewall prostřednictvím konfigurace veřejné IP adresy. Veřejná IP adresa i konfigurace veřejné IP adresy jsou vyhrazené pro tuto úlohu.
  2. Pravidlo DNAT služby Azure Firewall překládá veřejnou IP adresu a port služby Azure Firewall na privátní IP adresu a port používaný kontrolerem příchozího přenosu dat NGINX v interním Load Balanceru služby Standard clusteru AKS ve skupině prostředků uzlu.
  3. Požadavek odešle interní nástroj pro vyrovnávání zatížení na jeden z podů služby Kubernetes, které běží na jednom z uzlů agenta clusteru AKS.
  4. Zpráva odpovědi se odešle zpět původnímu volajícímu přes trasu definovanou uživatelem. 0.0.0.0/0 je předpona adresy a virtuální zařízení je typ dalšího segmentu směrování.
  5. Jakékoli odchozí volání iniciované úlohou se směruje na privátní IP adresu trasy definované uživatelem.

Další informace najdete v tématu Použití služby Azure Firewall před interním Load Balancerem úrovně Standard.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Některé z následujících aspektů jsou obecná doporučení, která nejsou specifická pro použití služby Azure Firewall ke zlepšení ochrany clusteru AKS. Věříme, že se jedná o základní požadavky tohoto řešení. To platí pro aspekty zabezpečení, výkonu, dostupnosti a spolehlivosti, úložiště, sítě služeb a monitorování.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Platforma Azure poskytuje vylepšenou ochranu před různými hrozbami, jako jsou narušení sítě a distribuované útoky DDoS (Denial of Service). Bránu firewall webových aplikací (WAF) byste měli použít k zajištění ochrany pro všechny webové aplikace a služby hostované službou AKS, které zpřístupňují veřejný koncový bod HTTPS. Potřebujete zajistit ochranu před běžnými hrozbami, jako je injektáž SQL, skriptování mezi weby a další zneužití webu. Uděláte to tak, že použijete pravidla OWASP (Open Web Application Security Project) a vlastní pravidla. Azure Web Application Firewall poskytuje vylepšenou centralizovanou ochranu webových aplikací před běžným zneužitím a ohrožením zabezpečení. Azure WAF můžete nasadit s Aplikace Azure lication Gateway, Azure Front Door a Azure Content Delivery Network.

Útoky DDoS patří mezi největší problémy s dostupností a zabezpečením, kterým čelí organizace, které přesouvají své aplikace do cloudu. Útok DDoS se pokusí vyčerpat prostředky aplikace a znepřístupňuje aplikaci legitimním uživatelům. Útoky DDoS se dají cílit na libovolný koncový bod, který je veřejně dostupný přes internet. Každá vlastnost v Azure zahrnuje ochranu prostřednictvím ochrany infrastruktury Azure DDoS bez dalších poplatků. Škálování a kapacita globálně nasazené sítě Azure poskytuje vylepšenou ochranu před běžnými útoky na síťovou vrstvu prostřednictvím nepřetržitého monitorování provozu a zmírnění rizik v reálném čase. Ochrana infrastruktury DDoS nevyžaduje žádné změny konfigurace uživatele ani aplikace. Pomáhá chránit všechny služby Azure, včetně služeb PaaS, jako je Azure DNS.

Azure DDoS Network Protection v kombinaci s osvědčenými postupy návrhu aplikací poskytuje vylepšené funkce pro zmírnění rizik DDoS, které poskytují větší ochranu před útoky DDoS. Službu Azure DDOS Network Protection byste měli povolit v jakékoli hraniční virtuální síti.

Tady je několik dalších aspektů zabezpečení:

  • Vytvořte privátní koncový bod pro libovolnou službu PaaS, kterou používají úlohy AKS, jako je Key Vault, Azure Service Bus a Azure SQL Database. Provoz mezi aplikacemi a těmito službami není přístupný veřejnému internetu. Provoz mezi virtuální sítí clusteru AKS a instancí služby PaaS prostřednictvím privátního koncového bodu prochází páteřní sítí Microsoftu, ale komunikace neprochází bránou Azure Firewall. Tento mechanismus poskytuje lepší zabezpečení a lepší ochranu před únikem dat. Další informace najdete v tématu Co je Azure Private Link?
  • Pokud používáte službu Application Gateway před clusterem AKS, použijte zásadu firewallu webových aplikací k ochraně veřejně přístupných úloh, které běží v AKS před útoky.
  • Pomocí zásad sítě se oddělte a pomozte zabezpečit komunikaci uvnitř služeb tím, že řídíte, které komponenty spolu můžou vzájemně komunikovat. Ve výchozím nastavení můžou všechny pody v clusteru Kubernetes odesílat a přijímat provoz bez omezení. Ke zlepšení zabezpečení můžete použít zásady sítě Azure nebo zásady sítě Calico k definování pravidel, která řídí tok provozu mezi různými mikroslužbami. Další informace najdete v tématu Zásady sítě.
  • Nezpřístupňujte vzdálené připojení k uzlům AKS. Vytvořte hostitele bastionu nebo jump box ve virtuální síti pro správu. Ke směrování provozu do clusteru AKS použijte hostitele bastionu.
  • Zvažte použití privátního clusteru AKS v produkčním prostředí nebo alespoň zabezpečeného přístupu k serveru rozhraní API pomocí autorizovaných rozsahů IP adres v AKS. Pokud používáte autorizované rozsahy IP adres ve veřejném clusteru, povolte všechny výchozí IP adresy v kolekci pravidel sítě služby Azure Firewall. Operace v clusteru využívají server rozhraní API Kubernetes.
  • Pokud povolíte proxy server DNS ve službě Azure Firewall, může služba Azure Firewall zpracovávat a předávat dotazy DNS z jedné nebo více virtuálních sítí na server DNS, který zvolíte. Tato funkce je zásadní a vyžaduje se pro spolehlivé filtrování plně kvalifikovaného názvu domény v pravidlech sítě. Proxy server DNS můžete povolit v nastavení služby Azure Firewall a zásad brány firewall. Další informace o protokolech proxy serveru DNS najdete v tématu Protokol a metriky služby Azure Firewall.
  • Když používáte službu Azure Firewall před službou Application Gateway, můžete nakonfigurovat prostředek příchozího přenosu dat Kubernetes tak, aby zpřístupnil úlohy prostřednictvím protokolu HTTPS, a pro každého tenanta použít samostatnou subdoménu a digitální certifikát. Kontroler příchozího přenosu dat služby Application Gateway (AGIC) automaticky nakonfiguruje naslouchací proces služby Application Gateway pro ukončení protokolu SSL (Secure Sockets Layer).
  • Azure Firewall můžete použít před proxy serverem služby, jako je kontroler příchozího přenosu dat NGINX. Tento kontroler poskytuje reverzní proxy server, konfigurovatelné směrování provozu a ukončení protokolu TLS pro služby Kubernetes. Prostředky příchozího přenosu dat Kubernetes se používají ke konfiguraci pravidel a tras pro příchozí data u jednotlivých služeb Kubernetes. Pomocí kontroleru příchozího přenosu dat a pravidel příchozího přenosu dat můžete pomocí jedné IP adresy směrovat provoz do více služeb v clusteru Kubernetes. Certifikáty TLS můžete vygenerovat pomocí rozpoznané certifikační autority. Alternativně můžete použít funkci Let's Encrypt k automatickému generování certifikátů TLS s dynamickou veřejnou IP adresou nebo se statickou veřejnou IP adresou. Další informace najdete v tématu Vytvoření kontroleru příchozího přenosu dat HTTPS a použití vlastních certifikátů TLS v AKS.
  • Striktní koordinace mezi operátorem služby Azure Firewall a clusterem a týmy úloh je nezbytná jak pro počáteční nasazení clusteru, tak i v průběhu vývoje úloh aclusterch To platí zejména v případě, že konfigurujete mechanismy ověřování, jako je OAuth 2.0 a OpenID Connect, které úlohy používají k ověřování svých klientů.
  • Následující pokyny vám pomůžou zabezpečit prostředí popsané v tomto článku:

Dostupnost a spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

Požadavky na dostupnost a spolehlivost nejsou specifické pro víceklientské prostředí v AKS. Věříme, že jsou pro toto řešení zásadní požadavky. Zvažte následující metody optimalizace dostupnosti clusteru a úloh AKS.

Odolnost uvnitř oblastí

  • Během nasazování můžete nakonfigurovat službu Azure Firewall tak, aby se více zón dostupnosti za účelem zvýšení dostupnosti rozšířilo. Procento doby provozu najdete ve sla služby Azure Firewall. Azure Firewall můžete také přidružit ke konkrétní zóně kvůli blízkosti, i když tato konfigurace ovlivňuje smlouvu SLA. Za bránu firewall nasazenou v zóně dostupnosti, včetně přenosů dat mezi zónami dostupnosti, nejsou žádné další poplatky.
  • Zvažte nasazení fondů uzlů clusteru AKS napříč všemi zónami dostupnosti v oblasti. Před fondy uzlů použijte Azure Standard Load Balancer nebo Application Gateway. Tato topologie poskytuje lepší odolnost, pokud dojde k výpadku jednoho datacentra. Uzly clusteru se distribuují napříč několika datovými centry ve třech samostatných zónách dostupnosti v rámci oblasti.
  • Povolení redundance zón ve službě Container Registry pro zajištění odolnosti uvnitř oblastí a vysoké dostupnosti
  • Pomocí omezení šíření topologie podů můžete řídit, jak se pody šíří napříč clusterem AKS mezi domény selhání, jako jsou oblasti, zóny dostupnosti a uzly.
  • Zvažte použití smlouvy SLA pro dobu provozu pro clustery AKS, které hostují klíčové úlohy. Smlouva SLA o provozu je volitelná funkce, která umožňuje finančně zajištěnou vyšší smlouvu SLA pro cluster. Smlouva SLA pro dobu provozu zaručuje vysokou dostupnost koncového bodu serveru rozhraní Kubernetes API pro clustery, které používají zóny dostupnosti. Můžete ho také použít pro clustery, které nepoužívají zóny dostupnosti, ale smlouva SLA je nižší. Podrobnosti o sla najdete v tématu Smlouva SLA o provozu. AKS k zajištění splnění požadavků smlouvy SLA využívá repliky hlavního uzlu napříč aktualizačními doménami a doménami selhání.

Zotavení po havárii a provozní kontinuita

  • Zvažte nasazení řešení do alespoň dvou spárovaných oblastí Azure v rámci geografické oblasti. K zajištění provozní kontinuity a zotavení po havárii použijte globální nástroj pro vyrovnávání zatížení, jako je Azure Traffic Manager nebo Azure Front Door, s metodou aktivního/aktivního nebo pasivního směrování.
  • Azure Firewall je regionální služba. Pokud řešení nasadíte ve dvou nebo více oblastech, musíte v každé oblasti vytvořit bránu Azure Firewall. Můžete vytvořit globální zásadu služby Azure Firewall, která budou obsahovat pravidla v rámci organizace, která se vztahují na všechna regionální centra. Tuto zásadu můžete použít jako nadřazenou zásadu pro místní zásady Azure. Zásady vytvořené s neprázdnými nadřazenými zásadami dědí všechny kolekce pravidel z nadřazené zásady. Kolekce pravidel sítě zděděné z nadřazené zásady jsou vždy upřednostňované nad kolekcemi pravidel sítě, které jsou definovány jako součást nové zásady. Stejná logika platí pro kolekce pravidel aplikace. Kolekce pravidel sítě se ale vždy zpracovávají před kolekcemi pravidel aplikace bez ohledu na dědičnost. Další informace o zásadách Standard a Premium najdete v přehledu zásad Azure Firewall Manageru.
  • Nezapomeňte skriptovat, dokumentovat a pravidelně testovat všechny místní procesy převzetí služeb při selhání v prostředí kontroly kvality. Tím se vyhnete nepředvídatelným problémům, pokud dojde k výpadku základní služby v primární oblasti. Tyto testy také kontrolují, jestli přístup zotavení po havárii splňuje cíle RPO/RTO ve spojení s případnými ručními procesy a zásahy potřebnými pro převzetí služeb při selhání.
  • Nezapomeňte otestovat postupy navrácení služeb po obnovení, abyste ověřili, že fungují podle očekávání.
  • Uložte image kontejneru ve službě Container Registry. Geograficky replikujte registr do každé oblasti AKS. Další informace najdete v tématu Geografická replikace ve službě Azure Container Registry.
  • Pokud je to možné, vyhněte se ukládání stavu služby v kontejneru. Místo toho použijte Azure PaaS, která podporuje replikaci mezi oblastmi.
  • Pokud používáte Azure Storage, připravte a otestujte proces migrace úložiště z primární oblasti do oblasti zálohování.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.

DevOps

  • Nasaďte úlohy do AKS pomocí chartu Helm v kanálu kontinuální integrace a průběžného doručování (CI/CD). Použijte systém DevOps, jako je GitHub Actions nebo Azure DevOps. Další informace najdete v tématu Sestavení a nasazení do služby Azure Kubernetes Service.
  • Pokud chcete aplikaci správně otestovat, než ji zpřístupníte uživatelům, použijte testování A/B a kanárské nasazení ve správě životního cyklu aplikace. Existuje několik technik, které můžete použít k rozdělení provozu mezi různé verze stejné služby. Jako alternativu můžete použít možnosti rozdělení provozu, které poskytuje implementace sítě služeb. Další informace najdete v tématu Rozdělení provozu Linkerd a Správa provozu Istio.
  • K uložení privátních imagí Dockeru nasazených do clusteru použijte Azure Container Registry nebo jiný registr kontejneru (například Docker Hub). AKS se může ověřit pomocí služby Azure Container Registry pomocí své identity Microsoft Entra.
  • Otestujte příchozí a výchozí přenos dat vašich úloh v samostatném předprodukčním prostředí, které zrcadlí topologii sítě a pravidla brány firewall vašeho produkčního prostředí. Strategie postupného zavedení vám pomůže odhalit všechny problémy se sítí nebo zabezpečením před vydáním nové funkce nebo pravidla sítě do produkčního prostředí.

Sledování

Azure Firewall je plně integrovaný se službou Azure Monitor pro protokolování příchozího a odchozího provozu zpracovávaného bránou firewall. Další informace najdete v tématu Filtrování na základě analýzy hrozeb na základě služby Azure Firewall.

Následující aspekty monitorování nejsou specifické pro víceklientské prostředí v AKS, ale věříme, že jsou pro toto řešení nezbytné požadavky.

  • Pomocí Přehledů kontejnerů můžete monitorovat stav clusteru a úloh AKS.
  • Nakonfigurujte všechny služby PaaS (jako je Container Registry a Key Vault) pro shromažďování diagnostických protokolů a metrik.

Optimalizace nákladů

Náklady na výslednou architekturu závisí na následujících podrobnostech konfigurace:

  • Úrovně služby
  • Škálovatelnost (počet instancí, které se dynamicky přidělují službami pro podporu dané poptávky)
  • Skripty pro Automation
  • Úroveň zotavení po havárii

Po posouzení těchto podrobností o konfiguraci použijte cenovou kalkulačku Azure k odhadu nákladů. Další možnosti optimalizace cen najdete v zásadách optimalizace nákladů v architektuře Microsoft Azure Well-Architected Framework.

Nasazení tohoto scénáře

Zdrojový kód pro tento scénář je k dispozici na GitHubu. Toto řešení je opensourcové a poskytuje se s licencí MIT.

Požadavky

Pro online nasazení potřebujete účet Azure. Pokud ho nemáte, vytvořte si před tím, než začnete, bezplatný účet Azure. Než budete moct nasadit moduly Terraformu pomocí Azure DevOps, musíte splnit tyto požadavky:

  • Uložte soubor stavu Terraformu do účtu úložiště Azure. Další informace o použití účtu úložiště k ukládání vzdáleného stavu Terraformu, uzamčení stavu a šifrování neaktivních uložených dat najdete v tématu Ukládání stavu Terraformu ve službě Azure Storage.
  • Vytvořte projekt Azure DevOps. Další informace najdete v tématu Vytvoření projektu v Azure DevOps.
  • Vytvořte připojení služby Azure DevOps k vašemu předplatnému Azure. Při vytváření připojení služby můžete použít ověřování instančního objektu (SPA) nebo identitu spravované služby Azure. V obou případech se ujistěte, že instanční objekt nebo spravovaná identita používaná Azure DevOps pro připojení k vašemu předplatnému Azure má přiřazenou roli vlastníka pro celé předplatné.

Nasazení do Azure

  1. Dejte si užitečné informace o předplatném Azure.

  2. Naklonujte úložiště Workbench na GitHubu:

    git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git
    
  3. Postupujte podle pokynů uvedených v souboru README.md.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Projděte si doporučení a osvědčené postupy pro AKS v architektuře Microsoft Azure Well-Architected Framework:

Azure Firewall

Azure Kubernetes Service

Doprovodné materiály k architektuře

Referenční architektury