Skydda dina Azure Kubernetes Service-kluster (AKS) med Azure Policy

Artikel
06/21/2023

Du kan tillämpa och tillämpa inbyggda säkerhetsprinciper på dina Azure Kubernetes Service-kluster (AKS) med hjälp av Azure Policy. Azure Policy hjälper till att genomdriva organisationens standarder och utvärdera efterlevnad i stor skala. När du har installerat Azure Policy tillägg för AKS kan du använda enskilda principdefinitioner eller grupper av principdefinitioner som kallas initiativ (kallas ibland principuppsättningar) för klustret. Se Azure Policy inbyggda definitioner för AKS för en fullständig lista över AKS-princip- och initiativdefinitioner.

Den här artikeln visar hur du tillämpar principdefinitioner på klustret och kontrollerar att tilldelningarna tillämpas.

Förutsättningar

Den här artikeln förutsätter att du har ett befintligt AKS-kluster. Om du behöver ett AKS-kluster kan du skapa ett med hjälp av Azure CLI, Azure PowerShell eller Azure Portal.
Du behöver det Azure Policy tillägget för AKS installerat i AKS-klustret.

Tilldela en inbyggd principdefinition eller ett initiativ

Du kan använda en principdefinition eller ett initiativ i Azure Portal med hjälp av följande steg:

Gå till Azure Policy-tjänsten i Azure Portal med namnet Princip.
I den vänstra rutan på sidan Azure Policy väljer du Definitioner.
Under Kategorier väljer du Kubernetes.
Välj den principdefinition eller det initiativ som du vill använda. I det här exemplet väljer du kubernetes-klustrets säkerhetsbaslinjestandarder för Linux-baserade arbetsbelastningar .
Välj Tilldela.
Ange omfånget till resursgruppen för AKS-klustret med det Azure Policy tillägget aktiverat.
Välj sidan Parametrar och uppdatera effekten från audit till för att deny blockera nya distributioner som bryter mot baslinjeinitiativet. Du kan också lägga till extra namnområden som ska undantas från utvärderingen. Behåll standardvärdena i det här exemplet.
Välj Granska + skapa>Skapa för att skicka principtilldelningen.

Skapa och tilldela en anpassad principdefinition

Med anpassade principer kan du definiera regler för att använda Azure. Du kan till exempel tillämpa följande typer av regler:

Säkerhetsmetoder
Kostnadshantering
Organisationsspecifika regler (till exempel namngivning eller platser)

Innan du skapar en anpassad princip kontrollerar du listan över vanliga mönster och exempel för att se om ditt ärende redan omfattas.

Anpassade principdefinitioner skrivs i JSON. Mer information om hur du skapar en anpassad princip finns i Azure Policy definitionsstruktur och Skapa en anpassad principdefinition.

Anteckning

Azure Policy använder nu en ny egenskap som kallas templateInfo som gör att du kan definiera källtypen för begränsningsmallen. När du definierar templateInfo i principdefinitioner behöver du inte definiera egenskaper för constraintTemplate eller constraint . Du måste fortfarande definiera apiGroups och typer. Mer information om detta finns i Förstå Azure Policy effekter.

När du har skapat din anpassade principdefinition kan du läsa Tilldela en principdefinition för en stegvis genomgång av tilldelningen av principen till kubernetes-klustret.

Verifiera att en Azure Policy körs

Bekräfta att principtilldelningarna tillämpas på klustret med hjälp av följande kubectl get kommando.

kubectl get constrainttemplates

Anteckning

Principtilldelningar kan ta upp till 20 minuter att synkronisera till varje kluster.

Dina utdata bör likna följande exempelutdata:

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

Verifiera avvisande av en privilegierad podd

Vi ska först testa vad som händer när du schemalägger en podd med säkerhetskontexten privileged: trueför . Den här säkerhetskontexten eskalerar poddens behörigheter. Initiativet tillåter inte privilegierade poddar, så begäran nekas, vilket resulterar i att distributionen avvisas.

Skapa en fil med namnet nginx-privileged.yaml och klistra in följande 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

Skapa podden med kubectl apply kommandot och ange namnet på ditt YAML-manifest.

kubectl apply -f nginx-privileged.yaml

Som förväntat kan podden inte schemaläggas, vilket visas i följande exempelutdata:

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}

Podden når inte schemaläggningssteget, så det finns inga resurser att ta bort innan du går vidare.

Testa skapandet av en oprivilegierad podd

I föregående exempel försökte containeravbildningen automatiskt använda roten för att binda NGINX till port 80. Principinitiativet nekar den här begäran, så podden startar inte. Nu ska vi prova att köra samma NGINX-podd utan privilegierad åtkomst.

Skapa en fil med namnet nginx-unprivileged.yaml och klistra in följande 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

Skapa podden med kubectl apply kommandot och ange namnet på ditt YAML-manifest.
```
kubectl apply -f nginx-unprivileged.yaml
```
Kontrollera statusen för podden med kommandot kubectl get pods .
```
kubectl get pods
```
Dina utdata bör likna följande exempelutdata, som visar att podden har schemalagts och har statusen Körs:
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s
```
Det här exemplet visar baslinjeinitiativet som endast påverkar de distributioner som bryter mot principer i samlingen. Tillåtna distributioner fortsätter att fungera.
Ta bort den Oprivilegierade NGINX-podden med kommandot kubectl delete och ange namnet på YAML-manifestet.
```
kubectl delete -f nginx-unprivileged.yaml
```

Inaktivera en princip eller ett initiativ

Du kan ta bort baslinjeinitiativet i Azure Portal med hjälp av följande steg:

Gå till fönstret Princip på Azure Portal.
Välj Tilldelningar.
Välj knappen ... bredvid Kubernetes-klusterpoddens säkerhetsbaslinjestandarder för Linux-baserat arbetsbelastningsinitiativ .
Välj Ta bort tilldelning.

Nästa steg

Mer information om hur Azure Policy fungerar finns i följande artiklar: