Freigeben über

Grundlegendes zu Azure Policy für Kubernetes-Cluster

  • Artikel

Azure Policy erweitert Gatekeeper v3, einen Webhook für die Zugangssteuerung für Open Policy Agent (OPA), um zentral und einheitlich bedarfsgesteuerte Erzwingungs- und Schutzmaßnahmen auf Ihre Clusterkomponenten anzuwenden. Clusterkomponenten umfassen Pods, Container und Namespaces.

Mithilfe von Azure Policy kann der Konformitätszustand Ihrer Kubernetes-Clusterkomponenten von einem zentralen Ort aus verwaltet und gemeldet werden. Wenn Sie das Add-On oder die Erweiterung von Azure Policy verwenden, wird die Steuerung Ihrer Clusterkomponenten durch Azure Policy-Features erweitert. Hierzu zählt beispielsweise die Möglichkeit, Selektoren und Außerkraftsetzungen für sichere Rollouts und Rollbacks von Richtlinien zu verwenden.

Von Azure Policy für Kubernetes werden folgende Clusterumgebungen unterstützt:

Wichtig

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

Überblick

Durch die Installation des Azure Policy-Add-Ons oder der Azure Policy-Erweiterung in Ihren Kubernetes-Clustern führt Azure Policy folgenden Funktionen aus:

  • Überprüfen auf Richtlinienzuweisungen für den Cluster mit dem Azure Policy-Dienst
  • Bereitstellen von Richtliniendefinitionen im Cluster als benutzerdefinierte Ressourcen vom Typ Einschränkungsvorlage und Einschränkung oder als Mutationsvorlagenressource (je nach Inhalt der Richtliniendefinition)
  • Senden von Details zur Überwachung und Konformität zurück an den Azure Policy-Dienst

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

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

    Hinweis

    Informationen zu häufigen Problemen bei der Installation finden Sie unter Problembehandlung – Azure Policy-Add-On.

  2. Erstellen oder verwenden Sie eine exemplarische Azure Policy-Definition 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 des Azure Policy-Add-Ons für AKS

Das Azure Policy-Add-On für AKS ist Teil von Kubernetes Version 1.27 mit LTS (Long-Term Support, langfristiger Support).

Voraussetzungen

  1. Registrieren Sie die Ressourcenanbieter und die Previewfunktionen.

    • Azure-Portal:

      Registrieren Sie den Ressourcenanbieter Microsoft.PolicyInsights. 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. Azure CLI-Version 2.12.0 oder höher muss installiert und konfiguriert sein. Führen Sie den Befehl az --version aus, um die Version zu ermitteln. Installations- und Upgradeinformationen finden Sie bei Bedarf unter Installieren der 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 sowie um die Konformität des Clusters zurück an Azure Policy zu melden.

    Domain Port
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

Nachdem die Voraussetzungen erfüllt sind, installieren Sie das Azure Policy-Add-On in dem zu verwaltenden AKS-Cluster.

  • Azure-Portal

    1. Starten Sie den AKS-Dienst im Azure-Portal, indem Sie die Option Alle Dienste auswählen und dann nach Kubernetes-Dienste suchen und die entsprechende Option 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 ausgeführt werden:

# 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

Vergewissern Sie sich abschließend, dass das neueste Add-On installiert ist. Führen Sie hierzu den folgenden Azure CLI-Befehl aus, und ersetzen Sie dabei <rg> durch den Namen Ihrer Ressourcengruppe und <cluster-name> durch den Namen Ihres AKS-Clusters: 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 der Azure Policy-Erweiterung für Kubernetes mit Azure Arc-Unterstützung

Mithilfe von Azure Policy für Kubernetes kann der Konformitätszustand Ihrer Kubernetes-Cluster von einem zentralen Ort aus verwaltet und gemeldet werden. Mit der Azure Policy-Erweiterung für Kubernetes-Cluster mit Arc-Unterstützung können Sie Ihre Kubernetes-Clusterkomponenten mit Arc-Unterstützung steuern (beispielsweise Pods und Container).

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

Eine Übersicht der Erweiterungsplattform finden Sie unter Azure Arc-Clustererweiterungen.

Voraussetzungen

