Uw Azure Kubernetes Service-clusters (AKS) beveiligen met Azure Policy

Artikel
06/21/2023

U kunt ingebouwd beveiligingsbeleid toepassen en afdwingen op uw AKS-clusters (Azure Kubernetes Service) met behulp van Azure Policy. Azure Policy helpt bij het afdwingen van organisatorische standaarden en het evalueren van naleving op schaal. Nadat u de Azure Policy-invoegtoepassing voor AKS hebt geïnstalleerd, kunt u afzonderlijke beleidsdefinities of groepen beleidsdefinities genaamd initiatieven (ook wel beleidssets genoemd) toepassen op uw cluster. Zie Azure Policy ingebouwde definities voor AKS voor een volledige lijst met AKS-beleids- en initiatiefdefinities.

In dit artikel wordt beschreven hoe u beleidsdefinities toepast op uw cluster en controleert of deze toewijzingen worden afgedwongen.

Vereisten

In dit artikel wordt ervan uitgegaan dat u een bestaand AKS-cluster hebt. Als u een AKS-cluster nodig hebt, kunt u er een maken met behulp van Azure CLI, Azure PowerShell of Azure Portal.
De Azure Policy-invoegtoepassing voor AKS moet op uw AKS-cluster zijn geïnstalleerd.

Een ingebouwde beleidsdefinitie of -initiatief toewijzen

U kunt een beleidsdefinitie of initiatief toepassen in de Azure Portal met behulp van de volgende stappen:

Navigeer naar de Azure Policy-service in Azure Portal met de naam Beleid.
Selecteer Definities in het linkerdeelvenster van de pagina Azure Policy.
Selecteer onder Categorieën de optie Kubernetes.
Kies de beleidsdefinitie of het initiatief dat u wilt toepassen. Selecteer voor dit voorbeeld het initiatief Kubernetes-clusterpodbeveiligingsbasislijnstandaarden voor op Linux gebaseerde workloads .
Selecteer Toewijzen.
Stel het bereik in op de resourcegroep van het AKS-cluster met de Azure Policy-invoegtoepassing ingeschakeld.
Selecteer de pagina Parameters en werk effect vanaudit tot bij deny om nieuwe implementaties te blokkeren die het basislijninitiatief schenden. U kunt ook extra naamruimten toevoegen om uit te sluiten van evaluatie. Behoud voor dit voorbeeld de standaardwaarden.
Selecteer Beoordelen en maken>Maken om de beleidstoewijzing te verzenden.

Een aangepaste beleidsdefinitie maken en toewijzen

Met aangepast beleid kunt u regels definiëren voor het gebruik van Azure. U kunt bijvoorbeeld de volgende typen regels afdwingen:

Beveiligingsmethoden
Kostenbeheer
Organisatie-specifieke regels (zoals namen of locaties)

Voordat u een aangepast beleid maakt, controleert u de lijst met veelvoorkomende patronen en voorbeelden om te zien of uw case al wordt behandeld.

Aangepaste beleidsdefinities worden geschreven in JSON. Zie Azure Policy definitiestructuur en Een aangepaste beleidsdefinitie maken voor meer informatie over het maken van een aangepast beleid.

Notitie

Azure Policy maakt nu gebruik van een nieuwe eigenschap, templateInfo genoemd, waarmee u het brontype voor de beperkingssjabloon kunt definiëren. Wanneer u templateInfo definieert in beleidsdefinities, hoeft u de eigenschappen constraintTemplate of constraint niet te definiëren. U moet nog steeds apiGroups en -soorten definiëren. Zie Inzicht in Azure Policy effecten voor meer informatie hierover.

Zodra u de aangepaste beleidsdefinitie hebt gemaakt, raadpleegt u Een beleidsdefinitie toewijzen voor een stapsgewijze procedure voor het toewijzen van het beleid aan uw Kubernetes-cluster.

Controleren of er een Azure Policy wordt uitgevoerd

Controleer of de beleidstoewijzingen worden toegepast op uw cluster met behulp van de volgende kubectl get opdracht.

kubectl get constrainttemplates

Notitie

Het kan tot 20 minuten duren voordat beleidstoewijzingen in elk cluster zijn gesynchroniseerd.

De uitvoer moet vergelijkbaar zijn met de volgende voorbeelduitvoer:

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Afwijzing van een bevoegde pod valideren

Laten we eerst testen wat er gebeurt wanneer u een pod plant met de beveiligingscontext van privileged: true. Deze beveiligingscontext escaleert de bevoegdheden van de pod. Het initiatief staat bevoegde pods niet toe, dus de aanvraag wordt geweigerd, waardoor de implementatie wordt geweigerd.

Maak een bestand met de naam nginx-privileged.yaml en plak 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.15.5-alpine
      securityContext:
        privileged: true

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

kubectl apply -f nginx-privileged.yaml

Zoals verwacht, kan de pod niet worden gepland, zoals wordt weergegeven in de volgende voorbeelduitvoer:

Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}

De pod bereikt de planningsfase niet, dus er zijn geen resources die u kunt verwijderen voordat u verdergaat.

Het maken van een niet-gemachtigde pod testen

In het vorige voorbeeld heeft de containerinstallatiekopieën automatisch geprobeerd om de hoofdmap te gebruiken om NGINX te binden aan poort 80. Het beleidsinitiatief weigert deze aanvraag, waardoor de pod niet kan worden gestart. Laten we nu proberen dezelfde NGINX-pod uit te voeren zonder bevoegde toegang.

Maak een bestand met de naam nginx-unprivileged.yaml en plak 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.15.5-alpine

Maak de pod met behulp van de kubectl apply opdracht en geef de naam van uw YAML-manifest op.
```
kubectl apply -f nginx-unprivileged.yaml
```
Controleer de status van de pod met behulp van de kubectl get pods opdracht .
```
kubectl get pods
```
De uitvoer moet vergelijkbaar zijn met de volgende voorbeelduitvoer, die laat zien dat de pod is gepland en de status Wordt uitgevoerd heeft:
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s
```
In dit voorbeeld ziet u het basislijninitiatief dat alleen van invloed is op de implementaties die het beleid in de verzameling schenden. Toegestane implementaties blijven werken.
Verwijder de niet-gemachtigde NGINX-pod met behulp van de kubectl delete opdracht en geef de naam van uw YAML-manifest op.
```
kubectl delete -f nginx-unprivileged.yaml
```

Een beleid of initiatief uitschakelen

U kunt het basislijninitiatief in de Azure Portal verwijderen met behulp van de volgende stappen:

Navigeer naar het deelvenster Beleid op de Azure Portal.
Selecteer Toewijzingen.
Selecteer de knop ... naast de basislijnstandaarden voor beveiliging van Kubernetes-clusterpods voor op Linux gebaseerde workloads .
Selecteer Toewijzing verwijderen.

Volgende stappen

Zie de volgende artikelen voor meer informatie over de werking van Azure Policy: