Zabezpečení provozu mezi lusky pomocí zásad sítě ve službě Azure Kubernetes Service (AKS)

Když v Kubernetes spustíte moderní aplikace založené na mikroslužbách, často chcete určit, které součásti můžou vzájemně komunikovat. Zásada minimálního oprávnění by měla být použita na to, jak přenos dat může procházet mezi lusky v clusteru služby Azure Kubernetes (AKS). Řekněme, že pravděpodobně chcete zablokovat provoz přímo do back-endové aplikace. Funkce zásady sítě v Kubernetes vám umožňuje definovat pravidla pro příchozí a odchozí provoz mezi lusky v clusteru.

V tomto článku se dozvíte, jak nainstalovat modul zásad sítě a vytvořit zásady sítě Kubernetes pro řízení toku provozu mezi lusky v AKS. Zásady sítě by se měly používat jenom pro uzly se systémem Linux a lusky v AKS.

Než začnete

Potřebujete nainstalovanou a nakonfigurovanou verzi Azure CLI 2.0.61 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Přehled zásad sítě

Všechny lusky v clusteru AKS můžou ve výchozím nastavení odesílat a přijímat přenosy bez omezení. Pro zvýšení zabezpečení můžete definovat pravidla, která řídí tok přenosů. Back-endové aplikace se často zveřejňují jenom pro požadované front-endové služby, například. Nebo součásti databáze jsou přístupné pouze pro aplikační vrstvy, které k nim připojovat.

Zásada sítě je specifikace Kubernetes, která definuje zásady přístupu pro komunikaci mezi lusky. Pomocí zásad sítě můžete definovat uspořádanou sadu pravidel pro odesílání a příjem provozu a použít je pro kolekci lusků, která odpovídá jednomu nebo více selektorům popisku.

Tato pravidla zásad sítě se definují jako YAML manifesty. Zásady sítě je možné zahrnout do širšího manifestu, který také vytváří nasazení nebo službu.

Možnosti zásad sítě v AKS

Azure poskytuje dva způsoby, jak implementovat zásady sítě. Při vytváření clusteru AKS zvolíte možnost Zásady sítě. Po vytvoření clusteru se možnost Zásady nedá změnit:

• Vlastní implementace Azure označovaná jako zásady sítě Azure.
• Calico zásady sítě, což je open source řešení zabezpečení sítě a sítě založené na Tigera.

Obě implementace používají Linux softwaru iptables k vykonání zadaných zásad. Zásady jsou přeloženy do sad povolených a nepovolených párů IP adres. Tyto páry se pak naprogramují jako pravidla filtru IPTable.

Rozdíly mezi zásadami Azure a Calico a jejich funkcemi

Vytvoření clusteru AKS a povolení zásad sítě

Pokud chcete zobrazit zásady sítě v akci, vytvoříme a pak rozbalíme zásadu, která definuje tok přenosů:

• Odepřít veškerý provoz do pod.
• Povoluje provoz na základě popisků pod.
• Povolte provoz založený na oboru názvů.

Nejdřív vytvořte cluster AKS, který podporuje zásady sítě.

Pokud chcete používat zásady sítě Azure, musíte použít modul plug-in Azure CNI a definovat vlastní virtuální síť a podsítě. Podrobnější informace o tom, jak naplánovat požadované rozsahy podsítí, najdete v tématu Konfigurace pokročilých sítí. Zásady sítě Calico se daly použít buď s tímto stejným modulem plug-in Azure CNI, nebo s modulem plug-in Kubenet CNI.

Následující vzorový skript:

• Vytvoří virtuální síť a podsíť.
• vytvoří instanční objekt služby Azure Active Directory (Azure AD) pro použití s clusterem AKS.
• Přiřadí oprávnění přispěvatele pro objekt služby Cluster AKS ve virtuální síti.
• Vytvoří v definované virtuální síti cluster AKS a povolí zásady sítě.
  • Použije se možnost zásady sítě Azure . Pokud chcete místo toho použít Calico jako zásadu sítě, použijte --network-policy calico parametr. Poznámka: Calico lze použít s buď --network-plugin azure nebo --network-plugin kubenet .

