Schützen Ihres Clusters mit Azure Policy

Um die Sicherheit Ihres Azure Kubernetes Service-Clusters (AKS) zu verbessern, können Sie mithilfe von Azure Policy integrierte Sicherheitsrichtlinien auf den Cluster anwenden und erzwingen. Azure Policy unterstützt Sie bei der Durchsetzung von Organisationsstandards und der Bewertung der Compliance im großen Stil. Nachdem Sie das Azure Policy-Add-On für AKS installiert haben, können Sie einzelne Richtliniendefinitionen oder als Initiativen bezeichnete Gruppen von Richtliniendefinitionen (mitunter als Richtliniensätze bezeichnet) auf Ihren Cluster anwenden. Eine vollständige Liste der AKS-Richtlinien- und -Initiativendefinitionen finden Sie unter Integrierte Azure Policy-Definitionen für AKS.

In diesem Artikel wird gezeigt, wie Sie Richtliniendefinitionen auf Ihren Cluster anwenden und überprüfen, ob diese Zuweisungen erzwungen werden.

Voraussetzungen

Zuweisen einer integrierten Richtliniendefinition oder -initiative

Verwenden Sie das Azure-Portal, um eine Richtliniendefinition oder -initiative anzuwenden.

  1. Navigieren Sie im Azure-Portal zum Azure Policy-Dienst.
  2. Wählen Sie im linken Bereich der Seite „Azure Policy“ die Option Definitionen aus.
  3. Wählen Sie unter Kategorien die Option Kubernetes aus.
  4. Wählen Sie die Richtliniendefinition oder -initiative aus, die Sie anwenden möchten. Wählen Sie für dieses Beispiel die Initiative Kubernetes cluster pod security baseline standards for Linux-based workloads aus.
  5. Wählen Sie Zuweisen aus.
  6. Legen Sie Bereich auf die Ressourcengruppe des AKS-Clusters fest, für den das Azure Policy-Add-On aktiviert ist.
  7. Wählen Sie die Seite Parameter aus, und ändern Sie Auswirkung von audit in deny, um neue Bereitstellungen zu blockieren, die gegen die Baseline-Initiative verstoßen. Sie können auch zusätzliche Namespaces hinzufügen, die Sie von der Auswertung ausschließen möchten. Übernehmen Sie für dieses Beispiel die Standardwerte.
  8. Wählen Sie Überprüfen und erstellen und dann Erstellen aus, um die Richtlinienzuweisung zu übermitteln.

Erstellen und Zuweisen einer benutzerdefinierten Richtliniendefinition

Mit benutzerdefinierten Richtlinien können Sie Regeln für die Verwendung von Azure definieren. Beispielsweise können Sie Folgendes erzwingen:

  • Sicherheitsmaßnahmen
  • Kostenverwaltung
  • Organisationsspezifische Regeln (z. B. Benennung oder Speicherorte)

Überprüfen Sie vor dem Erstellen einer benutzerdefinierten Richtlinie die Liste der gängigen Muster und Beispiele, um zu überprüfen, ob Ihr Anwendungsfall bereits behandelt wurde.

Benutzerdefinierte Richtliniendefinitionen werden in JSON geschrieben. Weitere Informationen zum Erstellen einer benutzerdefinierten Richtlinie finden Sie unter Azure Policy-Definitionsstruktur und Erstellen einer benutzerdefinierten Richtliniendefinition.

Hinweis

Azure Policy verwendet jetzt eine neue Eigenschaft, die als templateInfo bezeichnet wird und es Benutzern ermöglicht, den Quelltyp für die Einschränkungsvorlage zu definieren. Durch Definieren von templateInfo in Richtliniendefinitionen müssen Benutzer keine constraintTemplate- oder constraint-Eigenschaften mehr definieren. Benutzer müssen allerdings weiterhin apiGroup- und kind-Eigenschaften definieren. Weitere Informationen hierzu finden Sie unter Grundlegendes zu Azure Policy-Auswirkungen.

