Verkeer tussen pods beveiligen met behulp van netwerkbeleid in Azure Kubernetes Service (AKS)

Wanneer u moderne, op microservices gebaseerde toepassingen in Kubernetes gebruikt, wilt u vaak bepalen welke onderdelen met elkaar kunnen communiceren. Het principe van de minste bevoegdheden moet worden toegepast op de manier waarop verkeer tussen pods in een AKS-cluster (Azure Kubernetes Service) kan stromen. Stel dat u verkeer rechtstreeks naar back-endtoepassingen wilt blokkeren. Met de functie Netwerkbeleid in Kubernetes kunt u regels definiëren voor in- en uitverkeer tussen pods in een cluster.

In dit artikel wordt beschreven hoe u de engine voor netwerkbeleid installeert en Kubernetes-netwerkbeleid maakt om de verkeersstroom tussen pods in AKS te controleren. Netwerkbeleid mag alleen worden gebruikt voor Linux-knooppunten en -pods in AKS.

Voordat u begint

Azure CLI versie 2.0.61 of hoger moet zijn geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Zie Azure CLI installeren als u de CLI wilt installeren of een upgrade wilt uitvoeren.

Overzicht van netwerkbeleid

Alle pods in een AKS-cluster kunnen standaard zonder beperkingen verkeer verzenden en ontvangen. Om de beveiliging te verbeteren, kunt u regels definiëren die de verkeersstroom bepalen. Back-endtoepassingen worden bijvoorbeeld vaak alleen blootgesteld aan de vereiste front-endservices. Of databaseonderdelen zijn alleen toegankelijk voor de toepassingslagen die er verbinding mee maken.

Netwerkbeleid is een Kubernetes-specificatie die toegangsbeleid definieert voor communicatie tussen pods. Met behulp van netwerkbeleid definieert u een geordende set regels voor het verzenden en ontvangen van verkeer en past u deze toe op een verzameling pods die overeenkomen met een of meer label-selectors.

Deze netwerkbeleidsregels worden gedefinieerd als YAML-manifesten. Netwerkbeleid kan worden opgenomen als onderdeel van een breder manifest dat ook een implementatie of service maakt.

Opties voor netwerkbeleid in AKS

Azure biedt twee manieren om netwerkbeleid te implementeren. U kiest een netwerkbeleidsoptie wanneer u een AKS-cluster maakt. De beleidsoptie kan niet worden gewijzigd nadat het cluster is gemaakt:

• De eigen implementatie van Azure, Azure Network Policies genoemd.
• Kalico-netwerkbeleid, een opensourcenetwerk- en netwerkbeveiligingsoplossing die is gebouwd door Tigera.

Beide implementaties gebruiken Linux IPTables om het opgegeven beleid af te dwingen. Beleidsregels worden omgezet in sets toegestane en niet-toegestane IP-paren. Deze paren worden vervolgens geprogrammeerd als IPTable-filterregels.

Verschillen tussen Azure- en Euco-beleid en hun mogelijkheden

Een AKS-cluster maken en netwerkbeleid inschakelen

Als u netwerkbeleid in actie wilt zien, gaan we een beleid maken en vervolgens uitbreiden dat de verkeersstroom definieert:

• Al het verkeer naar pod weigeren.
• Sta verkeer toe op basis van podlabels.
• Sta verkeer toe op basis van naamruimte.

Eerst maken we een AKS-cluster dat ondersteuning biedt voor netwerkbeleid.

Als u Azure Network Policy wilt gebruiken, moet u de Azure CNI en uw eigen virtuele netwerk en subnetten definiëren. Zie Geavanceerde netwerken configureren voor meer informatie over het plannen van de vereiste subnetbereiken. Het Netwerkbeleid voor Het netwerk kan worden gebruikt met dezelfde Azure CNI-in plug-in of met de Kubenet CNI-in plug-in.

Het volgende voorbeeldscript:

• Hiermee maakt u een virtueel netwerk en subnet.
• Hiermee maakt u Azure Active Directory service-principal (Azure AD) voor gebruik met het AKS-cluster.
• Wijst inzendermachtigingen toe voor de AKS-clusterservice-principal in het virtuele netwerk.
• Hiermee maakt u een AKS-cluster in het gedefinieerde virtuele netwerk en schakelt u netwerkbeleid in.
  • De optie Azure Network-beleid wordt gebruikt. Als u in plaats daarvan Wilt gebruiken als optie voor netwerkbeleid, gebruikt u de --network-policy calico parameter . Opmerking: Kan Worden gebruikt met of --network-plugin azure --network-plugin kubenet .

In plaats van een service-principal te gebruiken, kunt u een beheerde identiteit gebruiken voor machtigingen. Zie Beheerde identiteiten gebruiken voor meer informatie.

Geef uw eigen beveiligde SP_PASSWORD. U kunt de RESOURCE_GROUP_NAME en CLUSTER_NAME vervangen:

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)

Een AKS-cluster maken voor Azure-netwerkbeleid

Maak het AKS-cluster en geef het virtuele netwerk, de service-principalgegevens en azure op voor de netwerkinvoegvoeging en het netwerkbeleid.

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

Het duurt een paar minuten om het cluster te maken. Wanneer het cluster klaar is, configureert u om verbinding te maken met uw Kubernetes-cluster met behulp van de kubectl opdracht az aks get-credentials. Met deze opdracht worden referenties gedownload en wordt de Kubernetes CLI geconfigureerd voor het gebruik ervan:

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

Een AKS-cluster maken voor Het netwerkbeleid van Kalico

Maak het AKS-cluster en geef het virtuele netwerk, informatie over de service-principal, azure voor de netwerkinvoegvoegsel en de code voor het netwerkbeleid op. Door gebruik te maken van kalico als netwerkbeleid kunt u Via Linux-netwerken Windows linux-knooppuntgroepen.

Als u van plan bent om Windows-knooppuntgroepen toe te voegen aan uw cluster, moet u de parameters en opnemen met die voldoen aan windows-admin-username windows-admin-password Windows serverwachtwoordvereisten. Als u Wilt gebruiken met Windows, moet u ook de Microsoft.ContainerService/EnableAKSWindowsCalico registreren.

Registreer de EnableAKSWindowsCalico functievlag met behulp van de opdracht az feature register, zoals wordt weergegeven in het volgende voorbeeld:

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

U kunt de registratiestatus controleren met behulp van de opdracht az feature list:

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

Wanneer u klaar bent, vernieuwt u de registratie van de resourceprovider Microsoft.ContainerService met behulp van de opdracht az provider register:

az provider register --namespace Microsoft.ContainerService

Het beleid voor netwerknetwerken met Windows knooppunten is momenteel beschikbaar als preview-versie.

Maak een gebruikersnaam om te gebruiken als beheerdersreferenties voor uw Windows Server-containers in uw cluster. De volgende opdrachten vragen u om een gebruikersnaam en stellen deze WINDOWS_USERNAME in voor gebruik in een latere opdracht (onthoud dat de opdrachten in dit artikel worden ingevoerd in een BASH-shell).

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

Het duurt een paar minuten om het cluster te maken. Uw cluster wordt standaard alleen gemaakt met een Linux-knooppuntgroep. Als u een knooppuntpool wilt Windows, kunt u er een toevoegen. Bijvoorbeeld:

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

Wanneer het cluster klaar is, configureert u om verbinding te maken met uw kubectl Kubernetes-cluster met behulp van de opdracht az aks get-credentials. Met deze opdracht worden referenties gedownload en wordt de Kubernetes CLI geconfigureerd voor het gebruik ervan:

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

Al het binnenkomende verkeer naar een pod weigeren

Voordat u regels definieert om specifiek netwerkverkeer toe te staan, moet u eerst een netwerkbeleid maken om al het verkeer te weigeren. Dit beleid geeft u een beginpunt om te beginnen met het maken van een allowlist voor alleen het gewenste verkeer. U kunt ook duidelijk zien dat verkeer wordt weggevallen wanneer het netwerkbeleid wordt toegepast.

Voor de voorbeeldtoepassingsomgeving en verkeersregels maken we eerst een naamruimte met de naam ontwikkeling om de voorbeeldpods uit te voeren:

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