Wenn Sie Azure Policy für Kubernetes bereits in einem Azure Arc-Cluster mittels Helm direkt ohne Erweiterungen bereitgestellt haben, befolgen Sie die Anweisungen zum Löschen des Helm-Charts. 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 Arc-Erweiterung wird in den folgenden Kubernetes-Distributionen unterstützt.

  2. Stellen Sie sicher, dass alle hier aufgeführten allgemeinen Voraussetzungen für Kubernetes-Erweiterungen erfüllt sind, einschließlich des Verbindens Ihres Clusters mit Azure Arc.

    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 sowie um die Konformität des Clusters zurück an Azure Policy zu melden.

    Domain Port
    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 eins der Dienstfeatures aktivieren, müssen Sie in Ihrem Abonnement den Ressourcenanbieter Microsoft.PolicyInsights aktivieren.

    Hinweis

    Zum Aktivieren des Ressourcenanbieters führen Sie die Schritte unter Ressourcenanbieter und -typen aus, oder führen Sie entweder den Azure CLI- oder Azure PowerShell-Befehl 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 der Azure Policy-Erweiterung

Hinweis

Beachten Sie Folgendes beim Erstellen der Azure Policy-Erweiterung:

  • Automatische Upgrades sind standardmäßig aktiviert, wodurch 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 den Proxy für ausgehenden Datenverkehr 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"
}

Anzeigen der Azure Policy-Erweiterung

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 des Erweiterung erfolgreich war und die Pods „azure-policy“ und „gatekeeper“ ausgeführt werden:

# 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 der 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 Struktur der Azure Policy-Sprache für die Verwaltung von Kubernetes orientiert sich an der Struktur bereits vorhandener Richtliniendefinitionen. Es stehen zuweisbare Beispieldefinitionsdateien in der integrierten Richtlinienbibliothek von Azure Policy zur Verfügung, die zum Steuern Ihrer Clusterkomponenten verwendet werden können.

Azure Policy für Kubernetes unterstützt auch die Erstellung benutzerdefinierter Definitionen auf Komponentenebene für Azure Kubernetes Service-Cluster und für Kubernetes-Cluster mit Azure Arc-Unterstützung. Beispiele für Einschränkungs- und Mutationsvorlagen stehen in der Gatekeeper-Communitybibliothek zur Verfügung. Die Visual Studio Code-Erweiterung von Azure Policy kann verwendet werden, um eine vorhandene Einschränkungs- oder Mutationsvorlage in eine benutzerdefinierte Azure Policy-Richtliniendefinition umzuwandeln.

Mit dem Ressourcenanbietermodus Microsoft.Kubernetes.Data werden die Auswirkungen von audit, deny, disabled und mutate zum Verwalten Ihrer Kubernetes-Cluster verwendet.

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

Als Teil der Eigenschaften vom Typ details.templateInfo oder details.constraintInfo in der Richtliniendefinition übergibt Azure Policy den URI oder den Base64Encoded-Werte dieser benutzerdefinierten Ressourcendefinitionen (CustomResourceDefinitions, CRDs) 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 bestehenden Standards für das Kubernetes-Management ermöglicht Azure Policy die Wiederverwendung bestehender Regeln und deren Kombination mit Azure Policy für eine einheitliche Berichterstellungsumgebung zur Cloud-Compliance. Weitere Informationen finden Sie unter Was ist Rego?

Zuweisen einer Richtliniendefinition

Um Ihrem Kubernetes-Cluster eine Richtliniendefinition zuweisen zu können, müssen Ihnen die entsprechenden Azure RBAC-Richtlinienzuweisungsvorgänge (Azure Role-Based Access Control, rollenbasierte Zugriffssteuerung) zugewiesen sein. Die in Azure integrierten Rollen Mitwirkender bei Ressourcenrichtlinien und Besitzer verfügen über diese Vorgänge. Weitere Informationen finden Sie unter Azure RBAC-Berechtigungen in Azure Policy.

Führen Sie die folgenden Schritte aus, um die integrierten Richtliniendefinitionen für die Verwaltung Ihres Clusters über das Azure-Portal zu finden. 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“ die Option Definitionen 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 Definition für Azure Policy für Kubernetes muss der Bereich 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 Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren nicht konformer Ressourcen, 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 prüft alle 15 Minuten mit dem Azure Policy-Dienst, ob sich die Richtlinienzuweisungen geändert haben. 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.

  • Kubernetes-Cluster mit Azure Arc-Unterstützung: admission.policy.azure.com/ignore

Hinweis

Ein Clusteradministrator verfügt zwar möglicherweise über die Berechtigung zum Erstellen und Aktualisieren von Einschränkungsvorlagen und -ressourcen, die durch das Azure Policy-Add-On installiert wurden, hierbei handelt es sich jedoch nicht um unterstützte Szenarien, da manuelle Updates überschrieben werden. Richtlinien, die vor der Installation des Add-Ons und vor der Zuweisung von Azure Policy-Richtliniendefinitionen vorhanden waren, werden weiterhin von Gatekeeper ausgewertet.

Das Add-On fordert alle 15 Minuten einen vollständigen Scan des Clusters an. Nachdem Details des vollständigen Scans und alle Echtzeitauswertungen von versuchten Änderungen am Cluster durch Gatekeeper erfasst wurden, meldet das Add-On die Ergebnisse an Azure Policy zurück, um sie in Konformitätsdetails wie bei allen Azure Policy-Zuweisungen aufzunehmen. 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 Konformitätsbericht in Azure Policy für Ihre Kubernetes-Cluster umfasst sämtliche Verstöße der letzten 45 Minuten. Der Zeitstempel gibt an, wann ein Verstoß aufgetreten ist.

Einige weitere Überlegungen:

  • Wenn das Cluster-Abonnement bei Microsoft Defender für Cloud registriert ist, wird Microsoft Defender für Cloud Kubernetes-Richtlinien automatisch 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 die gleiche Datei template.yaml, die an verschiedenen Quellspeicherorten gespeichert ist – z. B. im Azure Policy-Vorlagenspeicher (store.policy.core.windows.net) und auf 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 Überwachen der Leistung von Kubernetes-Clustern mit Azure Monitor für Container.

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-Fehler zu beheben, der in Ihren Complianceergebnissen angezeigt wird, können Sie die Azure Policy-Podprotokolle nach diesem Code durchsuchen, um den vollständigen Fehler anzuzeigen.

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 im Cluster installiert hat, werden beide mit Azure Policy-Informationen wie der Richtlinienzuweisungs-ID und der Richtliniendefinitions-ID kommentiert. 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 die folgende Azure CLI für einen Azure Kubernetes Service-Cluster:

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

Anzeigen der Add-On-Einschränkungsvorlagen

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 Behandlung von Problemen im Zusammenhang mit dem Add-On für Kubernetes finden Sie im Kubernetes-Abschnitt des Artikels zur Azure Policy-Problembehandlung.

Informationen zu Problemen im Zusammenhang mit der Azure Policy-Erweiterung für Arc finden Sie hier:

Informationen zu Problemen mit Azure Policy:

Azure Policy-Add-On für AKS-Änderungsprotokoll

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

In diesem Abschnitt erfahren Sie, wie Sie ermitteln, welche Add-On-Version in Ihrem Cluster installiert ist, und wie Sie eine historische Tabelle der pro AKS-Cluster installierten Azure Policy-Add-On-Version freigeben.

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

Das Azure Policy-Add-On verwendet für jede Version das Standardschema Semantische Versionierung. Um die Version des verwendeten Azure Policy-Add-Ons zu ermitteln, 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 ermitteln, 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.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 Analyse der Strukturrichtlinien, verringert die Latenz der Zulassungsanforderung 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 im Microsoft.ContainerService-Namespace für das Featureflag AKS-AzurePolicyK8sNativeValidation registrieren. Weitere Informationen finden Sie in der Gatekeeper-Dokumentation.

Verbesserungen der Sicherheit

  • Veröffentlicht im 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. Integrierte Elemente werden bald aktualisiert, um die Parametrisierung dieses Felds 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.

Verbesserungen der Sicherheit

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

1.6.1

Verbesserungen der Sicherheit

  • Veröffentlicht im Mai 2024
  • Gatekeeper 3.14.2

1.5.0

Verbesserungen der Sicherheit

  • Veröffentlicht im 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.

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

1.3.0

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

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

1.2.1

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

1.1.0

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

1.0.1

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

1.0.0

Azure Policy für Kubernetes unterstützt jetzt Mutationen zur Korrektur von AKS-Clustern im großen Stil.

Entfernen des Add-Ons

Entfernen des Add-Ons aus AKS

Verwenden Sie zum Entfernen des Azure Policy-Add-Ons aus Ihrem AKS-Cluster entweder das Azure-Portal oder die Azure CLI:

  • Azure-Portal

    1. Starten Sie den AKS-Dienst im Azure-Portal, indem Sie die Option Alle Dienste auswählen und dann nach Kubernetes-Dienste suchen und die entsprechende Option 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 des Add-Ins aus Kubernetes mit Azure Arc-Aktivierung

Hinweis

Das Azure Policy-Add-On Helm-Modell ist jetzt veraltet. Sie sollten stattdessen die Azure Policy-Erweiterung für Kubernetes mit Azure Arc-Unterstützung installieren.

Führen Sie den folgenden Helm-Befehl aus, um das Azure Policy-Add-On und Gatekeeper aus Ihrem Kubernetes-Cluster mit Azure Arc-Aktivierung zu entfernen:

helm uninstall azure-policy-addon

Entfernen des Add-Ons aus der AKS-Engine

Hinweis

Das AKS Modulprodukt ist jetzt für Azure Public Cloud-Kunden veraltet. Verwenden Sie ggf. Azure Kubernetes Service (AKS) für Managed Kubernetes oder Cluster-API-Anbieter in Azure für selbstverwaltete Kubernetes-Instanzen. 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.

Wenn Sie das Azure Policy Add-On und Gatekeeper aus dem AKS-Engine-Cluster entfernen möchten, verwenden Sie die Methode, die der Installationsweise des Add-Ons entspricht:

  • 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 Deaktivieren des Azure Policy-Add-Ons.

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

    helm uninstall azure-policy-addon

Begrenzungen

  • Allgemeine Azure Policy-Definitionen und Zuordnungsgrenzwerte finden Sie in den dokumentierten Grenzwerten von Azure Policy.
  • Das Azure Policy-Add-On für Kubernetes kann nur in 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.
  • Installationen von Gatekeeper außerhalb des Azure Policy-Add-Ons werden nicht unterstützt. Deinstallieren Sie alle Komponenten, die durch eine frühere Installation von Gatekeeper installiert wurden, bevor Sie das Azure Policy-Add-On aktivieren.
  • Ursachen für Nichtkonformität sind für den Ressourcenanbietermodus „Microsoft.Kubernetes.Data“ nicht verfügbar. Verwenden Sie Komponentendetails.
  • Ausnahmen auf Komponentenebene werden für Ressourcenanbietermodi nicht unterstützt. Parameterunterstützung ist in Azure Policy-Definitionen verfügbar, um bestimmte Namespaces aus- bzw. 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 in der Rego sowie durch das Vorhandensein der Anmerkung metadata.gatekeeper.sh/requires-sync-data unterschieden werden, die dem Azure Policy-Add-On mitteilt, welche Ressourcen 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 wird bei der Installation durch das Azure Policy-Add-On bzw. durch die Azure Policy-Erweiterung in meinem Cluster bereitgestellt?

Zur Verwendung des Azure Policy-Add-Ons müssen drei Gatekeeper-Komponenten ausgeführt werden: ein Überwachungspod und zwei Webhook-Podreplikate. Auch ein Azure Policy-Pod und ein Azure Policy-Webhook-Pod werden installiert.

Wie hoch fällt der Ressourcenverbrauch durch das Azure Policy-Add-On bzw. durch die Azure Policy-Erweiterung für jeden Cluster voraussichtlich aus?

Die Ressourcenverwendung der in Ihrem Cluster ausgeführten Komponenten von Azure Policy für Kubernetes ist direkt proportional zur Anzahl der Kubernetes-Ressourcen und Richtlinienzuweisungen im Cluster, was entsprechende Ü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.

Können Definitionen von Azure Policy für Kubernetes auf Windows-Pods angewendet werden?

Windows-Pods unterstützen keine Sicherheitskontexte. Daher können einige Azure Policy-Definitionen wie das Sperren von Rootberechtigungen in Windows-Pods nicht eskaliert werden und sind nur für Linux-Pods relevant.

Welche Diagnosedaten werden vom 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:

  • Azure Policy-Add-On auf dem neuesten Stand halten
  • Azure Policy-Add-On sicher, zuverlässig und leistungsfähig halten
  • Azure Policy-Add-On verbessern, und zwar 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:

  • Version des Azure Policy-Add-On-Agents
  • 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)
  • Land oder Region für den Cluster (Beispiel: USA)
  • Ausnahmen/Fehler, die während der Installation des Agents bei der Richtlinienauswertung durch das Azure Policy Add-On festgestellt werden
  • Anzahl von Gatekeeper-Richtliniendefinitionen, die nicht durch das Azure Policy-Add-On installiert wurden

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

  • 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 für den Cluster aad-pod-identity aktiviert wurde, werden die iptables der Knoten von NMI-Pods (Node Managed Identity) so geändert, dass Aufrufe des Azure Instance Metadata-Endpunkts abgefangen werden. 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). Installieren zur Konfiguration einer Ausnahme die YAML-Datei „mic-exception“.

Nächste Schritte