Osvědčené postupy pro připojení k síti a zabezpečení ve službě Azure Kubernetes Service (AKS)

Při vytváření a správě clusterů ve službě Azure Kubernetes Service (AKS) poskytujete síťové připojení pro uzly a aplikace. Mezi tyto síťové prostředky patří rozsahy IP adres, nástroje pro vyrovnávání zatížení a kontrolery příchozího přenosu dat.

Tento článek s osvědčenými postupy se zaměřuje na síťové připojení a zabezpečení pro operátory clusteru. V tomto článku získáte informace o těchto tématech:

Volba vhodného síťového modelu

Pokyny k osvědčeným postupům

Sítě Azure CNI v AKS slouží k integraci se stávajícími virtuálními sítěmi nebo místními sítěmi. Tento síťový model umožňuje větší oddělení prostředků a ovládacích prvků v podnikovém prostředí.

Virtuální sítě poskytují základní připojení pro uzly AKS a zákazníky pro přístup k vašim aplikacím. Clustery AKS můžete nasadit do virtuálních sítí dvěma různými způsoby:

• Sítě Azure CNI: Nasadí se do virtuální sítě a používá modul plug-in Azure CNI Kubernetes. Pody přijímají jednotlivé IP adresy, které můžou směrovat na jiné síťové služby nebo místní prostředky.
• Sítě Kubenet: Azure spravuje prostředky virtuální sítě při nasazení clusteru a používá modul plug-in kubenet Kubernetes.

Azure CNI i kubenet jsou platné možnosti pro produkční nasazení.

Sítě CNI

Azure CNI je protokol neutrální dodavatele, který umožňuje modulu runtime kontejneru provádět požadavky na poskytovatele sítě. Přiřazuje IP adresy podům a uzlům a poskytuje funkce správy IP adres (IPAM) při připojování k existujícím virtuálním sítím Azure. Každý uzel a prostředek podu obdrží IP adresu ve virtuální síti Azure. Není potřeba další směrování ke komunikaci s jinými prostředky nebo službami.

Zejména sítě Azure CNI pro produkční prostředí umožňují oddělení kontroly a správy prostředků. Z hlediska zabezpečení často chcete, aby tyto prostředky spravovály a zabezpečily různé týmy. Pomocí sítí Azure CNI se připojíte k existujícím prostředkům Azure, místním prostředkům nebo jiným službám přímo přes IP adresy přiřazené k jednotlivým podům.

Pokud používáte sítě Azure CNI, prostředek virtuální sítě je v samostatné skupině prostředků pro cluster AKS. Delegujte oprávnění pro identitu clusteru AKS pro přístup k těmto prostředkům a jejich správě. Identita clusteru používaná clusterem AKS musí mít v podsíti ve vaší virtuální síti alespoň oprávnění Přispěvatel sítě.

Pokud chcete místo předdefinované role Přispěvatel sítě definovat vlastní roli , musíte mít následující oprávnění:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Ve výchozím nastavení používá AKS spravovanou identitu pro svou identitu clusteru. Místo toho ale můžete použít instanční objekt.

• Další informace o delegování instančního objektu AKS najdete v tématu Delegování přístupu k jiným prostředkům Azure.
• Další informace o spravovaných identitách najdete v tématu Použití spravovaných identit.

Jakmile každý uzel a pod obdrží svou vlastní IP adresu, naplánujte rozsahy adres pro podsítě AKS. Mějte na paměti následující kritéria:

• Podsíť musí být dostatečně velká, aby poskytovala IP adresy pro každý uzel, pod a síťový prostředek, který nasadíte.
  • U sítí kubenet i Azure CNI má každý spuštěný uzel výchozí omezení počtu podů.
• Nepoužívejte rozsahy IP adres, které se překrývají s existujícími síťovými prostředky.
  • Je potřeba povolit připojení k místním nebo partnerským sítím v Azure.
• Pokud chcete zpracovávat události horizontálního navýšení kapacity nebo upgrady clusteru, potřebujete další IP adresy dostupné v přiřazené podsíti.
  • Tento dodatečný adresní prostor je zvlášť důležitý, pokud používáte kontejnery Windows Serveru, protože tyto fondy uzlů vyžadují upgrade, aby se použily nejnovější opravy zabezpečení. Další informace o uzlech Windows Serveru najdete v tématu Upgrade fondu uzlů v AKS.

Pokud chcete vypočítat požadovanou IP adresu, přečtěte si téma Konfigurace sítí Azure CNI v AKS.

Při vytváření clusteru se sítěmi Azure CNI zadáte další rozsahy adres pro cluster, jako je adresa mostu Dockeru, IP adresa služby DNS a rozsah adres služby. Obecně se ujistěte, že se tyto rozsahy adres navzájem nepřekrývají ani žádné sítě přidružené ke clusteru, včetně všech virtuálních sítí, podsítí, místních sítí a partnerských sítí.

Konkrétní podrobnosti týkající se limitů a velikosti těchto rozsahů adres najdete v tématu Konfigurace sítí Azure CNI v AKS.

Sítě Kubenet

I když kubenet nevyžaduje konfiguraci virtuálních sítí před nasazením clusteru, existují nevýhody čekání, například:

• Vzhledem k tomu, že uzly a pody jsou umístěny v různých podsítích IP adres, směrování definované uživatelem (UDR) a předávání IP směrují provoz mezi pody a uzly. Toto další směrování může snížit výkon sítě.
• Připojení k existujícím místním sítím nebo peeringu s jinými virtuálními sítěmi Azure můžou být složitá.

Vzhledem k tomu, že virtuální síť a podsítě nevytvoříte odděleně od clusteru AKS, je Kubenet ideální pro následující scénáře:

• Malé úlohy vývoje nebo testování
• Jednoduché weby s nízkým provozem.
• Zvedání a přesouvání úloh do kontejnerů

Pro produkční nasazení jsou platné možnosti kubenetu i Azure CNI. Prostředí, která vyžadují oddělení řízení a správy, azure CNI může upřednostňovanou možnost. Kromě toho je kubenet vhodný jenom pro linuxová prostředí, kde zachování rozsahu IP adres je prioritou.

Můžete také nakonfigurovat vlastní rozsahy IP adres a virtuální sítě pomocí kubenetu. Podobně jako sítě Azure CNI by se tyto rozsahy adres neměly překrývat mezi sebou ani žádné sítě přidružené ke clusteru (virtuální sítě, podsítě, místní a partnerské sítě).

Konkrétní podrobnosti týkající se limitů a velikosti těchto rozsahů adres najdete v tématu Použití sítí kubenet s vlastními rozsahy IP adres v AKS.

Distribuce příchozího přenosu dat

Pokyny k osvědčeným postupům

Pokud chcete distribuovat provoz HTTP nebo HTTPS do vašich aplikací, použijte prostředky a kontrolery příchozího přenosu dat. V porovnání s nástrojem pro vyrovnávání zatížení Azure poskytují kontrolery příchozího přenosu dat další funkce a dají se spravovat jako nativní prostředky Kubernetes.

I když nástroj pro vyrovnávání zatížení Azure může distribuovat zákaznický provoz do aplikací v clusteru AKS, je omezený na pochopení provozu. Prostředek nástroje pro vyrovnávání zatížení funguje ve vrstvě 4 a distribuuje provoz na základě protokolu nebo portů.

Většina webových aplikací využívajících PROTOKOL HTTP nebo HTTPS by měla používat prostředky a kontrolery příchozího přenosu dat Kubernetes, které fungují ve vrstvě 7. Příchozí přenos dat může distribuovat provoz na základě adresy URL aplikace a zpracovat ukončení protokolu TLS/SSL. Příchozí přenos dat také snižuje počet IP adres, které zveřejňujete a mapujete.

S nástrojem pro vyrovnávání zatížení každá aplikace obvykle potřebuje přiřazenou veřejnou IP adresu a namapovanou na službu v clusteru AKS. S prostředkem příchozího přenosu dat může jedna IP adresa distribuovat provoz do více aplikací.

Pro příchozí přenos dat existují dvě komponenty:

1. Prostředek příchozího přenosu dat
2. Kontroler příchozího přenosu dat

Prostředek příchozího přenosu dat

Prostředek příchozího přenosu dat je manifestEM kind: IngressYAML . Definuje hostitele, certifikáty a pravidla pro směrování provozu do služeb spuštěných v clusteru AKS.

Následující příklad manifest YAML distribuuje provoz pro myapp.com do jedné ze dvou služeb, blogservice nebo storeservice a přesměruje zákazníka na jednu službu nebo druhou na základě adresy URL, ke které přistupuje.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Kontroler příchozího přenosu dat

Kontroler příchozího přenosu dat je proces démon, který běží na uzlu AKS a sleduje příchozí požadavky. Provoz se pak distribuuje na základě pravidel definovaných v prostředku příchozího přenosu dat. Zatímco nejběžnější kontroler příchozího přenosu dat je založený na NGINX, AKS vás neomezuje na konkrétní kontroler. Můžete použít Obrys, HAProxy, Traefik atd.

Kontrolery příchozího přenosu dat musí být naplánované na linuxovém uzlu. Označte, že prostředek by se měl spustit na uzlu založeném na Linuxu pomocí selektoru uzlu v manifestu YAML nebo v nasazení chartu Helm. Další informace naleznete v tématu Použití selektorů uzlů k řízení, kde jsou pody naplánované v AKS.

Příchozí přenos dat pomocí doplňku směrování aplikace

Doplněk směrování aplikací je doporučený způsob konfigurace kontroleru příchozího přenosu dat v AKS. Doplněk směrování aplikací je plně spravovaný kontroler příchozího přenosu dat pro Službu Azure Kubernetes Service (AKS), který poskytuje následující funkce:

• Snadná konfigurace spravovaných kontrolerů příchozího přenosu dat NGINX na základě kontroleru příchozího přenosu dat NGINX Kubernetes

• Integrace s Azure DNS pro správu veřejných a privátních zón

• Ukončení protokolu SSL s certifikáty uloženými ve službě Azure Key Vault