Nachdem Ihre benutzerdefinierte Richtliniendefinition erstellt wurde, finden Sie unter Zuweisen einer Richtliniendefinition eine exemplarische Vorgehensweise als Schrittanleitung zum Zuweisen der Richtlinie zu Ihrem Kubernetes-Cluster.

Überprüfen, ob Azure Policy ausgeführt wird

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Richtlinienzuweisungen auf Ihren Cluster angewendet werden:

kubectl get constrainttemplates

Hinweis

Die Synchronisierung der Richtlinienzuweisungen in den einzelnen Clustern kann bis zu 20 Minuten dauern.

Die Ausgabe sollte in etwa wie folgt aussehen:

$ kubectl get constrainttemplate
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

Überprüfen der Ablehnung eines privilegierten Pods

Testen Sie als Erstes, was passiert, wenn Sie einen Pod mit dem Sicherheitskontext privileged: true planen. Dieser Sicherheitskontext weitet die Podberechtigungen aus. Die Initiative lässt keine privilegierten Pods zu, sodass die Anforderung abgelehnt wird, was wiederum zur Ablehnung der Bereitstellung führt.

Erstellen Sie eine Datei mit dem Namen nginx-privileged.yaml, und fügen Sie das folgende YAML-Manifest ein:

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

Erstellen Sie den Pod mithilfe des Befehls kubectl apply, und geben Sie den Namen Ihres YAML-Manifests an:

kubectl apply -f nginx-privileged.yaml

Der Pod kann wie erwartet nicht geplant werden, wie in der folgenden Beispielausgabe zu sehen:

$ kubectl apply -f nginx-privileged.yaml

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}

Da der Pod die Planungsphase nicht erreicht, müssen keine Ressourcen gelöscht werden, und Sie können direkt mit dem nächsten Schritt fortfahren.

Testen der Erstellung eines nicht privilegierten Pods

Im vorherigen Beispiel hat das Containerimage automatisch versucht, Stammberechtigungen zu verwenden, um NGINX an den Port 80 zu binden. Diese Anforderung wurde von der Richtlinieninitiative abgelehnt, sodass der Pod nicht gestartet werden kann. Lassen Sie uns jetzt versuchen, denselben NGINX-Pod ohne privilegierten Zugriff auszuführen.

Erstellen Sie eine Datei mit dem Namen nginx-unprivileged.yaml, und fügen Sie das folgende YAML-Manifest ein:

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

Erstellen Sie den Pod mithilfe des Befehls kubectl apply, und geben Sie den Namen Ihres YAML-Manifests an:

kubectl apply -f nginx-unprivileged.yaml

Der Pod wird erfolgreich geplant. Wenn Sie mithilfe des Befehls kubectl get pods den Status des Pods überprüfen, sehen Sie, dass der Pod ausgeführt wird (Running):

$ kubectl get pods

NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s

Dieses Beispiel zeigt die Baseline-Initiative, die sich nur auf Bereitstellungen auswirkt, die gegen Richtlinien in der Sammlung verstoßen. Zulässige Bereitstellungen funktionieren weiterhin.

Löschen Sie den nicht privilegierten NGINX-Pod mithilfe des Befehls kubectl delete, und geben Sie den Namen Ihres YAML-Manifests an:

kubectl delete -f nginx-unprivileged.yaml

Deaktivieren einer Richtlinie oder Initiative

So entfernen Sie die Baseline-Initiative

  1. Navigieren Sie im Azure-Portal zum Richtlinienbereich.
  2. Wählen Sie im linken Bereich Zuweisungen aus.
  3. Klicken Sie neben der Initiative Kubernetes cluster pod security baseline standards for Linux-based workloads auf die Schaltfläche mit den Auslassungspunkten ( ... ).
  4. Wählen Sie Zuweisung löschen aus.

Nächste Schritte

Weitere Informationen zur Funktionsweise von Azure Policy finden Sie hier: