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ů v 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. Pokud chcete zachovat vysokou kvalitu služeb pro vaše aplikace, musíte tyto prostředky strategit a nakonfigurovat.

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

  • Porovnejte síťové režimy kubenet a azure Container Networking Interface (CNI) v AKS.
  • Naplánujte požadované přidělování IP adres a možnosti připojení.
  • Distribuujte provoz pomocí nástrojů pro vyrovnávání zatížení, kontrolerů příchozího přenosu dat nebo firewallu webových aplikací (WAF).
  • Připojte se bezpečně k uzlům clusteru.

Zvolte vhodný model sítě.

Osvědčené postupy

Použití sítí Azure CNI v AKS 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. Existují dva různé způsoby nasazení clusterů AKS do virtuálních sítí:

  • Sítě Azure CNI

    Nasadí se do virtuální sítě a použije modul plug-in Azure CNI Kubernetes. Pody přijímají jednotlivé IP adresy, které můžou směrovat do jiných síťových služeb nebo místních prostředků.

  • Sítě Kubenet

    Azure spravuje prostředky virtuální sítě při nasazování clusteru a používá modul plug-in Kubenet Kubernetes.

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

Sítě CNI

Azure CNI je protokol neutrální z hlediska dodavatele, který modulu runtime kontejneru umožňuje 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 – ke komunikaci s jinými prostředky nebo službami není potřeba další směrování.

Diagram znázorňující dva uzly s mosty propojujícími jednotlivé uzly s jednou virtuální sítí Azure

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 spravily a zabezpečily různé týmy. Se sítí Azure CNI se připojujete ke stávajícím prostředkům Azure, místním prostředkům nebo jiným službám přímo prostřednictvím IP adres přiřazených ke každému podu.

Pokud používáte síť Azure CNI, prostředek virtuální sítě je v samostatné skupině prostředků clusteru AKS. Delegujte oprávnění pro identitu clusteru AKS pro přístup k těmto prostředkům a jejich správu. 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 použití předdefinované role Přispěvatel sítě definovat vlastní roli , jsou vyžadována 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 pro svoji identitu clusteru spravovanou identitu. Místo toho ale můžete použít instanční objekt. Další informace:

Vzhledem k tomu, že každý uzel a pod obdrží vlastní IP adresu, naplánujte rozsahy adres pro podsítě AKS. Pamatujte si, že:

  • Podsíť musí být dostatečně velká, aby poskytovala IP adresy pro každý nasazený uzel, pody a síťový prostředek.
    • U sítí kubenet i Azure CNI má každý spuštěný uzel výchozí omezení počtu podů.
  • Každý cluster AKS musí být umístěný ve své vlastní podsíti.
  • Nepoužívejte rozsahy IP adres, které se překrývají se stávajícími síťovými prostředky.
    • Nezbytné k umožnění připojení k místním sítím nebo partnerským sítím v Azure.
  • Ke zpracování událostí škálování na více instancí nebo upgradů clusteru potřebujete v přiřazené podsíti k dispozici další IP adresy.
    • 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.

Informace o výpočtu požadované IP adresy najdete v tématu Konfigurace sítí Azure CNI v AKS.

Při vytváření clusteru se sítěmi Azure CNI zadáte další rozsahy adres clusteru, například adresu mostu Docker, IP adresu služby DNS a rozsah adres služby. Obecně se ujistěte, že se jedná o tyto rozsahy adres:

  • Nepřekrývejte se.
  • Nepřekrývejte se se žádnými sítěmi přidruženými ke clusteru, včetně virtuálních sítí, podsítí, místních sítí a partnerských sítí.

Konkrétní podrobnosti o omezeních 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 nastavení virtuálních sítí před nasazením clusteru, čekání má své nevýhody:

  • Vzhledem k tomu, že uzly a pody jsou umístěné v různých podsítích PROTOKOLU IP, směrování definované uživatelem (UDR) a předávání IP směruje provoz mezi pody a uzly. Toto dodatečné směrování může snížit výkon sítě.
  • Připojení ke stávajícím místním sítím nebo partnerský vztah k jiným virtuálním sítím Azure mohou být složitá.

Vzhledem k tomu, že virtuální síť a podsítě nevytáčíte odděleně od clusteru AKS, je Kubenet ideální pro:

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

U většiny produkčních nasazení byste měli naplánovat a používat sítě Azure CNI.

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

Konkrétní podrobnosti o omezeních 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 provozu

Osvědčené postupy

K distribuci provozu 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í ve vašem clusteru AKS, je omezený na pochopení takového 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í použí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 zpracovávat ukončení protokolu TLS/SSL. Příchozí přenos dat také snižuje počet IP adres, které zveřejňujete a mapujete.

U nástroje pro vyrovnávání zatížení musí každá aplikace obvykle přiřadit veřejnou IP adresu, která je namapovaná 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í.

Diagram znázorňující tok příchozího provozu v clusteru AKS

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

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

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

Prostředek příchozího přenosu dat je manifest YAML .kind: Ingress 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 manifestu YAML by distribuoval provoz pro myapp.com do jedné ze dvou služeb, blogservice nebo storeservice. Zákazník je přesměrován na jednu nebo druhou službu na základě adresy URL, ke které přistupuje.

kind: Ingress
metadata:
 name: myapp-ingress
   annotations: kubernetes.io/ingress.class: "PublicIngress"
spec:
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         serviceName: blogservice
         servicePort: 80
      - path: /store
        backend:
         serviceName: storeservice
         servicePort: 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. I když je nejběžnější kontroler příchozího přenosu dat založený na NGINX, AKS vás neomezuje na konkrétní kontroler. Můžete použít Contour, HAProxy, Traefik atd.

Kontrolery příchozího přenosu dat musí být naplánované na linuxovém uzlu. Označte, že by se prostředek měl spustit na uzlu se systémem Linux pomocí selektoru uzlů v nasazení manifestu YAML nebo chartu Helm. Další informace najdete v tématu Použití selektorů uzlů k řízení plánování podů v AKS.

Poznámka

V uzlech Windows Serveru by se kontroler příchozího přenosu dat neměl spouštět.

Existuje mnoho scénářů pro příchozí přenos dat, včetně následujících návodů:

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

Osvědčené postupy

Pokud chcete zkontrolovat potenciální útoky v příchozím provozu, použijte firewall webových aplikací (WAF), jako je Barracuda WAF pro Azure nebo Azure Application Gateway. Tyto pokročilejší síťové prostředky také můžou směrovat provoz nad rámec jenom 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 budete chtít:

  • Přesměrování části tohoto směrování provozu nebo ukončení protokolu TLS na síťový prostředek mimo cluster AKS
  • Zkontrolujte příchozí provoz z hlediska potenciálních útoků.

Firewall webových aplikací (WAF), jako je Aplikace Azure Gateway, může chránit a distribuovat provoz pro váš cluster AKS.

Pro další vrstvu zabezpečení filtruje příchozí provoz firewall webových aplikací (WAF). Pomocí sady pravidel OWASP (Open Web Application Security Project) sleduje útoky, jako je skriptování mezi weby nebo otrava soubory cookie. Azure Application Gateway (aktuálně ve verzi Preview v AKS) je WAF, který se integruje s clustery AKS a zamkne tyto funkce zabezpečení předtím, než provoz dorazí do vašeho 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 v preferovaném produktu.

Prostředky nástroje pro vyrovnávání zatížení nebo příchozího přenosu dat neustále běží ve vašem 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 tím, že vytvoříte kontroler příchozího přenosu dat Application Gateway.

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

Osvědčené postupy

Pomocí zásad sítě můžete povolit nebo zakázat provoz do podů. Ve výchozím nastavení je veškerý provoz mezi pody v rámci 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. Provoz do podu povolíte nebo zakážete na základě nastavení, jako jsou přiřazené popisky, obor názvů nebo přenosový port. Zásady sítě představují nativní cloudový způsob řízení toku provozu pro pody. Při dynamickém vytváření podů 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ě. Předem naplánujte povolení zásad sítě na potřebných clusterech.

Poznámka

Zásady sítě by se měly používat jenom pro uzly a pody založené na Linuxu v AKS.

Zásady sítě vytvoříte jako prostředek Kubernetes pomocí manifestu YAML. Zásady se použijí na definované pody, přičemž tok provozu definují pravidla příchozího nebo výchozího přenosu dat.

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

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ě v Azure Kubernetes Service (AKS).

Zabezpečené připojení k uzlům prostřednictvím hostitele bastionu

Osvědčené postupy

Nezpřístupňujte vzdálené připojení k uzlům AKS. Ve virtuální síti pro správu vytvořte hostitele bastionu neboli jump box. Pomocí hostitele bastionu můžete bezpečně směrovat provoz do clusteru AKS na úlohy vzdálené správy.

Většinu operací v AKS můžete provádět 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 se tento hostitel nachází v samostatné virtuální síti pro správu s virtuální sítí clusteru AKS s bezpečným partnerským vztahem.

Připojení k uzlům AKS pomocí hostitele bastionu nebo jump boxu

Síť pro správu pro hostitele bastionu by měla být také zabezpečená. K připojení k místní síti a řízení přístupu pomocí skupin zabezpečení sítě použijte azure ExpressRoute nebo bránu VPN .

Další kroky

Tento článek se zaměřil na připojení k síti a zabezpečení. Další informace o základech sítě v Kubernetes najdete v tématu Koncepty sítě pro aplikace v Azure Kubernetes Service (AKS).