Maak een voorbeeld van een back-endpod met NGINX. Deze back-endpod kan worden gebruikt om een voorbeeld van een back-endwebtoepassing te simuleren. Maak deze pod in de ontwikkelingsnaamruimte en open poort 80 om webverkeer te bedienen. Label de pod met app=webapp,role=backend, zodat we deze in de volgende sectie kunnen richten met een netwerkbeleid:

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

Maak nog een pod en voeg een terminalsessie toe om te testen of u de standaard NGINX-webpagina kunt bereiken:

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

Gebruik bij de shell-prompt om te bevestigen dat u toegang hebt tot de standaard wget NGINX-webpagina:

wget -qO- http://backend

In de volgende voorbeelduitvoer ziet u dat de standaard NGINX-webpagina is geretourneerd:

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

Sluit de gekoppelde terminalsessie af. De testpod wordt automatisch verwijderd.

exit

Een netwerkbeleid maken en toepassen

Nu u hebt bevestigd dat u de eenvoudige NGINX-webpagina op de voorbeeld-back-endpod kunt gebruiken, maakt u een netwerkbeleid om al het verkeer te weigeren. Maak een bestand met de backend-policy.yaml naam en plak het volgende YAML-manifest. In dit manifest wordt een podSelector gebruikt om het beleid te koppelen aan pods met het label app:webapp,role:backend, zoals uw NGINX-voorbeeldpod. Er zijn geen regels gedefinieerd onder inkomende, zodat al het binnenkomende verkeer naar de pod wordt geweigerd:

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

Ga naar https://shell.azure.com om de Azure Cloud Shell in uw browser te openen.

Pas het netwerkbeleid toe met behulp van de opdracht kubectl apply en geef de naam van uw YAML-manifest op:

kubectl apply -f backend-policy.yaml

Het netwerkbeleid testen

Laten we eens kijken of u de NGINX-webpagina op de back-endpod opnieuw kunt gebruiken. Maak nog een testpod en koppel een terminalsessie:

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

Gebruik bij de shell-prompt om te zien of u toegang hebt tot de standaard wget NGINX-webpagina. Stel deze keer een time-outwaarde in op 2 seconden. Het netwerkbeleid blokkeert nu al het inkomende verkeer, zodat de pagina niet kan worden geladen, zoals wordt weergegeven in het volgende voorbeeld:

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

wget: download timed out

Sluit de gekoppelde terminalsessie af. De testpod wordt automatisch verwijderd.

exit

Inkomende verkeer toestaan op basis van een podlabel

In de vorige sectie is een back-end NGINX-pod gepland en is een netwerkbeleid gemaakt om al het verkeer te weigeren. We gaan een front-endpod maken en het netwerkbeleid bijwerken om verkeer van front-endpods toe te staan.

Werk het netwerkbeleid bij om verkeer van pods toe te staan met de labels app:webapp,role:frontend en in een naamruimte. Bewerk het vorige backend-policy.yaml-bestand en voeg regels voor het binnenkomtagress matchLabels toe, zodat uw manifest eruitziet als in het volgende voorbeeld:

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

Pas het bijgewerkte netwerkbeleid toe met behulp van de opdracht kubectl apply en geef de naam van uw YAML-manifest op:

kubectl apply -f backend-policy.yaml

Plan een pod met het label app=webapp,role=frontend en koppel een terminalsessie:

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

Gebruik bij de shell-prompt om te zien of u toegang hebt tot de standaard wget NGINX-webpagina:

wget -qO- http://backend

Omdat de toegangsregel verkeer toestaat met pods die de labels-app hebben: webapp,rol: front-end, is het verkeer van de front-endpod toegestaan. In de volgende voorbeelduitvoer ziet u de standaard NGINX-webpagina die wordt geretourneerd:

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

Sluit de gekoppelde terminalsessie af. De pod wordt automatisch verwijderd.

exit

Een pod testen zonder een overeenkomend label

Het netwerkbeleid staat verkeer toe van pods met het label app: webapp,rol: front-end, maar moet al het andere verkeer weigeren. We gaan testen of een andere pod zonder deze labels toegang heeft tot de back-end NGINX-pod. Maak nog een testpod en koppel een terminalsessie:

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

