Delen via

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

  • Artikel

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 organisatiestandaarden en het beoordelen van naleving op schaal. Nadat u de Azure Policy-invoegtoepassing voor AKS hebt geïnstalleerd, kunt u afzonderlijke beleidsdefinities of groepen beleidsdefinities met de naam initiatieven (ook wel beleidssets genoemd) toepassen op uw cluster. Zie ingebouwde Azure Policy-definities voor AKS voor een volledige lijst met AKS-beleids - en initiatiefdefinities.

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

Vereisten

Een ingebouwde beleidsdefinitie of initiatief toewijzen

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

  1. Navigeer naar de Azure Policy-service in Azure Portal met de naam Policy.
  2. Selecteer Definities in het linkerdeelvenster van de pagina Azure Policy.
  3. Selecteer onder Categorieën de optie Kubernetes.
  4. Kies de beleidsdefinitie of het initiatief dat u wilt toepassen. Selecteer voor dit voorbeeld de basislijnstandaarden voor de beveiliging van kubernetes-clusters voor linux-workloads .
  5. Selecteer Toewijzen.
  6. Stel het bereik in op de resourcegroep van het AKS-cluster met de Azure Policy-invoegtoepassing ingeschakeld.
  7. Selecteer de pagina Parameters en werk het effect bij audit om deny te voorkomen dat nieuwe implementaties het basislijninitiatief schenden. U kunt ook extra naamruimten toevoegen om uit te sluiten van evaluatie. Behoud voor dit voorbeeld de standaardwaarden.
  8. Selecteer Beoordelen en maken> om de beleidstoewijzing in te dienen.

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 de definitiestructuur van Azure Policy 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, ook wel templateInfo genoemd, waarmee u het brontype voor de beperkingssjabloon kunt definiëren. Wanneer u templateInfo definieert in beleidsdefinities, hoeft u geen constraintTemplate- of constraint-eigenschappen te definiëren. U moet nog steeds apiGroups en -soorten definiëren. Zie Azure Policy-effecten voor meer informatie hierover.

Zodra u uw 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 Azure Policy wordt uitgevoerd

  • Controleer of de beleidstoewijzingen zijn 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 worden gesynchroniseerd .

    De uitvoer moet er ongeveer uitzien als in 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.

  1. 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

  2. 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 om te verwijderen voordat u verdergaat.

Test het maken van een niet-gemachtigde pod

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, zodat de pod niet kan worden gestart. Nu gaan we proberen dezelfde NGINX-pod uit te voeren zonder bevoegde toegang.

  1. 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

  2. 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

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

    kubectl get pods

    Uw uitvoer moet vergelijkbaar zijn met de volgende voorbeelduitvoer, waarin wordt weergegeven dat de pod is gepland en de status Wordt uitgevoerd:

    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 functioneren.

  4. 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 Azure Portal verwijderen met behulp van de volgende stappen:

  1. Navigeer naar het deelvenster Beleid in Azure Portal.
  2. Selecteer Opdrachten.
  3. Selecteer de knop ... naast de beveiligingsbasislijnstandaarden voor kubernetes-clusterpods voor linux-workloads .
  4. Selecteer Toewijzing verwijderen.

Volgende stappen

Zie de volgende artikelen voor meer informatie over hoe Azure Policy werkt: