Freigeben über


Grundlegendes zu Azure Policy für Kubernetes-Cluster

Azure Policy erweitert Gatekeeper v3, einen Admissionscontroller-Webhook für Open Policy Agent (OPA), um skalierte Erzwingungen und Schutzmaßnahmen auf Ihre Clusterkomponenten auf einheitliche Weise anzuwenden. Clusterkomponenten umfassen Pods, Container und Namespaces.

Azure Policy ermöglicht es, den Compliancestatus Ihrer Kubernetes-Clusterkomponenten von einem Ort aus zu verwalten und zu melden. Wenn Sie das Add-On oder die Erweiterung von Azure Policy verwenden, wird die Verwaltung Ihrer Clusterkomponenten durch Azure Policy Features verbessert, z. B. die Möglichkeit, Selectors und overrides für das sichere Rollout und Rollback von Richtlinien zu verwenden.

Azure Policy für Kubernetes unterstützt die folgenden Clusterumgebungen:

Wichtig

Das Azure Policy Add-On Helm-Modell und das Add-On für die AKS-Engine wurden ausgemustert. Befolgen Sie die Anweisungen zum Entfernen der Add-Ons.

Wichtig

Installationen von Gatekeeper außerhalb des Azure Policy-Add-Ons werden nicht unterstützt. Deinstallieren Sie alle Komponenten, die von einer vorherigen Gatekeeper-Installation installiert wurden, bevor Sie das Azure Policy-Add-On aktivieren.

Überblick

Durch die Installation des Add-Ons oder der Erweiterung von Azure Policy auf Ihren Kubernetes-Clustern werden die folgenden Funktionen Azure Policy ausgeführt:

  • Überprüft mit dem Azure Policy-Dienst auf Richtlinienzuweisungen für den Cluster.
  • Bereitstellen von Richtliniendefinitionen im Cluster als benutzerdefinierte Ressourcen vom Typ Einschränkungsvorlage und Einschränkung oder als Mutationsvorlagenressource (je nach Inhalt der Richtliniendefinition)
  • Meldet Überwachungs- und Compliancedetails zurück zum Azure Policy Dienst.

Gehen Sie wie folgt vor, um Azure Policy mit Ihrem Kubernetes-Cluster zu aktivieren und zu verwenden:

  1. Konfigurieren Sie Ihren Kubernetes-Cluster, und installieren Sie den Azure Kubernetes Service (AKS)-Add-On oder die Erweiterung Azure Policy für Arc-fähige Kubernetes-Cluster (je nach Clustertyp).

    Hinweis

    Häufige Probleme bei der Installation finden Sie unter Troubleshoot - Azure Policy Add-On.

  2. Erstellen oder verwenden Sie eine Beispiel-Azure-Richtliniendefinition für Kubernetes

  3. Weisen Sie Ihrem Kubernetes-Cluster eine Definition zu.

  4. Warten auf die Validierung

  5. Protokollierung und Problembehandlung

  6. Informieren Sie sich über Einschränkungen, und sehen Sie sich die Empfehlungen in unseren häufig gestellten Fragen an.

Installieren Azure Policy Add-Ons für AKS

Das Azure Policy-Add-On für AKS ist Teil von Kubernetes Version 1.27 mit langfristiger Unterstützung (LTS).

Voraussetzungen

  1. Registrieren Sie die Ressourcenanbieter und die Previewfunktionen.

    • Azure Portal:

      Registrieren Sie die Microsoft.PolicyInsights-Ressourcenanbieter. Weitere Informationen finden Sie unter Ressourcenanbieter und -typen.

    • Azure CLI:

      # Log in first with az login if you're not using Cloud Shell
      
      # Provider register: Register the Azure Policy provider
      az provider register --namespace Microsoft.PolicyInsights
      
  2. Sie benötigen die Azure CLI Version 2.12.0 oder höher installiert und konfiguriert. Führen Sie den Befehl az --version aus, um die Version zu ermitteln. Informationen zum Installieren oder Aktualisieren finden Sie unter Wie installieren Sie die Azure CLI.

  3. Der AKS-Cluster muss eine unterstützte Kubernetes-Version in Azure Kubernetes Service (AKS) sein. Verwenden Sie das folgende Skript, um Ihre AKS-Clusterversion zu überprüfen:

    # Log in first with az login if you're not using Cloud Shell
    
    # Look for the value in kubernetesVersion
    az aks list
    
  4. Öffnen Sie Ports für die Azure Policy-Erweiterung. Die Azure Policy-Erweiterung verwendet diese Domänen und Ports, um Richtliniendefinitionen und Zuweisungen abzurufen und die Kompatibilität des Clusters zurück an Azure Policy zu melden.

    Domäne Hafen
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

Installieren Sie nach Abschluss der erforderlichen Komponenten das Azure Policy-Add-On im AKS-Cluster, den Sie verwalten möchten.

  • Azure Portal

    1. Starten Sie den AKS-Dienst im Azure-Portal, indem Sie All services auswählen und dann nach Kubernetes services suchen und auswählen.

    2. Wählen Sie einen Ihrer AKS-Cluster aus.

    3. Wählen Sie links Richtlinien auf der Seite des Kubernetes-Diensts aus.

    4. Wählen Sie auf der Hauptseite die Schaltfläche Add-On aktivieren aus.

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell
    
    az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
    

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Installation des Add-Ons erfolgreich war und die Pods azure-policy und gatekeeper laufen:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Überprüfen Sie abschließend, ob das neueste Add-On installiert ist, indem Sie diesen Azure CLI Befehl ausführen, indem Sie <rg> durch ihren Ressourcengruppennamen und <cluster-name> durch den Namen Ihres AKS-Clusters ersetzen: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. Für Cluster mit Dienstprinzipalen sollte die Ausgabe in etwa wie folgt aussehen:

{
  "config": null,
  "enabled": true,
  "identity": null
}

Und für Cluster mit verwalteten Identitäten sollte die Ausgabe in etwa wie folgt aussehen:

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Installieren Azure Policy Erweiterung für Azure Arc aktivierte Kubernetes

Azure Policy für Kubernetes ermöglicht es, den Compliancestatus Ihrer Kubernetes-Cluster von einem Ort aus zu verwalten und zu melden. Mit Azure Policy Erweiterung für Arc-fähige Kubernetes-Cluster können Sie Ihre Arc-fähigen Kubernetes-Clusterkomponenten wie Pods und Container steuern.

In diesem Artikel wird beschrieben, wie Sie die Azure Policy für die Kubernetes-Erweiterung erstellen, den Erweiterungsstatus anzeigen und löschen.

Eine Übersicht über die Erweiterungsplattform finden Sie unter Azure Arc Clustererweiterungen.

Voraussetzungen

Wenn Sie bereits Azure Policy für Kubernetes auf einem Azure Arc-Cluster mithilfe von Helm direkt ohne Erweiterungen bereitgestellt haben, befolgen Sie diese Anweisungen, um das Helm-Chart zu löschen. Sobald der Löschvorgang erfolgt ist, können Sie fortfahren.

  1. Stellen Sie sicher, dass Ihr Kubernetes-Cluster eine unterstützte Distribution ist.

    Hinweis

    Die Azure Policy für die Arc-Erweiterung wird auf die folgenden Kubernetes-Verteilungen unterstützt.

  2. Stellen Sie sicher, dass Sie alle allgemeinen Voraussetzungen für Kubernetes-Erweiterungen erfüllt haben, die here einschließlich Verbinden Des Clusters mit Azure Arc aufgeführt sind.

    Hinweis

    Die Azure Policy Erweiterung wird für Kubernetes-Cluster mit Arc-Unterstützung in diesen Regionen unterstützt.

  3. Öffnen Sie Ports für die Azure Policy-Erweiterung. Die Azure Policy-Erweiterung verwendet diese Domänen und Ports, um Richtliniendefinitionen und Zuweisungen abzurufen und die Kompatibilität des Clusters zurück an Azure Policy zu melden.

    Domäne Hafen
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443
  4. Bevor Sie die Azure Policy-Erweiterung installieren oder eines der Dienstfeatures aktivieren, muss Ihr Abonnement die Microsoft.PolicyInsights-Ressourcenanbieter aktivieren.

    Hinweis

    Führen Sie zum Aktivieren des Ressourcenanbieters die Schritte in Ressourcenanbietern und -typen aus, oder führen Sie entweder den Befehl Azure CLI oder Azure PowerShell aus.

    • Azure CLI

      # Log in first with az login if you're not using Cloud Shell
      # Provider register: Register the Azure Policy provider
      az provider register --namespace 'Microsoft.PolicyInsights'
      
    • Azure PowerShell

      # Log in first with Connect-AzAccount if you're not using Cloud Shell
      
      # Provider register: Register the Azure Policy provider
      Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
      

Erstellen Sie eine Azure Policy-Erweiterung

Hinweis

Beachten Sie Folgendes für Azure Policy Erweiterungserstellung:

  • Das automatische Upgrade ist standardmäßig aktiviert, indem die Nebenversion der Azure Policy-Erweiterung aktualisiert wird, wenn neue Änderungen bereitgestellt werden.
  • Alle Proxyvariablen, die als Parameter an connectedk8s übergeben werden, werden an die Azure Policy Erweiterung weitergegeben, um ausgehenden Proxy zu unterstützen.

Führen Sie zum Erstellen einer Erweiterungsinstanz für Ihren Cluster mit Arc-Unterstützung den folgenden Befehl aus, wobei Sie <> durch Ihre Werte ersetzen:

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

Beispiel:

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

Beispielausgabe:

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Azure Policy Erweiterung anzeigen

Um zu überprüfen, ob die Erstellung der Erweiterungsinstanz erfolgreich war, und die Metadaten der Erweiterung zu überprüfen, führen Sie den folgenden Befehl aus, wobei Sie <> durch Ihre Werte ersetzen:

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Beispiel:

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Installation der Erweiterung erfolgreich war und die Pods „azure-policy“ und „gatekeeper“ laufen.

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Löschen Sie die Azure Policy-Erweiterung

Um die Erweiterungsinstanz zu löschen, führen Sie den folgenden Befehl aus, wobei Sie <> durch Ihre Werte ersetzen:

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Erstellen einer Richtliniendefinition

Die Azure Policy Sprachstruktur für die Verwaltung von Kubernetes folgt der der vorhandenen Richtliniendefinitionen. Es stehen Beispieldefinitionsdateien zur Verfügung, die in der integrierten Richtlinienbibliothek Azure Policy zugewiesen werden können, die zum Steuern der Clusterkomponenten verwendet werden können.

Azure Policy für Kubernetes unterstützt auch die Erstellung von benutzerdefinierten Definitionen auf Komponentenebene für den Azure Kubernetes Service Cluster und den Azure Arc-fähigen Kubernetes-Cluster. Beispiele für Einschränkungs- und Mutationsvorlagen stehen in der Gatekeeper-Communitybibliothek zur Verfügung. Azure Policy Visual Studio Code Extension kann verwendet werden, um eine vorhandene Einschränkungsvorlage oder Mutationsvorlage in eine benutzerdefinierte Azure Policy Richtliniendefinition zu übersetzen.

Mit einem Ressourcenerweiterungsmodus von Microsoft.Kubernetes.Data werden die Effekte audit, deny, disabled und mutate genutzt, um Ihre Kubernetes-Cluster zu verwalten.

Audit und deny müssen details-Eigenschaften bereitstellen, die für das Arbeiten mit dem OPA Constraint Framework und Gatekeeper v3 spezifisch sind.

Im Rahmen der details.templateInfo oder details.constraintInfoEigenschaften in der Richtliniendefinition, Azure Policy übergibt den URI oder Base64Encoded Wert dieser CustomResourceDefinitions(CRD) an das Add-On. Rego ist die Sprache, die von OPA und Gatekeeper unterstützt wird, um eine Anforderung an den Kubernetes-Cluster zu validieren. Durch die Unterstützung eines vorhandenen Standards für die Kubernetes-Verwaltung ermöglicht Azure Policy die Wiederverwendung vorhandener Regeln und das Koppeln mit Azure Policy für eine einheitliche Berichterstattung in der Cloud. Weitere Informationen finden Sie unter Was ist Rego?

Zuweisen einer Richtliniendefinition

Um Ihrem Kubernetes-Cluster eine Richtliniendefinition zuzuweisen, müssen Sie die entsprechenden Berechtigungen für die Zuweisungsvorgänge der Azure rollenbasierten Zugriffskontrolle (Azure RBAC) besitzen. Die Azure integrierten Rollen Ressourcenrichtlinien-Mitwirkender und Besitzer haben diese Vorgänge. Weitere Informationen finden Sie unter Azure RBAC-Berechtigungen in Azure Policy.

Suchen Sie die integrierten Richtliniendefinitionen für die Verwaltung Ihres Clusters mithilfe des Azure Portals mit den folgenden Schritten. Wenn Sie eine benutzerdefinierte Richtliniendefinition verwenden, suchen Sie nach deren Namen oder der Kategorie, mit der Sie sie erstellt haben.

  1. Starten Sie den Azure Policy-Dienst im Azure-Portal. Wählen Sie Alle Dienste im linken Bereich aus, suchen Sie dann nach der Option Richtlinie und wählen Sie sie aus.

  2. Wählen Sie im linken Bereich der seite Azure Policy Definitions aus.

  3. Verwenden Sie im Dropdown-Listenfeld „Kategorie“ die Option Alle auswählen, um den Filter zu löschen, und wählen Sie dann Kubernetes aus.

  4. Wählen Sie die Richtliniendefinition und dann die Schaltfläche Zuweisen aus.

  5. Legen Sie den Bereich auf die Verwaltungsgruppe, das Abonnement oder die Ressourcengruppe des Kubernetes-Clusters fest, in dem die Richtlinienzuweisung angewendet wird.

    Hinweis

    Beim Zuweisen der Azure Policy-Definition für Kubernetes muss der Scope die Clusterressource enthalten.

  6. Weisen Sie der Richtlinienzuweisung einen Namen und eine Beschreibung zu, die Sie zur einfachen Identifizierung verwenden können.

  7. Legen Sie die Richtlinienerzwingung auf einen der folgenden Werte fest:

    • Aktiviert: Erzwingen Sie die Richtlinie auf dem Cluster. Kubernetes-Zulassungsanforderungen mit Verstößen werden verweigert.

    • Deaktiviert: Erzwingen Sie die Richtlinie nicht auf dem Cluster. Kubernetes-Zulassungsanforderungen mit Verstößen werden nicht verweigert. Die Ergebnisse der Konformitätsbewertung sind weiterhin verfügbar. Wenn Sie neue Richtliniendefinitionen für aktive Cluster einführen, ist die Option Deaktiviert hilfreich, um die Richtliniendefinition zu testen, da Zulassungsanforderungen mit Verstößen nicht verweigert werden.

  8. Wählen Sie Weiter aus.

  9. Festlegen von Parameterwerten

    • Geben Sie die Liste der Namespaces im Parameter Namespaceausschlüsse an, um Kubernetes-Namespaces aus der Richtlinienauswertung auszuschließen. Es wird empfohlen, Folgendes auszuschließen: kube-system, gatekeeper-system und azure-arc.
  10. Klicken Sie auf Überprüfen + erstellen.

Verwenden Sie alternativ den Quickstart: Richtlinie zuweisen - Portal, um eine Kubernetes-Richtlinie zu finden und zuzuweisen. Suchen Sie nach einer Kubernetes-Richtliniendefinition anstelle der Stichprobe audit vms.

Wichtig

Integrierte Richtliniendefinitionen stehen für Kubernetes-Cluster in der Kategorie Kubernetes zur Verfügung. Eine Liste der integrierten Richtliniendefinitionen finden Sie unter Kubernetes-Beispiele.

Richtlinienauswertung

Das Add-On meldet sich alle 15 Minuten beim Azure Policy-Dienst, um Änderungen an Richtlinienzuweisungen zu überprüfen. Während dieses Aktualisierungszyklus nimmt das Add-On eine Prüfung auf Änderungen vor. Diese Änderungen lösen das Erstellen, Aktualisieren oder Löschen der Einschränkungsvorlagen und Einschränkungen aus.

Wenn ein Namespace in einem Kubernetes-Cluster über die dem Cluster entsprechende Bezeichnungen verfügt, werden die Zulassungsanforderungen mit Verstößen nicht verweigert. Die Ergebnisse der Konformitätsbewertung sind weiterhin verfügbar.

  • Azure Arc-fähiger Kubernetes-Cluster: admission.policy.azure.com/ignore

Hinweis

Während ein Clusteradministrator möglicherweise über die Berechtigung zum Erstellen und Aktualisieren von Einschränkungsvorlagen und Einschränkungsressourcen verfügt, die vom Azure Policy-Add-On installiert werden, werden diese Szenarien nicht unterstützt, da manuelle Updates überschrieben werden. Gatekeeper bewertet weiterhin Richtlinien, die vor der Installation des Add-Ons vorhanden waren, und weist Azure Policy Richtliniendefinitionen zu.

Das Add-On fordert alle 15 Minuten einen vollständigen Scan des Clusters an. Nach der Erfassung der Details des vollständigen Scans und aller in Echtzeit von Gatekeeper bewerteten Änderungsversuche am Cluster gibt das Add-On die Ergebnisse an Azure Policy zurück, um in Compliance-Einzelheiten aufgenommen zu werden, wie bei jeder Azure Policy-Zuweisung. Während des Prüfzyklus werden nur Ergebnisse für aktive Richtlinienzuweisungen zurückgegeben. Prüfungsergebnisse können auch als Violations (Verstöße) angezeigt werden, die im Statusfeld der fehlerhaften Einschränkung aufgeführt sind. Weitere Informationen zu nicht konformen Ressourcen finden Sie unter Komponentendetails für Ressourcenanbietermodi.

Hinweis

Jeder Compliancebericht in Azure Policy für Ihre Kubernetes-Cluster umfasst alle Verletzungen innerhalb der letzten 45 Minuten. Der Zeitstempel gibt an, wann ein Verstoß aufgetreten ist.

Einige weitere Überlegungen:

  • Wenn das Clusterabonnement bei Microsoft Defender for Cloud registriert ist, werden automatisch Microsoft Defender for Cloud Kubernetes-Richtlinien auf den Cluster angewendet.

  • Wenn eine Ablehnungsrichtlinie auf einen Cluster mit vorhandenen Kubernetes-Ressourcen angewendet wird, werden alle ggf. bereits vorhandenen Ressourcen, die nicht mit der neuen Richtlinie konform sind, weiterhin ausgeführt. Wenn die nicht konforme Ressource auf einem anderen Knoten neu geplant wird, wird die Ressourcenerstellung durch Gatekeeper blockiert.

  • Wenn ein Cluster über eine Ablehnungsrichtlinie verfügt, durch die Ressourcen überprüft werden, bekommt der Benutzer beim Erstellen einer Bereitstellung keine Ablehnungsmeldung. Betrachten Sie beispielsweise eine Kubernetes-Bereitstellung, die replicasets und Pods enthält. Wenn ein Benutzer kubectl describe deployment $MY_DEPLOYMENT ausführt, wird im Rahmen von Ereignissen keine Ablehnungsmeldung zurückgegeben. Von kubectl describe replicasets.apps $MY_DEPLOYMENT werden jedoch die mit der Ablehnung zusammenhängenden Ereignisse zurückgegeben.

Hinweis

Init-Container können während der Richtlinienauswertung eingeschlossen werden. Um zu überprüfen, ob Init-Container enthalten sind, überprüfen Sie die CRD auf die folgende oder eine ähnliche Deklaration:

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

Konflikte mit Einschränkungsvorlagen

Wenn Einschränkungsvorlagen denselben Ressourcenmetadatennamen haben, die Richtliniendefinition aber an verschiedenen Stellen auf die Quelle verweist, gelten die Richtliniendefinitionen als in Konflikt miteinander. Beispiel: Zwei Richtliniendefinitionen verweisen auf dieselbe template.yaml-Datei, die an verschiedenen Quellspeicherorten gespeichert ist, z. B. den Azure Policy Vorlagenspeicher (store.policy.core.windows.net) und GitHub.

Wenn Richtliniendefinitionen und die zugehörigen Beschränkungsvorlagen zugewiesen werden, aber noch nicht auf dem Cluster installiert sind und es zu Konflikten kommt, werden sie als Konflikt gemeldet und erst dann im Cluster installiert, wenn der Konflikt gelöst ist. Ebenso funktionieren alle vorhandenen Richtliniendefinitionen und ihre Einschränkungsvorlagen, die sich bereits im Cluster befinden und mit neu zugewiesenen Richtliniendefinitionen in Konflikt stehen, weiterhin normal. Wenn eine vorhandene Zuweisung aktualisiert wird und die Einschränkungsvorlage nicht synchronisiert werden kann, wird der Cluster ebenfalls als konfliktbehaftet eingestuft. Informationen zu allen Konfliktmeldungen finden Sie unter Konformitätsgründe für den AKS-Ressourcenanbietermodus.

Protokollierung

Als Kubernetes-Controller/-Container speichern die Pods azure-policy und gatekeeper Protokolle im Kubernetes-Cluster. Im Allgemeinen können Azure-Richtlinien-Protokolle verwendet werden, um Probleme bei der Erfassung von Richtlinien im Cluster und bei der Konformitätsberichterstellung zu beheben. Die Podprotokolle des Gatekeeper-Controller-Managers können verwendet werden, um Laufzeitverweigerungen zu beheben. Die Podprotokolle desGatekeeper-Audits können zur Problembehandlung bei der Überwachung vorhandener Ressourcen verwendet werden. Die Protokolle können auf der Seite Insights des Kubernetes-Clusters verfügbar gemacht werden. Weitere Informationen finden Sie unter Monitor your Kubernetes cluster performance with Azure Monitor for containers.

Verwenden Sie kubectl, um die Add-On-Protokolle anzuzeigen:

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

Wenn Sie versuchen, einen bestimmten ComplianceReasonCode zu beheben, der in Ihren Complianceergebnissen erscheint, können Sie die Azure Policy-Pod-Protokolle nach diesem Code durchsuchen, um den vollständigen begleitenden Fehler zu sehen.

Weitere Informationen finden Sie in der Gatekeeper-Dokumentation unter Debuggen.

Anzeigen von Gatekeeper-Artefakten

Nachdem das Add-On die Richtlinienzuweisungen heruntergeladen und die Einschränkungsvorlagen und Einschränkungen auf dem Cluster installiert hat, versieht es beide mit Informationen zu Azure Policy, wie der Richtlinienzuweisungs-ID und der Richtliniendefinitions-ID. Führen Sie die folgenden Schritte aus, um Ihren Client zum Anzeigen der Add-On-bezogenen Artefakte zu konfigurieren:

  1. Richten Sie für den Cluster kubeconfig ein.

    Verwenden Sie für einen Azure Kubernetes Service Cluster die folgenden Azure CLI:

    # Set context to the subscription
    az account set --subscription <YOUR-SUBSCRIPTION>
    
    # Save credentials for kubeconfig into .kube in your home folder
    az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>
    
  2. Testen Sie die Clusterverbindung.

    Führen Sie den Befehl kubectl cluster-info aus. Bei einer erfolgreichen Ausführung antwortet jeder Dienst mit einer URL, unter der er ausgeführt wird.

Vorlagen für Add-On-Einschränkungen anzeigen

Führen Sie kubectl get constrainttemplates aus, um die vom Add-On heruntergeladenen Einschränkungsvorlagen anzuzeigen. Einschränkungsvorlagen, die mit k8sazure beginnen, werden vom Add-On installiert.

Anzeigen der Add-On-Mutationsvorlagen

Führen Sie kubectl get assign, kubectl get assignmetadata und kubectl get modifyset aus, um die vom Add-On heruntergeladenen Mutationsvorlagen anzuzeigen.

Abrufen von Azure Policy-Zuordnungen

Verwenden Sie kubectl get constrainttemplates <TEMPLATE> -o yaml, um die Zuordnung zwischen einer Einschränkungsvorlage, die in den Cluster heruntergeladen wurde, und der Richtliniendefinition zu identifizieren. Die Ergebnisse sehen in etwa wie in der folgenden Ausgabe aus:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> ist die Abonnement-ID und <GUID> die ID der zugeordneten Richtliniendefinition. <URL-OF-YAML> ist der Quellspeicherort der Einschränkungsvorlage, die das Add-On heruntergeladen hat, um es im Cluster zu installieren.

Sobald Sie über die Namen der heruntergeladenen Add-On-Einschränkungsvorlagen verfügen, können Sie den Namen verwenden, um die zugehörigen Einschränkungen anzuzeigen. Verwenden Sie kubectl get <constraintTemplateName>, um die Liste abzurufen. Vom Add-On installierte Einschränkungen beginnen mit azurepolicy-.

Anzeigen von Einschränkungsdetails

Die Einschränkung enthält Details zu Verstößen und Zuordnungen zur Richtliniendefinition und -zuweisung. Verwenden Sie kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml, um die Details anzuzeigen. Die Ergebnisse sehen in etwa wie in der folgenden Ausgabe aus:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

Behandeln von Problemen mit dem Add-On

Weitere Informationen zur Problembehandlung des Add-Ons für Kubernetes finden Sie im Abschnitt Kubernetes des Azure Policy Problembehandlungsartikels.

Weitere Informationen zu Problemen mit der Azure Policy-Erweiterung für die Arc-Erweiterung finden Sie unter:

Für Azure Policy verwandte Probleme gehen Sie zu:

Azure Policy Add-On für AKS Changelog

Azure Policy-Add-On für AKS weist eine Versionsnummer auf, die die Bildversion des Add-Ons angibt. Wenn eine neue Featureunterstützung im Add-On eingeführt wird, wird die Versionsnummer erhöht.

In diesem Abschnitt können Sie ermitteln, welche Add-On-Version auf Ihrem Cluster installiert ist, und außerdem eine historische Tabelle der Azure Policy Add-On-Version freigeben, die pro AKS-Cluster installiert ist.

Ermitteln, welche Add-On-Version in Ihrem Cluster installiert ist

Das Azure Policy-Add-On verwendet für jede Version das Standardschema Semantic Versioning. Um die verwendete Azure Policy Add-On-Version zu identifizieren, können Sie den folgenden Befehl ausführen: kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Um die Gatekeeper-Version zu identifizieren, die Ihr Azure Policy-Add-On verwendet, können Sie den folgenden Befehl ausführen: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Um die verwendete AKS-Clusterversion zu ermitteln, können Sie die verlinkte AKS-Anleitung verwenden.

Verfügbare Add-On-Versionen nach AKS-Clusterversion

1.16.1

Einführung der Validating Admission Policy (VAP)-Generierung. Bei der Überprüfung von Zulassungsrichtlinien handelt es sich um Kubernetes-systemeigene Überprüfungsrichtlinienressourcen, die im Prozess ausgewertet werden, was eine reduzierte Latenz und eine Fail-Close-Auswertung ermöglicht. Azure Richtlinien, die Common Expression Language (CEL) enthalten, generieren automatisch VAPs. Weitere Informationen finden Sie in der Gatekeeper-Dokumentation. Patch CVE-2026-25679, CVE-2026-27142, CVE-2026-27139 und CVE-2026-32280. Verbesserungen der Sicherheit

  • Veröffentlicht: Mai 2026
  • Kubernetes: 1.36+
  • Gatekeeper: 3.22.1
Gatekeeper 3.22.1

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.22.1 Änderungen: https://github.com/open-policy-agent/gatekeeper/compare/v3.20.1...v3.22.1

1.15.5

Verbesserungen der Sicherheit

  • Veröffentlicht: Februar 2026
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.1

1.15.4

Patch CVE-2025-61727. Verbesserungen der Sicherheit

  • Veröffentlicht: Dez 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.1

1.15.3

Patch CVE-2025-47914, CVE-2025-58181, CVE-2025-58187 und CVE-2025-22872. Verbesserungen der Sicherheit

  • Veröffentlicht: Dez 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.1

1.15.1

Verbesserungen der Sicherheit

  • Veröffentlicht: Nov 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.1

1.14.2

Patch CVE-2025-4802. Verbesserungen der Sicherheit

  • Veröffentlicht: Okt 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.1
Gatekeeper 3.20.1

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.1 Änderungen: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.1

1.13.1

Patch CVE-2025-47907. Verbesserungen der Sicherheit

  • Veröffentlicht: August 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.0

1.13.0

EU-Datengrenze wird jetzt von Azure Policy für Kubernetes auf AKS unterstützt. Weitere Informationen zur EU-Datengrenze finden Sie im Allgemeinen: Übersicht über die EU-Datengrenze. Patch CVE-2025-22874. Verbesserungen der Sicherheit

  • Veröffentlicht: Juli 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.20.0
Gatekeeper 3.20.0

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 Änderungen: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0

1.12.3

Patch CVE-2025-22874 und GHSA-vrw8-fxc6-2r93. Verbesserungen der Sicherheit

  • Veröffentlicht: Juli 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.19.1

1.12.2

Verbesserungen der Sicherheit

  • Veröffentlicht: Juni 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.19.1

1.11.1

Patch CVE-2025-22872. Verbesserungen der Sicherheit

  • Veröffentlicht: Mai 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.19.1
Gatekeeper 3.19.1

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 Änderungen: https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1

1.10.1

Patch CVE-2025-30204 und CVE-2025-22870. Verbesserungen der Sicherheit

  • Veröffentlicht: April 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.18.2

1.10.0

CEL ist standardmäßig aktiviert, Sie können Rego weiterhin verwenden. Die neue CRD configpodstatuses.status.gatekeeper.sh wird eingeführt (Referenz: https://github.com/open-policy-agent/gatekeeper/issues/2918). Verbesserungen der Sicherheit

  • Veröffentlicht: Februar 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.18.2
Gatekeeper 3.18.2

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 Änderungen: https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2

1.9.1

Patch CVE-2024-45337 und CVE-2024-45338. Verbesserungen der Sicherheit

  • Veröffentlicht: Januar 2025
  • Kubernetes: 1.27+
  • Gatekeeper: 3.17.1
Gatekeeper 3.17.1

Gatekeeper-Release: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.17.1

1.8.0

Azure Policy kann nun zur Bewertung von CONNECT-Vorgängen verwendet werden, z. B. um execs zu verweigern. Beachten Sie, dass es keine Brownfield-Compliance für nicht konforme CONNECT-Vorgänge gibt, sodass eine Richtlinie mit Audit-Effekt, die auf CONNECTs abzielt, wirkungslos ist. Verbesserungen der Sicherheit

  • Veröffentlicht: November 2024
  • Kubernetes: 1.27+
  • Gatekeeper: 3.17.1

1.7.1

Einführung in CEL und VAP. Common Expression Language (CEL) ist eine Kubernetes-native Ausdruckssprache, die zum Deklarieren von Gültigkeitsregeln einer Richtlinie verwendet werden kann. Das Feature „Validating Admission Policy (VAP)“ bietet eine Bewertung der internen Zulassungsrichtlinien, verringert die Latenz bei Zulassungsanfragen und verbessert die Zuverlässigkeit und Verfügbarkeit. Zu den unterstützten Überprüfungsaktionen gehören „Verweigern“, „Warnen“ und „Überwachung“. Die Erstellung benutzerdefinierter Richtlinien für CEL/VAP ist zulässig, und vorhandene Benutzer müssen ihre Rego nicht in CEL konvertieren, da sie sowohl unterstützt als auch zum Erzwingen von Richtlinien verwendet werden. Um CEL und VAP zu verwenden, müssen sich Benutzer für die Feature-Flagge AKS-AzurePolicyK8sNativeValidation im Namespace Microsoft.ContainerService einschreiben. Weitere Informationen finden Sie in der Gatekeeper-Dokumentation. Verbesserungen der Sicherheit

  • Veröffentlicht: September 2024
  • Kubernetes: 1.27+ (VAP-Generation wird nur auf 1,30+ unterstützt)
  • Gatekeeper: 3.17.1

1.7.0

Einführung in die Expansion, ein Shift-Left-Feature, mit dem Sie vorab wissen können, ob Ihre Workloadressourcen (Bereitstellungen, ReplicaSets, Aufträge usw.) zulässige Pods erzeugen werden. Die Expansion sollte das Verhalten Ihrer Richtlinien nicht ändern. Stattdessen verschiebt sie nur die Gatekeeper-Bewertung von Richtlinien im Pod-Bereich von der Pod-Zulassungszeit zur Workload-Zulassungszeit. Um diese Bewertung durchzuführen, muss sie jedoch einen „Was-wäre-wenn-Pod“ generieren und bewerten, der auf der in der Workload definierten Pod-Spezifikation basiert, die möglicherweise unvollständige Metadaten enthält. Beispielsweise enthält der „Was-wäre-wenn-Pod“ nicht die richtigen Besitzerverweise. Da dieses geringe Risiko besteht, dass sich das Richtlinienverhalten ändert, wird die Expansion standardmäßig als deaktiviert eingeführt. Um die Expansion für eine bestimmte Richtliniendefinition zu aktivieren, legen Sie .policyRule.then.details.source auf All fest. Eingebaute Funktionen werden bald aktualisiert, um die Parametrierung dieses Feldes zu ermöglichen. Wenn Sie Ihre Richtliniendefinition testen und feststellen, dass der generierte „Was-wäre-wenn-Pod“ für Bewertungszwecke unvollständig ist, können Sie auch eine Mutation mit der Quelle Generated verwenden, um die „Was-wäre-wenn-Pods“ zu mutieren. Weitere Informationen zu dieser Option finden Sie in der Gatekeeper-Dokumentation. Die Erweiterung ist derzeit nur auf AKS-Clustern verfügbar, nicht auf Arc-Clustern. Verbesserungen der Sicherheit

  • Veröffentlicht: Juli 2024
  • Kubernetes: 1.27+
  • Gatekeeper: 3.16.3

1.6.1

Verbesserungen der Sicherheit

  • Veröffentlicht: Mai 2024
  • Gatekeeper: 3.14.2

1.5.0

Verbesserungen der Sicherheit

  • Veröffentlicht: Mai 2024
  • Kubernetes: 1.27+
  • Gatekeeper: 3.16.3

1.4.0

Aktiviert standardmäßig Mutations- und externe Daten. Der zusätzliche mutierende Webhook und das erhöhte Zeitlimit für die Validierung des Webhooks können im schlimmsten Fall zu einer Verzögerung der Aufrufe führen. Außerdem wird Unterstützung für die Anzeige von Richtliniendefinitionen und Definitionsversionen von Sets in den Konformitätsergebnissen eingeführt. Verbesserungen der Sicherheit

  • Veröffentlicht: Mai 2024
  • Kubernetes: 1.25+
  • Gatekeeper: 3.14.0

1.3.0

Führt den Fehlerstatus für Richtlinien mit Fehlern ein, sodass sie von Richtlinien in nicht konformen Zuständen unterschieden werden können. Fügt Unterstützung für v1-Einschränkungsvorlagen und die Verwendung des excludedNamespaces Parameters in Mutationsrichtlinien hinzu. Fügt eine Fehlerstatusüberprüfung für Einschränkungsvorlagen nach der Installation hinzu. Verbesserungen der Sicherheit

  • Veröffentlicht: Februar 2024
  • Kubernetes: 1.25+
  • Gatekeeper: 3.14.0

1.2.1

Verbesserungen der Sicherheit

  • Veröffentlicht: Oktober 2023
  • Kubernetes: 1.25+
  • Gatekeeper: 3.13.3

1.1.0

Verbesserungen der Sicherheit

  • Veröffentlicht: Juli 2023
  • Kubernetes: 1.27+
  • Gatekeeper: 3.11.1

1.0.1

Verbesserungen der Sicherheit

  • Veröffentlicht: Juni 2023
  • Kubernetes: 1.24+
  • Gatekeeper: 3.11.1

1.0.0

Azure Policy für Kubernetes unterstützt jetzt Mutation zur Behebung von AKS-Clustern im großen Maßstab.

Entfernen des Add-Ons

Entfernen des Add-Ons aus AKS

Um das Azure Policy-Add-On aus Ihrem AKS-Cluster zu entfernen, verwenden Sie entweder das Azure Portal oder Azure CLI:

  • Azure Portal

    1. Starten Sie den AKS-Dienst im Azure-Portal, indem Sie All services auswählen und dann nach Kubernetes services suchen und auswählen.

    2. Wählen Sie Ihren AKS-Cluster aus, in dem Sie das Azure Policy-Add-On deaktivieren möchten.

    3. Wählen Sie links Richtlinien auf der Seite des Kubernetes-Diensts aus.

    4. Wählen Sie auf der Hauptseite die Schaltfläche Add-On deaktivieren aus.

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell
    
    az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
    

Entfernen Sie das Add-On von Azure Arc-aktivierten Kubernetes.

Hinweis

Azure Policy Add-On Helm-Modell ist jetzt veraltet. Sie sollten sich stattdessen für die Azure Policy Erweiterung für Azure Arc aktivierte Kubernetes entscheiden.

Um das Azure Policy Add-On und Gatekeeper aus Ihrem Azure Arc aktivierten Kubernetes-Cluster zu entfernen, führen Sie den folgenden Helm-Befehl aus:

helm uninstall azure-policy-addon

Entfernen des Add-Ons aus der AKS-Engine

Hinweis

Das AKS Engine-Produkt ist jetzt für Azure Öffentlichen Cloud-Kunden veraltet. Erwägen Sie die Verwendung von Azure Kubernetes Service (AKS) für verwaltete Kubernetes oder Cluster-API-Anbieter Azure für selbstverwaltete Kubernetes. Es sind keine neuen Funktionen geplant. Dieses Projekt wird nur für CVEs und ähnliches aktualisiert, wobei Kubernetes 1.24 die letzte Version ist, die Updates erhält.

Um das Azure Policy-Add-On und Gatekeeper aus Ihrem AKS Engine-Cluster zu entfernen, verwenden Sie die Methode, die an der Installation des Add-Ons ausgerichtet ist:

  • Bei Installation durch Festlegen der addons-Eigenschaft in der Clusterdefinition für die AKS-Engine:

    Stellen Sie die Clusterdefinition erneut für die AKS-Engine bereit, nachdem Sie die addons-Eigenschaft für azure-policy in „false“ geändert haben:

    "addons": [
      {
        "name": "azure-policy",
        "enabled": false
      }
    ]
    

    Weitere Informationen finden Sie unter AKS Engine – Deaktivieren Azure Policy Add-On.

  • Wenn die Installation mit Helm-Charts durchgeführt wurde, führen Sie den folgenden Helm-Befehl aus:

    helm uninstall azure-policy-addon
    

Begrenzungen

  • Überprüfen Sie die allgemeinen Richtliniendefinitionen und Zuordnungsgrenzwerte von Azure Policy, indem Sie die in der Azure Policy dokumentierten Grenzwerte durchsehen.
  • Azure Policy Add-On für Kubernetes kann nur für Linux-Knotenpools bereitgestellt werden.
  • Maximale Anzahl von Pods, die vom Azure Policy-Add-On pro Cluster unterstützt werden: 10.000
  • Maximale Anzahl nicht konformer Datensätze pro Richtlinie pro Cluster: 500
  • Maximale Anzahl nicht konformer Datensätze pro Abonnement: 1 Mio.
  • Gründe für die Nichteinhaltung sind für den Microsoft.Kubernetes.Data Ressourcenanbieter-Modus nicht verfügbar. Verwenden Sie Komponentendetails.
  • Ausnahmen auf Komponentenebene werden für Ressourcenanbietermodi nicht unterstützt. Die Parameterunterstützung ist in Azure Policy Definitionen verfügbar, um bestimmte Namespaces auszuschließen und einzuschließen.
  • Die Verwendung der Anmerkung metadata.gatekeeper.sh/requires-sync-data in einer Einschränkungsvorlage zum Konfigurieren der Replikation von Daten aus Ihrem Cluster im OPA-Cache ist derzeit nur für integrierte Richtlinien zulässig. Die Ursache dafür ist, dass sich die Ressourcenauslastung der Gatekeeper-Pods erheblich erhöhen kann, wenn sie nicht sorgfältig verwendet wird.

Konfigurieren der Gatekeeper-Konfiguration

Die Änderung der Gatekeeper-Konfiguration wird nicht unterstützt, da sie wichtige Sicherheitseinstellungen enthält. Die Änderungen an der Konfiguration werden abgeglichen.

Verwenden von data.inventory in Einschränkungsvorlagen

Derzeit nutzen mehrere integrierte Richtlinien die Datenreplikation, die es den Benutzern ermöglicht, vorhandene On-Cluster-Ressourcen mit dem OPA-Cache zu synchronisieren und während der Auswertung einer AdmissionReview-Anforderung auf sie zu verweisen. Datenreplikationsrichtlinien können durch das Vorhandensein von data.inventory im Rego unterschieden werden und das Vorhandensein der metadata.gatekeeper.sh/requires-sync-data Anmerkung, die das Azure Policy Addon informiert, welche Ressourcen für die Richtlinienauswertung zwischengespeichert werden müssen, damit die Richtlinienauswertung ordnungsgemäß funktioniert. Dieser Vorgang unterscheidet sich vom eigenständigen Gatekeeper, bei dem diese Anmerkung beschreibend und nicht vorschreibend ist.

Die Datenreplikation ist derzeit für die Verwendung in benutzerdefinierten Richtliniendefinitionen blockiert, da die Replikation von Ressourcen mit hoher Instanzanzahl die Ressourcenverwendung der Gatekeeper-Pods dramatisch erhöhen kann, wenn sie nicht sorgfältig eingesetzt wird. Wenn Sie versuchen, eine benutzerdefinierte Richtliniendefinition zu erstellen, die eine Beschränkungsvorlage mit dieser Anmerkung enthält, wird ein ConstraintTemplateInstallFailed-Fehler angezeigt.

Das Entfernen der Anmerkung scheint den Fehler, den Sie sehen, zu beheben, aber dann wird das Richtlinien-Addon keine erforderlichen Ressourcen für diese Beschränkungsvorlage in den Cache synchronisieren. Ihre Richtlinien werden also gegen ein leeres data.inventory ausgewertet (unter der Annahme, dass kein Built-in zugewiesen ist, das die erforderlichen Ressourcen repliziert). Dies führt zu irreführenden Complianceergebnissen. Wie bereits erwähnt, ist eine manuelle Bearbeitung der Konfiguration zum Zwischenspeichern der erforderlichen Ressourcen ebenfalls nicht zulässig.

Die folgenden Einschränkungen gelten nur für das Azure Policy-Add-On für AKS:

Häufig gestellte Fragen

Was stellt das Azure Policy-Add-On/Azure Policy Erweiterung bei der Installation auf meinem Cluster bereit?

Für das Azure Policy-Add-On müssen drei Gatekeeper-Komponenten ausgeführt werden: ein Audit-Pod und zwei Webhook-Pod-Replikate. Ein Azure Policy Pod und ein Azure Policy Webhook-Pod ist ebenfalls installiert.

Wie viel Ressourcenverbrauch sollte ich erwarten, dass das Azure Policy-Add-On/die Erweiterung für jeden Cluster verwendet wird?

Die Azure Policy für Kubernetes-Komponenten, die auf Ihrem Cluster ausgeführt werden, verbrauchen mehr Ressourcen, da die Anzahl der Kubernetes-Ressourcen und Richtlinienzuweisungen im Cluster zunimmt, was Überwachungs- und Erzwingungsvorgänge erfordert.

Im Anschluss finden Sie Schätzungen, um Sie bei der Planung zu unterstützen:

  • Bei weniger als 500 Pods in einem Cluster mit maximal 20 Einschränkungen sind zwei vCPUs und 350 MB Arbeitsspeicher pro Komponente erforderlich.
  • Bei mehr als 500 Pods in einem Cluster mit maximal 40 Einschränkungen sind drei vCPUs und 600 MB Arbeitsspeicher pro Komponente erforderlich.

Kann Azure Policy für Kubernetes-Definitionen auf Windows Pods angewendet werden?

Windows-Pods unterstützen keine Sicherheitskontexte. Daher können einige der Azure Policy Definitionen, z. B. das Aufheben von Stammrechten, nicht in Windows Pods eskaliert werden und gelten nur für Linux-Pods.

Welche Art von Diagnosedaten werden von Azure Policy Add-On gesammelt?

Das Azure Policy-Add-On für Kubernetes sammelt begrenzte Clusterdiagnosedaten. Diese Diagnosedaten sind wichtige technische Daten in Bezug auf Software und Leistung. Die Daten können folgendermaßen verwendet werden:

  • Halten Sie Azure Policy Add-On auf dem neuesten Stand.
  • Halten Sie Azure Policy Add-On sicher, zuverlässig und leistungsfähig.
  • Verbessern Sie Azure Policy Add-On – durch die aggregierte Analyse der Verwendung des Add-Ons.

Die vom Add-On gesammelten Informationen sind keine persönlichen Daten. Die folgenden Details werden derzeit gesammelt:

  • Azure Policy Add-On-Agentversion
  • Clustertyp
  • Clusterregion
  • Clusterressourcengruppe
  • Clusterressourcen-ID
  • Clusterabonnement-ID
  • Clusterbetriebssystem (Beispiel: Linux)
  • Ort für den Cluster (Beispiel: Seattle)
  • Bundesland oder Kanton für den Cluster (Beispiel: Washington)
  • Clusterland oder Region (Beispiel: USA)
  • Ausnahmen/Fehler, die von Azure Policy Add-on während der Installation des Agents bei der Richtlinienbewertung aufgetreten sind
  • Anzahl der Von Azure Policy Add-On nicht installierten Gatekeeper-Richtliniendefinitionen

Welche allgemeinen bewährten Methoden sollten Sie beim Installieren des Azure Policy-Add-Ons berücksichtigen?

  • Verwenden Sie zum Planen von Gatekeeper-Pods den Systemknotenpool mit einem CriticalAddonsOnly-Taint. Weitere Informationen finden Sie unter Verwenden von Systemknotenpools.
  • Schützen Sie von Ihren AKS-Clustern ausgehenden Datenverkehr. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten.
  • Wenn der Cluster aad-pod-identity aktiviert hat, ändern Node Managed Identity (NMI)-Pods die Knoten iptables, um Aufrufe des Azure Instanzmetadaten-Endpunkts abzufangen. Diese Konfiguration bedeutet, dass jede Anforderung, die an den Metadatenendpunkt gerichtet ist, von NMI abgefangen wird, auch wenn aad-pod-identity vom Pod nicht verwendet wird.
  • Die AzurePodIdentityException-CRD kann so konfiguriert werden, dass aad-pod-identity darüber informiert wird, dass an den Metadatenendpunkt gerichtete Anforderungen, die von einem Pod stammen, der in der CRD definierten Bezeichnungen entspricht, ohne Verarbeitung in NMI über einen Proxy weitergeleitet werden sollen. Die Systempods mit der Bezeichnung kubernetes.azure.com/managedby: aks im Namespace „kube-system“ müssen in aad-pod-identity durch Konfiguration der AzurePodIdentityException-CRD ausgeschlossen werden. Weitere Informationen finden Sie unter Disable aad-pod-identity for a specific pod or application (Deaktivieren von „aad-pod-identity“ für einen bestimmten Pod oder eine bestimmte Anwendung). Um eine Ausnahme zu konfigurieren, installieren Sie die mic-exception YAML.

Nächste Schritte