Gebruik bij de shell-prompt om te zien of u toegang hebt tot de standaard wget NGINX-webpagina. Het netwerkbeleid blokkeert het binnenkomende verkeer, zodat de pagina niet kan worden geladen, zoals wordt weergegeven in het volgende voorbeeld:

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

wget: download timed out

Sluit de gekoppelde terminalsessie af. De testpod wordt automatisch verwijderd.

exit

Verkeer alleen toestaan vanuit een gedefinieerde naamruimte

In de vorige voorbeelden hebt u een netwerkbeleid gemaakt dat al het verkeer heeft geweigerd en vervolgens het beleid bijgewerkt om verkeer van pods met een specifiek label toe te staan. Een andere veelvoorkomende behoefte is om verkeer te beperken tot alleen binnen een bepaalde naamruimte. Als de vorige voorbeelden voor verkeer in een ontwikkelingsnaamruimte waren, maakt u een netwerkbeleid dat voorkomt dat verkeer van een andere naamruimte, zoals productie, de pods bereikt.

Maak eerst een nieuwe naamruimte om een productienaamruimte te simuleren:

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

Plan een testpod in de productienaamruimte die is gelabeld als app=webapp,role=front-end. Een terminalsessie koppelen:

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

Gebruik bij de shell-prompt om te bevestigen dat u toegang hebt tot de standaard wget NGINX-webpagina:

wget -qO- http://backend.development

Omdat de labels voor de pod overeenkomen met wat momenteel is toegestaan in het netwerkbeleid, is het verkeer toegestaan. Het netwerkbeleid kijkt niet naar de naamruimten, alleen naar de podlabels. In de volgende voorbeelduitvoer ziet u de standaard NGINX-webpagina die wordt geretourneerd:

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

Sluit de gekoppelde terminalsessie af. De testpod wordt automatisch verwijderd.

exit

Het netwerkbeleid bijwerken

Laten we de sectie naamruimte van de toegangsregelSelector bijwerken zodat alleen verkeer vanuit de ontwikkelingsnaamruimte wordt toegestaan. Bewerk het manifestbestand backend-policy.yaml zoals wordt weergegeven in het volgende voorbeeld:

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

In complexere voorbeelden kunt u meerdere regels voor ingress definiëren, zoals een naamruimteSelector en vervolgens een podSelector.

Pas het bijgewerkte netwerkbeleid toe met behulp van de opdracht kubectl apply en geef de naam van uw YAML-manifest op:

kubectl apply -f backend-policy.yaml

Het bijgewerkte netwerkbeleid testen

Plan nog een pod in de productienaamruimte en koppel een terminalsessie:

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

Gebruik bij de shell-prompt wget om te zien dat het netwerkbeleid verkeer nu weert:

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

wget: download timed out

Sluit de testpod af:

exit

Als verkeer uit de productienaamruimte wordt geweigerd, moet u een testpod weer plannen in de ontwikkelingsnaamruimte en een terminalsessie koppelen:

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

Gebruik bij de shell-prompt wget om te zien dat het netwerkbeleid het verkeer toestaat:

wget -qO- http://backend

Verkeer is toegestaan omdat de pod is gepland in de naamruimte die overeenkomt met wat is toegestaan in het netwerkbeleid. In de volgende voorbeelduitvoer ziet u de standaard NGINX-webpagina die wordt geretourneerd:

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

Sluit de gekoppelde terminalsessie af. De testpod wordt automatisch verwijderd.

exit

Resources opschonen

In dit artikel hebben we twee naamruimten gemaakt en een netwerkbeleid toegepast. Als u deze resources wilt ops schonen, gebruikt u de opdracht kubectl delete en geeft u de resourcenamen op:

kubectl delete namespace production
kubectl delete namespace development

Volgende stappen

Zie Netwerkconcepten voor toepassingen in Azure Kubernetes Service (AKS) voor meer informatie over netwerkresources.

Zie Kubernetes-netwerkbeleidvoor meer informatie over beleidsregels.