Všimněte si, že místo použití instančního objektu můžete pro oprávnění použít spravovanou identitu. Další informace najdete v tématu použití spravovaných identit.

Zadejte vlastní zabezpečený sp_password. Můžete nahradit proměnné RESOURCE_GROUP_NAME a CLUSTER_NAME :

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --role Contributor --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

Vytvoření clusteru AKS pro zásady sítě Azure

Vytvořte cluster AKS a zadejte virtuální síť, informace o instančním objektu a Azure pro modul plug-in sítě a zásady sítě.

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-plugin azure \
    --network-policy azure

Vytvoření clusteru bude trvat několik minut. Až bude cluster připravený, nakonfigurujte kubectl pro připojení ke clusteru Kubernetes pomocí příkazu AZ AKS Get-Credentials . Tento příkaz stáhne přihlašovací údaje a nakonfiguruje rozhraní příkazového řádku Kubernetes pro jejich použití:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Vytvoření clusteru AKS pro zásady sítě Calico

Vytvořte cluster AKS a zadejte virtuální síť, informace o instančním objektu, službu Azure pro modul plug-in sítě a Calico pro zásady sítě. použití calico jako zásady sítě umožňuje sítě calico na fondech Linux i Windows.

pokud plánujete přidat do clusteru Windows fondy uzlů, zahrňte windows-admin-username windows-admin-password parametry a, které splňují požadavky na heslo Windows serveru. chcete-li používat Calico s fondy uzlů Windows, je také nutné zaregistrovat Microsoft.ContainerService/EnableAKSWindowsCalico .

Zaregistrujte EnableAKSWindowsCalico příznak funkce pomocí příkazu AZ Feature Register , jak je znázorněno v následujícím příkladu:

az feature register --namespace "Microsoft.ContainerService" --name "EnableAKSWindowsCalico"

Stav registrace můžete zjistit pomocí příkazu AZ Feature list :

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAKSWindowsCalico')].{Name:name,State:properties.state}"

Až budete připraveni, aktualizujte registraci poskytovatele prostředků Microsoft. ContainerService pomocí příkazu AZ Provider Register :

az provider register --namespace Microsoft.ContainerService

zásady sítě Calico s uzly Windows jsou momentálně ve verzi preview.

vytvořte uživatelské jméno, které se použije jako přihlašovací údaje správce pro kontejnery Windows serveru v clusteru. Následující příkazy zobrazí výzvu k zadání uživatelského jména a nastaví WINDOWS_USERNAME pro použití v pozdějším příkazu (Nezapomeňte, že příkazy v tomto článku jsou zadány do prostředí BASH).

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --windows-admin-username $WINDOWS_USERNAME \
    --vm-set-type VirtualMachineScaleSets \
    --kubernetes-version 1.20.2 \
    --network-plugin azure \
    --network-policy calico

Vytvoření clusteru bude trvat několik minut. Ve výchozím nastavení se cluster vytvoří jenom s fondem uzlů Linux. pokud chcete použít fondy uzlů Windows, můžete je přidat. Například:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Až bude cluster připravený, nakonfigurujte kubectl pro připojení ke clusteru Kubernetes pomocí příkazu AZ AKS Get-Credentials . Tento příkaz stáhne přihlašovací údaje a nakonfiguruje rozhraní příkazového řádku Kubernetes pro jejich použití:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Odepřít veškerý příchozí provoz do pod

Před definováním pravidel pro povolení konkrétního síťového provozu vytvořte nejprve zásadu sítě, která zamítne veškerý provoz. Tato zásada vám poskytne výchozí bod pro začátek vytváření povolených jenom pro požadovaný provoz. Můžete také jasně vidět, že při použití zásad sítě dojde k přerušení provozu.

V případě ukázkových prostředí aplikace a pravidel přenosů nejprve vytvoříme obor názvů s názvem vývoj pro spuštění příkladu lusků:

kubectl create namespace development
kubectl label namespace/development purpose=development