Další informace o doplňku směrování aplikací najdete v tématu Spravované příchozí přenosy dat NGINX s doplňkem směrování aplikace.

Zabezpečení provozu pomocí firewallu webových aplikací (WAF)

Pokyny k osvědčeným postupům

Ke kontrole příchozího provozu potenciálních útoků použijte firewall webových aplikací (WAF), jako je Barracuda WAF pro Azure nebo Aplikace Azure lication Gateway. Tyto pokročilejší síťové prostředky můžou také směrovat provoz nad rámec pouze připojení HTTP a HTTPS nebo základního ukončení protokolu TLS.

Kontroler příchozího přenosu dat je obvykle prostředek Kubernetes ve vašem clusteru AKS, který distribuuje provoz do služeb a aplikací. Kontroler běží jako démon na uzlu AKS a využívá některé prostředky uzlu, jako je procesor, paměť a šířka pásma sítě. Ve větších prostředích můžete zvážit následující:

• Přesměrujte některé z těchto přenosů směrování nebo ukončení protokolu TLS na síťový prostředek mimo cluster AKS.
• Zkontrolujte potenciální útoky na příchozí provoz.

U této další vrstvy zabezpečení filtruje příchozí provoz firewall webových aplikací (WAF). Se sadou pravidel sleduje projekt OWASP (Open Web Application Security Project) útoky, jako je skriptování mezi weby nebo otrava soubory cookie. Aplikace Azure lication Gateway (aktuálně ve verzi Preview v AKS) je WAF, který se integruje s clustery AKS a uzamkne tyto funkce zabezpečení předtím, než provoz dosáhne clusteru a aplikací AKS.

Vzhledem k tomu, že tyto funkce provádějí i jiná řešení třetích stran, můžete i nadále využívat stávající investice nebo odborné znalosti vašeho preferovaného produktu.

Nástroj pro vyrovnávání zatížení nebo prostředky příchozího přenosu dat se průběžně spouštějí v clusteru AKS a zpřesní distribuci provozu. App Gateway je možné centrálně spravovat jako kontroler příchozího přenosu dat s definicí prostředku. Začněte vytvořením kontroleru příchozího přenosu dat služby Application Gateway.

Řízení toku provozu pomocí zásad sítě

Pokyny k osvědčeným postupům

Pomocí zásad sítě povolte nebo zamítněte provoz do podů. Ve výchozím nastavení je veškerý provoz mezi pody v clusteru povolený. Pro lepší zabezpečení definujte pravidla, která omezují komunikaci podů.

Zásady sítě jsou funkce Kubernetes dostupná v AKS, která umožňuje řídit tok provozu mezi pody. Povolíte nebo zakážete provoz do podu na základě nastavení, jako jsou přiřazené popisky, obor názvů nebo port provozu. Zásady sítě představují nativní způsob, jak řídit tok provozu podů. Vzhledem k tomu, že se pody dynamicky vytvářejí v clusteru AKS, je možné automaticky použít požadované zásady sítě.

Pokud chcete použít zásady sítě, povolte tuto funkci při vytváření nového clusteru AKS. V existujícím clusteru AKS nemůžete povolit zásady sítě. Naplánujte si dopředu povolení zásad sítě v nezbytných clusterech.

Zásady sítě vytvoříte jako prostředek Kubernetes pomocí manifestu YAML. Zásady se použijí na definované pody s příchozím nebo výstupním pravidlem definujícím tok provozu.

Následující příklad aplikuje zásady sítě na pody s aplikací: back-endový popisek použitý na ně. Pravidlo příchozího přenosu dat povoluje provoz jenom z podů s aplikací: popisek front-endu .

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Pokud chcete začít se zásadami, přečtěte si téma Zabezpečení provozu mezi pody pomocí zásad sítě ve službě Azure Kubernetes Service (AKS).

Bezpečné připojení k uzlům prostřednictvím hostitele bastionu

Pokyny k osvědčeným postupům

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. Pomocí hostitele bastionu bezpečně směrujte provoz do clusteru AKS do úloh vzdálené správy.

Většinu operací v AKS můžete dokončit pomocí nástrojů pro správu Azure nebo prostřednictvím serveru rozhraní API Kubernetes. Uzly AKS jsou dostupné jenom v privátní síti a nejsou připojené k veřejnému internetu. Pokud se chcete připojit k uzlům a zajistit údržbu a podporu, nasměrujte připojení přes hostitele bastionu nebo jump box. Ověřte, že tento hostitel žije v samostatné zabezpečené virtuální síti pro správu v partnerském vztahu s virtuální sítí clusteru AKS.

Měli byste také zabezpečit síť pro správu pro hostitele bastionu. Pomocí azure ExpressRoute nebo brány VPN se můžete připojit k místní síti a řídit přístup pomocí skupin zabezpečení sítě.

Další kroky

Tento článek se zaměřuje na síťové připojení a zabezpečení. Další informace o základech sítě v Kubernetes najdete v tématu Koncepty sítě pro aplikace ve službě Azure Kubernetes Service (AKS).