Uw cluster beveiligen met beleid voor pod-beveiliging in Azure Kubernetes Service (AKS) (preview)

Belangrijk

De functie voor beveiligingsbeleid voor pods is op 1 augustus 2023 afgeschaft en verwijderd uit AKS-versies 1.25 en hoger.

U wordt aangeraden te migreren naar toegangscontroller voor podbeveiliging of Azure-beleid om binnen ondersteuning voor Azure te blijven. Pod Security Admission is een ingebouwde beleidsoplossing voor implementaties van één cluster. Als u op zoek bent naar beleid op ondernemingsniveau, is Azure Policy een betere keuze.

Voordat u begint

• In dit artikel wordt ervan uitgegaan dat u een bestaand AKS-cluster hebt. Als u een AKS-cluster nodig hebt, maakt u er een met behulp van Azure CLI, Azure PowerShell of Azure Portal.
• U moet Azure CLI versie 2.0.61 of hoger hebben geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

aks-preview De Azure CLI-extensie installeren

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Daarom zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

• AKS-ondersteuningsbeleid
• Veelgestelde vragen over ondersteuning voor Azure

1. Installeer de aks-preview-extensie met behulp van de az extension add opdracht.

   az extension add --name aks-preview
   

2. Werk bij naar de nieuwste versie van de extensie met behulp van de az extension update opdracht.

   az extension update --name aks-preview
   

PodSecurityPolicyPreview De functievlag registreren

1. Registreer de PodSecurityPolicyPreview functievlag met behulp van de az feature register opdracht.

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

   Het duurt enkele minuten voordat de status Geregistreerd wordt weergegeven.

2. Controleer de registratiestatus met behulp van de az feature show opdracht.

   az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
   

3. Wanneer de status Geregistreerd weergeeft, vernieuwt u de registratie van de Microsoft.ContainerService-resourceprovider met behulp van de az provider register opdracht.

   az provider register --namespace Microsoft.ContainerService
   

Overzicht van beveiligingsbeleid voor pods

Kubernetes-clusters gebruiken toegangscontrollers om aanvragen naar de API-server te onderscheppen wanneer er een resource wordt gemaakt. De toegangscontroller kan vervolgens de resourceaanvraag valideren op basis van een set regels of de resource dempen om implementatieparameters te wijzigen.

PodSecurityPolicy is een toegangscontroller waarmee een podspecificatie wordt gevalideerd die voldoet aan uw gedefinieerde vereisten. Deze vereisten kunnen het gebruik van bevoegde containers beperken, toegang tot bepaalde typen opslag of de gebruiker of groep die de container kan uitvoeren als. Wanneer u probeert een resource te implementeren waarbij de podspecificaties niet voldoen aan de vereisten die worden beschreven in het beveiligingsbeleid voor pods, wordt de aanvraag geweigerd. Deze mogelijkheid om te bepalen welke pods kunnen worden gepland in het AKS-cluster voorkomt mogelijk beveiligingsproblemen of escalatie van bevoegdheden.

Wanneer u beveiligingsbeleid voor pods inschakelt in een AKS-cluster, worden sommige standaardbeleidsregels toegepast. Deze beleidsregels bieden een out-of-the-box-ervaring om te definiëren welke pods kunnen worden gepland. U kunt echter problemen ondervinden bij het implementeren van uw pods totdat u uw eigen beleid definieert. De aanbevolen aanpak is het volgende:

1. Maak een AKS-cluster.
2. Definieer uw eigen beveiligingsbeleid voor pods.
3. Schakel de beveiligingsbeleidsfunctie voor pods in.

Gedragswijzigingen tussen beveiligingsbeleid voor pods en Azure Policy

Scenario	Beveiligingsbeleid voor pods	Azure Policy
Installatie	Functie voor beveiligingsbeleid voor pods inschakelen	Azure Policy-invoegtoepassing inschakelen
Beleid implementeren	Resource voor beveiligingsbeleid voor pods implementeren	Wijs Azure-beleid toe aan het bereik van het abonnement of de resourcegroep. De Azure Policy-invoegtoepassing is vereist voor Kubernetes-resourcetoepassingen.
Standaardbeleid	Wanneer beveiligingsbeleid voor pods is ingeschakeld in AKS, worden standaardbeleid met bevoegdheden en onbeperkte beleidsregels toegepast.	Er worden geen standaardbeleid toegepast door de Azure Policy-invoegtoepassing in te schakelen. U moet beleidsregels expliciet inschakelen in Azure Policy.
Wie beleidsregels kunnen maken en toewijzen	Clusterbeheerder maakt een beveiligingsbeleidsresource voor pods	Gebruikers moeten een minimale rol 'eigenaar' of 'Inzender voor resourcebeleid' hebben voor de AKS-clusterresourcegroep. - Via API kunnen gebruikers beleidsregels toewijzen in het resourcebereik van het AKS-cluster. De gebruiker moet minimaal de machtigingen eigenaar of Inzender voor resourcebeleid hebben voor de AKS-clusterresource. - In Azure Portal kunnen beleidsregels worden toegewezen op het niveau Van beheergroep/abonnement/resourcegroep.
Beleid autoriseren	Gebruikers en serviceaccounts vereisen expliciete machtigingen voor het gebruik van beveiligingsbeleid voor pods.	Er is geen extra toewijzing vereist om beleid te autoriseren. Zodra beleidsregels zijn toegewezen in Azure, kunnen alle clustergebruikers dit beleid gebruiken.
Toepasselijkheid van beleid	De gebruiker met beheerdersrechten omzeilt het afdwingen van beveiligingsbeleid voor pods.	Alle gebruikers (beheerder en niet-beheerder) zien hetzelfde beleid. Er is geen speciale behuizing op basis van gebruikers. Beleidstoepassing kan worden uitgesloten op naamruimteniveau.
Beleidsbereik	Beveiligingsbeleid voor pods is niet naamruimted	Beperkingssjablonen die door Azure Policy worden gebruikt, zijn niet naamruimte.
Actie Weigeren/Controleren/Mutatie	Beveiligingsbeleid voor pods ondersteunt alleen acties voor weigeren. Mutatie kan worden uitgevoerd met standaardwaarden voor het maken van aanvragen. Validatie kan worden uitgevoerd tijdens updateaanvragen.	Azure Policy ondersteunt beide acties voor controle en weigeren. Mutatie wordt nog niet ondersteund.
Naleving van beveiligingsbeleid voor pods	Er is geen inzicht in de naleving van pods die bestonden voordat het beveiligingsbeleid voor pods werd ingeschakeld. Niet-compatibele pods die zijn gemaakt nadat het inschakelen van beveiligingsbeleid voor pods is geweigerd.	Niet-compatibele pods die bestonden voordat Azure-beleid werd toegepast, worden weergegeven in beleidsschendingen. Niet-compatibele pods die zijn gemaakt nadat azure-beleid is ingeschakeld, worden geweigerd als beleidsregels zijn ingesteld met een weigeringseffect.
Beleidsregels in het cluster weergeven	kubectl get psp	kubectl get constrainttemplate - Alle beleidsregels worden geretourneerd.
Standaard voor beveiligingsbeleid voor pods - Privileged	Er wordt standaard een resource voor beveiligingsbeleid voor bevoegde pods gemaakt bij het inschakelen van de functie.	De modus Privileged impliceert geen beperking, waardoor deze gelijk is aan het niet hebben van een Azure Policy-toewijzing.
Standaard voor beveiligingsbeleid voor pods - Basislijn/standaard	Gebruiker installeert een basislijnresource voor het beveiligingsbeleid voor pods.	Azure Policy biedt een ingebouwd basislijninitiatief dat is toegewezen aan het basislijnbeveiligingsbeleid voor pods.
Standaard voor beveiligingsbeleid voor pods - beperkt	Gebruiker installeert een beperkte resource voor podbeveiligingsbeleid.	Azure Policy biedt een ingebouwd, beperkt initiatief dat is toegewezen aan het beveiligingsbeleid voor beperkte pods.

Beveiligingsbeleid voor pods inschakelen op een AKS-cluster

Notitie

Voor gebruik in de praktijk moet u het beveiligingsbeleid voor pods pas inschakelen als u uw eigen aangepaste beleidsregels definieert. In dit artikel schakelen we het beveiligingsbeleid voor pods in als eerste stap om te zien hoe de standaardbeleidsregels podimplementaties beperken.

• Schakel het beveiligingsbeleid voor pods in met behulp van de az aks update opdracht.

  az aks update \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --enable-pod-security-policy
  

Standaard AKS-beleid

Wanneer u podbeveiligingsbeleid inschakelt, maakt AKS één standaardbeleid met de naam Privileged. Bewerk of verwijder het standaardbeleid niet. Maak in plaats daarvan uw eigen beleid dat de instellingen definieert die u wilt beheren. Laten we eerst eens kijken wat deze standaardbeleidsregels zijn hoe ze van invloed zijn op podimplementaties.

1. Bekijk het beschikbare beleid met behulp van de kubectl get psp opdracht.

   kubectl get psp
   

   Uw uitvoer ziet er ongeveer als volgt uit:

   NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
   

   Het beveiligingsbeleid voor bevoegde pods wordt toegepast op elke geverifieerde gebruiker in het AKS-cluster. Deze opdracht wordt beheerd door ClusterRoles en ClusterRoleBindings.

2. Zoek met behulp van de kubectl get rolebindings opdracht naar de standaardnaamruimte:privileged: binding in de kube-system-naamruimte.

   kubectl get rolebindings default:privileged -n kube-system -o yaml
   

   In de volgende verkorte voorbeelduitvoer ziet u dat de psp:privilegedClusterRole is toegewezen aan alle door het systeem geverifieerde gebruikers. Deze mogelijkheid biedt een basisniveau van bevoegdheden zonder dat uw eigen beleid wordt gedefinieerd.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     [...]
     name: default:privileged
     [...]
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp:privileged
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   

Het is belangrijk om te begrijpen hoe deze standaardbeleidsregels communiceren met gebruikersaanvragen om pods te plannen voordat u begint met het maken van uw eigen podbeveiligingsbeleid. In de volgende secties plannen we enkele pods om het standaardbeleid in actie te zien.

Een testgebruiker maken in een AKS-cluster

Wanneer u de az aks get-credentials opdracht gebruikt, worden de beheerdersreferenties voor het AKS-cluster standaard toegevoegd aan uw kubectl configuratie. De gebruiker met beheerdersrechten omzeilt het afdwingen van beveiligingsbeleid voor pods. Als u Microsoft Entra-integratie gebruikt voor uw AKS-clusters, kunt u zich aanmelden met de referenties van een niet-beheerder om de handhaving van beleid in actie te zien.

1. Maak een voorbeeldnaamruimte met de naam psp-aks voor testbronnen met behulp van de kubectl create namespace opdracht.

   kubectl create namespace psp-aks
   

2. Maak een serviceaccount met de naam nonadmin-gebruiker met behulp van de kubectl create serviceaccount opdracht.

   kubectl create serviceaccount --namespace psp-aks nonadmin-user
   

3. Maak een RoleBinding voor de niet-beheerder om basisacties uit te voeren in de naamruimte met behulp van de kubectl create rolebinding opdracht.

   kubectl create rolebinding \
       --namespace psp-aks \
       psp-aks-editor \
       --clusterrole=edit \
       --serviceaccount=psp-aks:nonadmin-user
   

Aliasopdrachten maken voor de gebruiker met beheerdersrechten en niet-beheerders

Wanneer u dit gebruikt kubectl, kunt u de verschillen tussen de gewone gebruiker met beheerdersrechten en de niet-beheerdersgebruiker markeren door twee opdrachtregelaliassen te maken:

1. De kubectl-admin-alias voor de gewone gebruiker met beheerdersrechten, die is gericht op de psp-aks-naamruimte .
2. De kubectl-nonadminuser-alias voor de niet-beheerder die in de vorige stap is gemaakt, die is gericht op de psp-aks-naamruimte .

• Maak de twee aliassen met behulp van de volgende opdrachten.

  alias kubectl-admin='kubectl --namespace psp-aks'
  alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'
  

Het maken van een bevoegde pod testen

Laten we eens testen wat er gebeurt wanneer u een pod plant met de beveiligingscontext van privileged: true. Deze beveiligingscontext escaleert de bevoegdheden van de pod. Het AKS-beveiligingsbeleid voor standaardbevoegdheden moet deze aanvraag weigeren.

1. Maak een bestand met de naam nginx-privileged.yaml en plak de inhoud van het volgende YAML-manifest.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged
   spec:
     containers:
       - name: nginx-privileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           privileged: true
   

2. Maak de pod met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   In de volgende voorbeelduitvoer ziet u dat de pod niet kan worden gepland:

   Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
   

   Omdat de pod de planningsfase niet bereikt, zijn er geen resources om te verwijderen voordat u verdergaat.

Test het maken van een niet-gemachtigde pod

In het vorige voorbeeld heeft de podspecificatie uitgebreide escalatie aangevraagd. Deze aanvraag wordt geweigerd door het standaard beveiligingsbeleid voor bevoegdheden voor pods, zodat de pod niet kan worden gepland. Laten we proberen dezelfde NGINX-pod uit te voeren zonder de aanvraag voor escalatie van bevoegdheden.

1. Maak een bestand met de naam nginx-unprivileged.yaml en plak deze in de inhoud van het volgende YAML-manifest.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
   

2. Maak de pod met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   In de volgende voorbeelduitvoer ziet u dat de pod niet kan worden gepland:

   Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
   

   Omdat de pod de planningsfase niet bereikt, zijn er geen resources om te verwijderen voordat u verdergaat.

Test het maken van een pod met een specifieke gebruikerscontext

In het vorige voorbeeld heeft de containerinstallatiekopieën automatisch geprobeerd om de hoofdmap te gebruiken om NGINX te binden aan poort 80. Deze aanvraag is geweigerd volgens het standaard beveiligingsbeleid voor bevoegdheden voor pods, zodat de pod niet kan worden gestart. Laten we dezelfde NGINX-pod proberen uit te voeren met een specifieke gebruikerscontext, zoals runAsUser: 2000.

1. Maak een bestand met de naam nginx-unprivileged-nonroot.yaml en plak het volgende YAML-manifest.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged-nonroot
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           runAsUser: 2000
   

2. Maak de pod met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
   

   In de volgende voorbeelduitvoer ziet u dat de pod niet kan worden gepland:

   Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []
   

   Omdat de pod de planningsfase niet bereikt, zijn er geen resources om te verwijderen voordat u verdergaat.

Een aangepast beveiligingsbeleid voor pods maken

Nu u het gedrag van het standaardbeveiligingsbeleid voor pods hebt gezien, gaan we een manier bieden voor de niet-beheerder om pods te plannen.

We maken een beleid voor het weigeren van pods die bevoegde toegang aanvragen. Andere opties, zoals runAsUser of toegestane volumes, worden niet expliciet beperkt. Met dit type beleid wordt een aanvraag voor bevoegde toegang geweigerd, maar kan het cluster de aangevraagde pods uitvoeren.

1. Maak een bestand met de naam psp-deny-privileged.yaml en plak het volgende YAML-manifest.

   apiVersion: policy/v1beta1
   kind: PodSecurityPolicy
   metadata:
     name: psp-deny-privileged
   spec:
     privileged: false
     seLinux:
       rule: RunAsAny
     supplementalGroups:
       rule: RunAsAny
     runAsUser:
       rule: RunAsAny
     fsGroup:
       rule: RunAsAny
     volumes:
    - '*'
   

2. Maak het beleid met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl apply -f psp-deny-privileged.yaml
   

3. Bekijk het beschikbare beleid met behulp van de kubectl get psp opdracht.

   kubectl get psp
   

   In de volgende voorbeelduitvoer vergelijkt u het beleid met betrekking tot psp-deny-privileged met het standaardbevoegdhedenbeleid dat in de vorige voorbeelden is afgedwongen om een pod te maken. Alleen het gebruik van PRIV-escalatie wordt geweigerd door uw beleid. Er zijn geen beperkingen voor de gebruiker of groep voor het beleid psp-deny-privileged .

   NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
   psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *          
   

Gebruikersaccount toestaan het aangepaste beveiligingsbeleid voor pods te gebruiken

In de vorige stap hebt u een beveiligingsbeleid voor pods gemaakt om pods te weigeren die bevoegde toegang aanvragen. Als u wilt toestaan dat het beleid wordt gebruikt, maakt u een rol of clusterrole. Vervolgens koppelt u een van deze rollen met behulp van een RoleBinding of ClusterRoleBinding. In dit voorbeeld maken we een ClusterRole waarmee u het beleid psp-deny-privileged kunt gebruiken dat in de vorige stap is gemaakt.

1. Maak een bestand met de naam psp-deny-privileged-clusterrole.yaml en plak het volgende YAML-manifest.

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: psp-deny-privileged-clusterrole
   rules:
   - apiGroups:
     - extensions
      resources:
     - podsecuritypolicies
      resourceNames:
     - psp-deny-privileged
      verbs:
     - use
   

2. Maak clusterrole met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl apply -f psp-deny-privileged-clusterrole.yaml
   

3. Maak een bestand met de naam psp-deny-privileged-clusterrolebinding.yaml en plak het volgende YAML-manifest.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: psp-deny-privileged-clusterrolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp-deny-privileged-clusterrole
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   

4. Maak de ClusterRoleBinding met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.

   kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
   

Notitie

In de eerste stap van dit artikel is de functie voor het beveiligingsbeleid voor pods ingeschakeld op het AKS-cluster. De aanbevolen procedure was om alleen de functie voor het beveiligingsbeleid voor pods in te schakelen nadat u uw eigen beleid hebt gedefinieerd. Dit is de fase waarin u de functie voor het beveiligingsbeleid voor pods inschakelt. Er zijn een of meer aangepaste beleidsregels gedefinieerd en gebruikersaccounts zijn gekoppeld aan dit beleid. U kunt de beveiligingsbeleidsfunctie voor pods nu veilig inschakelen en problemen minimaliseren die worden veroorzaakt door het standaardbeleid.

Test het maken van een niet-gemachtigde pod opnieuw

Nu uw aangepaste podbeveiligingsbeleid is toegepast en een binding voor het gebruikersaccount om het beleid te gebruiken, gaan we opnieuw proberen een niet-gemachtigde pod te maken.

In dit voorbeeld ziet u hoe u aangepast beveiligingsbeleid voor pods kunt maken om toegang tot het AKS-cluster te definiëren voor verschillende gebruikers of groepen. Het standaard AKS-beleid biedt strikte besturingselementen voor welke pods kunnen worden uitgevoerd, dus maak uw eigen aangepaste beleidsregels om vervolgens de beperkingen die u nodig hebt correct te definiëren.

1. Gebruik het nginx-privileged.yaml manifest om de pod te maken met behulp van de kubectl apply opdracht.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. Controleer de status van de pod met behulp van de kubectl get pods opdracht.

   kubectl-nonadminuser get pods
   

   In de volgende voorbeelduitvoer ziet u dat de pod is gepland en wordt uitgevoerd:

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          7m14s
   

3. Verwijder de niet-gemachtigde NGINX-pod met behulp van de kubectl delete opdracht en geef de naam van uw YAML-manifest op.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Resources opschonen

1. Schakel het beveiligingsbeleid voor pods uit met behulp van de az aks update opdracht.

   az aks update \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --disable-pod-security-policy
   

2. Verwijder clusterrole en ClusterRoleBinding met behulp van de kubectl delete opdracht.

   kubectl delete -f psp-deny-privileged-clusterrole.yaml
   

3. Verwijder clusterRoleBinding met behulp van de kubectl delete opdracht.

   kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
   

4. Verwijder het beveiligingsbeleid met behulp van kubectl delete de opdracht en geef de naam van uw YAML-manifest op.

   kubectl delete -f psp-deny-privileged.yaml
   

5. Verwijder de psp-aks-naamruimte met behulp van de kubectl delete opdracht.

   kubectl delete namespace psp-aks
   

Volgende stappen

In dit artikel hebt u gezien hoe u een beveiligingsbeleid voor pods maakt om het gebruik van bevoegde toegang te voorkomen. Beleidsregels kunnen veel functies afdwingen, zoals het type volume of de RunAs-gebruiker. Zie de naslagdocumenten voor kubernetes-podbeveiligingsbeleid voor meer informatie over de beschikbare opties.

Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS voor meer informatie over het beperken van podnetwerkverkeer.