Vytvořte příklad back-endu pod, na kterém běží NGINX. Pomocí tohoto back-endu se dá simulovat Ukázková webová aplikace v back-endu. Vytvořte tuto položku pod oborem názvů pro vývoj a otevřete port 80 pro obsloužení webového provozu. Popište ho jako App = WebApp, role = back-end , abyste se mohli na něj zaměřit pomocí zásad sítě v následující části:

kubectl run backend --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --labels app=webapp,role=backend --namespace development --expose --port 80

Vytvořte další pod a připojte relaci terminálu k otestování, jestli můžete úspěšně dosáhnout výchozí webové stránky NGINX:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Na příkazovém řádku prostředí použijte wget k potvrzení, že máte přístup k výchozí webové stránce Nginx:

wget -qO- http://backend

Následující vzorový výstup ukazuje, že se vrátila výchozí webová stránka NGINX:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ukončete připojenou relaci Terminálové programu. Test pod je automaticky odstraněn.

exit

Vytvoření a použití zásad sítě

Teď, když jste se potvrdili, že můžete použít základní webovou stránku NGINX na ukázkovém back-endu pod, vytvořit zásadu sítě, která zamítne veškerý provoz. Vytvořte soubor s názvem backend-policy.yaml a vložte následující manifest YAML. Tento manifest používá podSelector k připojení zásady k luskům, které mají aplikaci: WebApp, role: back-end , jako je ukázka Nginx pod. V rámci příchozího přenosu nejsou definována žádná pravidla, takže veškerý příchozí provoz do uzlu pod je odepřen:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

https://shell.azure.comV prohlížeči otevřete Azure Cloud Shell.

Použijte zásady sítě pomocí příkazu kubectl Apply a zadejte název manifestu YAML:

kubectl apply -f backend-policy.yaml

Testování zásad sítě

Pojďme se podívat, jestli můžete použít webovou stránku NGINX v back-endu pod. Vytvořte další test pod a připojte relaci terminálu:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Na příkazovém řádku prostředí použijte wget k zobrazení, zda máte přístup k výchozí webové stránce Nginx. Tentokrát nastavte hodnotu časového limitu na 2 sekund. Zásada sítě teď blokuje veškerý příchozí provoz, takže stránku nejde načíst, jak je znázorněno v následujícím příkladu:

wget -O- --timeout=2 --tries=1 http://backend

wget: download timed out

Ukončete připojenou relaci Terminálové programu. Test pod je automaticky odstraněn.

exit

Povolit příchozí provoz na základě popisku pod

V předchozí části se naplánoval back-end NGINX pod tím, že se vytvořila zásada sítě pro zamítnutí veškerého provozu. Pojďme vytvořit front-end pod a aktualizovat zásady sítě tak, aby umožňovaly provoz z front-endovéch lusků.

Aktualizujte zásady sítě tak, aby povolovaly provoz z lusků s aplikací Labels : WebApp, role: front-end a v jakémkoli oboru názvů. Upravte předchozí soubor back-end-Policy. yaml a přidejte matchLabels pravidla pro příchozí, aby váš manifest vypadal jako v následujícím příkladu:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

Použijte aktualizované zásady sítě pomocí příkazu kubectl Apply a zadejte název manifestu YAML:

kubectl apply -f backend-policy.yaml

Naplánujte pod označený jako App = WebApp, role = front-end a připojte relaci terminálu:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

Na příkazovém řádku prostředí použijte wget k zobrazení, zda máte přístup k výchozí webové stránce Nginx:

wget -qO- http://backend

Vzhledem k tomu, že pravidlo příchozího přenosu dat povoluje provoz s lusky, které mají aplikaci Labels : WebApp, role: front-end, je povolen provoz z front-endu pod. Následující příklad výstupu ukazuje výchozí webovou stránku NGINX, která se vrátila:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ukončete připojenou relaci Terminálové programu. Pole pod je automaticky odstraněno.

exit

Test pod bez odpovídajícího popisku

Zásady sítě umožňují provoz z lusků s označením aplikace: WebApp, role: front-end, ale měla by Odepřít všechny ostatní přenosy. Pojďme se podívat, jestli jiný pod ním bez těchto popisků může mít přístup k back-endové NGINX pod. Vytvořte další test pod a připojte relaci terminálu:

kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --namespace development

Na příkazovém řádku prostředí použijte wget k zobrazení, zda máte přístup k výchozí webové stránce Nginx. Zásada sítě blokuje příchozí provoz, takže nelze načíst stránku, jak je znázorněno v následujícím příkladu:

wget -O- --timeout=2 --tries=1 http://backend

wget: download timed out

Ukončete připojenou relaci Terminálové programu. Test pod je automaticky odstraněn.

exit

Povolení provozu pouze v rámci definovaného oboru názvů

V předchozích příkladech jste vytvořili zásadu sítě, která odepřela veškerý provoz, a pak aktualizovali zásady tak, aby povolovala provoz z lusků s určitým popiskem. Další běžnou potřebou je omezit provoz jenom na v rámci daného oboru názvů. Pokud předchozí příklady byly pro provoz v oboru názvů pro vývoj , vytvořte zásady sítě, které brání provozu z jiného oboru názvů, jako je například Výroba, od dosažení lusků.

Nejdřív vytvořte nový obor názvů pro simulaci produkčního oboru názvů:

kubectl create namespace production
kubectl label namespace/production purpose=production

Naplánujte test pod v produkčním oboru názvů, který je označený jako App = WebApp, role = front-endu. Připojit relaci terminálu:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

Na příkazovém řádku prostředí použijte wget k potvrzení, že máte přístup k výchozí webové stránce Nginx:

wget -qO- http://backend.development

Vzhledem k tomu, že se jmenovky pod shodují s tím, co je aktuálně povoleno v zásadách sítě, je povolen provoz. Zásada sítě se nezobrazuje na oborech názvů, jenom na jmenovky pod. Následující příklad výstupu ukazuje výchozí webovou stránku NGINX, která se vrátila:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ukončete připojenou relaci Terminálové programu. Test pod je automaticky odstraněn.

exit

Aktualizace zásad sítě

Pojďme aktualizovat oddíl namespaceSelector pravidla příchozího přenosu dat, aby povoloval jenom přenosy z oboru názvů pro vývoj . Upravte soubor manifestu back-end-Policy. yaml , jak je znázorněno v následujícím příkladu:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

V složitějších příkladech můžete definovat více pravidel příchozího přenosu dat, jako je namespaceSelector , a pak podSelector.

Použijte aktualizované zásady sítě pomocí příkazu kubectl Apply a zadejte název manifestu YAML:

kubectl apply -f backend-policy.yaml

Otestování aktualizovaných síťových zásad

Naplánujte další pod v produkčním oboru názvů a připojte relaci terminálu:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace production

Na příkazovém řádku prostředí použijte wget k zobrazení, že síťové zásady nyní zakazuje provoz:

wget -O- --timeout=2 --tries=1 http://backend.development

wget: download timed out

Ukončete test pod:

exit

Když se provoz zamítl z produkčního oboru názvů, naplánujte ho zpátky v oboru názvů pro vývoj a připojte relaci Terminálové služby:

kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels app=webapp,role=frontend --namespace development

Na příkazovém řádku prostředí použijte wget k tomu, abyste viděli, že síťové zásady povolují přenosy:

wget -qO- http://backend

Provoz je povolen, protože v oboru názvů je naplánováno, které odpovídá tomu, co je v zásadách sítě povoleno. Následující vzorový výstup ukazuje výchozí webovou stránku NGINX, která se vrátila:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Ukončete připojenou relaci Terminálové programu. Test pod je automaticky odstraněn.

exit

Vyčištění prostředků

V tomto článku jsme vytvořili dva obory názvů a použili jste zásady sítě. K vyčištění těchto prostředků použijte příkaz kubectl Delete a zadejte názvy prostředků:

kubectl delete namespace production
kubectl delete namespace development

Další kroky

Další informace o síťových prostředcích najdete v tématu Koncepty sítě pro aplikace ve službě Azure Kubernetes Service (AKS).

Další informace o zásadách najdete v tématu zásady sítě Kubernetes.