Informazioni Criteri di Azure per i cluster Kubernetes

Criteri di Azure estende Gatekeeper v3, un webhook del controller admission per Open Policy Agent, per applicare controlli e misure di salvaguardia su ampia scala nei componenti del cluster in modo centralizzato e coerente. I componenti del cluster includono pod, contenitori e namespace.

Criteri di Azure consente di gestire e segnalare lo stato di conformità dei componenti del cluster Kubernetes da un'unica posizione. Usando il componente aggiuntivo o l'estensione di Criteri di Azure, con funzionalità delle policy di Azure come la possibilità di usare selectors e overrides per un'implementazione e revoca sicura dei criteri, la governance dei componenti del cluster è migliorata.

Criteri di Azure per Kubernetes supporta gli ambienti cluster seguenti:

• Servizio Azure Kubernetes (AKS), attraverso l'Add-on di Criteri di Azure per AKS
• Azure Arc abilitato Kubernetes tramite Estensione di Criteri di Azure per Arc

Panoramica

Installando l'estensione o il componente aggiuntivo di Criteri di Azure nei cluster Kubernetes, Criteri di Azure applica le funzioni seguenti:

• Verifica con il servizio Criteri di Azure per le assegnazioni di criteri al cluster.
• Distribuisce le definizioni dei criteri nel cluster come modello di vincolo e risorse personalizzate di vincolo o come risorsa modello di mutazione (a seconda del contenuto della definizione dei criteri).
• Segnala i dettagli di controllo e conformità al servizio Criteri di Azure.

Per abilitare e usare Criteri di Azure con il cluster Kubernetes, eseguire le azioni seguenti:

1. Configurare il cluster Kubernetes e installare il componente aggiuntivo Servizio Azure Kubernetes (AKS) o l'estensione di Criteri di Azure per i cluster Kubernetes abilitati per Arc (in base al tipo di cluster).

   Nota

   Per problemi comuni relativi all'installazione, vedere Risoluzione dei problemi - componente aggiuntivo di Criteri di Azure.

2. Creare o usare una definizione di Criteri di Azure di esempio per Kubernetes

3. Assegnare una definizione al cluster Kubernetes

4. Attendere la convalida

5. Registrazione e risoluzione dei problemi

6. Esaminare le limitazioni e i consigli nella sezione domande frequenti

Installare il componente aggiuntivo di Criteri di Azure per Azure Kubernetes Service (AKS)

Il componente aggiuntivo Criteri di Azure per AKS fa parte della versione 1.27 di Kubernetes con supporto a lungo termine (LTS).

Prerequisiti

1. Registrare i provider di risorse e le funzionalità di anteprima.

   • portale Azure:

     Registrare i fornitori di risorse Microsoft.PolicyInsights. Per le procedure, vedere Provider e tipi di risorse.

   • interfaccia della riga di comando di Azure:

     # 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. È necessaria la interfaccia della riga di comando di Azure versione 2.12.0 o successiva installata e configurata. Per trovare la versione, eseguire il comando az --version. Se è necessario installare o aggiornare, vedere Come installare il interfaccia della riga di comando di Azure.

3. Il cluster AKS deve essere una versione di Kubernetes supportata in Servizio Azure Kubernetes (AKS). Usare il seguente script per verificare la versione del cluster AKS:

   # Log in first with az login if you're not using Cloud Shell
   
   # Look for the value in kubernetesVersion
   az aks list
   

4. Aprire porte per l'estensione Criteri di Azure. L'estensione Criteri di Azure usa questi domini e porte per recuperare le definizioni e le assegnazioni dei criteri e segnalare la conformità del cluster a Criteri di Azure.

   Dominio	Porto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

Al termine dei prerequisiti, installare il componente aggiuntivo Criteri di Azure nel cluster AKS che si vuole gestire.

• portale di Azure

  1. Avviare il servizio Azure Kubernetes nel portale di Azure selezionando Tutti i servizi e poi cercare e selezionare Servizi Kubernetes.

  2. Seleziona uno dei tuoi cluster AKS.

  3. Selezionare Criteri sul lato sinistro della pagina del servizio Kubernetes.

  4. Nella pagina principale selezionare il pulsante Abilita componente aggiuntivo.

• interfaccia della riga di comando di Azure

  # 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
  

Per verificare che l'installazione del componente aggiuntivo sia stata completata correttamente e che i pod azure-policy e gatekeeper siano in esecuzione, eseguire il comando seguente:

# 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

Infine, verificare che l'estensione più recente sia installata tramite questo comando interfaccia della riga di comando di Azure, sostituendo <rg> con il nome del gruppo di risorse e <cluster-name> con il nome del cluster AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. Per cluster che usano entità servizio, il risultato dovrebbe essere simile all'output seguente:

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

E il seguente output dei cluster che utilizzano l'identità gestita:

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

Installare l'estensione Criteri di Azure per Kubernetes abilitato da Azure Arc

Criteri di Azure per Kubernetes consente di gestire e segnalare lo stato di conformità dei cluster Kubernetes da un'unica posizione. Con l'estensione di Criteri di Azure per i cluster Kubernetes abilitati per Arc, è possibile gestire i componenti del cluster Kubernetes abilitati per Arc, ad esempio pod e contenitori.

Questo articolo descrive come create, show extension status e delete l'estensione Criteri di Azure per Kubernetes.

Per una panoramica della piattaforma delle estensioni, vedere le estensioni del cluster di Azure Arc.

Prerequisiti

Se hai già distribuito Criteri di Azure per Kubernetes in un cluster Azure Arc utilizzando Helm direttamente senza estensioni, segui le istruzioni per eliminare il chart Helm. Al termine dell'eliminazione, è possibile procedere.

1. Assicurarsi che il cluster Kubernetes sia una distribuzione supportata.

   Nota

   Criteri di Azure per l'estensione Arc è supportata in le distribuzioni kubernetes seguenti.

2. Assicurarsi di soddisfare tutti i prerequisiti comuni per le estensioni Kubernetes elencate here inclusa connessione del cluster a Azure Arc.

   Nota

   L'estensione di Criteri di Azure è supportata per i cluster Kubernetes abilitati tramite Arc in queste aree.

3. Aprire porte per l'estensione Criteri di Azure. L'estensione Criteri di Azure usa questi domini e porte per recuperare le definizioni e le assegnazioni dei criteri e segnalare la conformità del cluster a Criteri di Azure.

   Dominio	Porto
   data.policy.core.windows.net	443
   store.policy.core.windows.net	443
   login.windows.net	443
   dc.services.visualstudio.com	443

4. Prima di installare l'estensione Criteri di Azure o abilitare una delle funzionalità del servizio, la sottoscrizione deve abilitare i provider di risorse Microsoft.PolicyInsights.

   Nota

   Per abilitare il provider di risorse, seguire i passaggi descritti in Resource providers and types oppure eseguire il comando interfaccia della riga di comando di Azure o Azure PowerShell.

   • interfaccia della riga di comando di Azure

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

Creare l'estensione Criteri di Azure

Per creare un'istanza di estensione per il cluster con abilitazione di Arc, eseguire il comando seguente sostituendo <> con i valori:

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

Esempio:

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

Output di esempio:

{
  "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"
}

Mostra estensione Criteri di Azure

Per verificare che la creazione dell'istanza dell'estensione sia riuscita ed esaminare i metadati dell'estensione, eseguire il comando seguente sostituendo <> con i valori:

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

Esempio:

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

Per verificare che l'installazione dell’estensione sia stata completata correttamente e che i pod azure-policy e gatekeeper siano in esecuzione, eseguire il comando seguente:

# 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

Eliminare l'estensione di Criteri di Azure

Per eliminare l'istanza dell'estensione, eseguire il comando seguente sostituendo <> con i valori:

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

Creare una definizione di criteri

La struttura del linguaggio Criteri di Azure per la gestione di Kubernetes segue quella delle definizioni di criteri esistenti. Sono disponibili file di definizione di esempio da assegnare nella libreria dei criteri predefinita di Criteri di Azure che può essere usata per gestire i componenti del cluster.

Criteri di Azure per Kubernetes supporta anche la creazione di definizioni personalizzate a livello di componente sia per i cluster servizio Azure Kubernetes che per i cluster Kubernetes abilitati per Azure Arc. I modelli di vincolo e gli esempi di modelli di mutazione sono disponibili nella libreria della community gatekeeper. È possibile usare Criteri di Azure Visual Studio Code Extension per convertire un modello di vincolo esistente o un modello di mutazione in una definizione di criteri di Criteri di Azure personalizzata.

Con una modalità Resource Provider di Microsoft.Kubernetes.Data, gli effetti audit, deny, disabled e mutate vengono utilizzati per gestire i cluster Kubernetes.

Il controllo e la negazione devono fornire details proprietà specifiche per l'uso di OPA Constraint Framework e Gatekeeper v3.

Come parte delle proprietà details.templateInfo o details.constraintInfo nella definizione dei criteri, Criteri di Azure passa il valore URI o Base64Encoded di questi CustomResourceDefinitions(CRD) al componente aggiuntivo. Rego è il linguaggio supportato da OPA e Gatekeeper per convalidare una richiesta al cluster Kubernetes. Supportando uno standard esistente per la gestione di Kubernetes, Criteri di Azure consente di riutilizzare le regole esistenti e associarle a Criteri di Azure per un'esperienza unificata di creazione di report sulla conformità al cloud. Per altre informazioni, vedere Che cos'è Rego?

Assegnare una definizione di politica

Per assegnare una definizione di criteri al cluster Kubernetes, è necessario essere assegnati alle operazioni di assegnazione delle politiche di controllo degli accessi basato sui ruoli di Azure (Azure RBAC) appropriate. I ruoli predefiniti Azure Resource Policy Contributor e Owner dispongono di queste operazioni. Per ulteriori informazioni, vedere autorizzazioni Azure RBAC in Criteri di Azure.

Trovare le definizioni di criteri predefinite per la gestione del cluster usando il portale di Azure con la procedura seguente. Se si usa una definizione di criteri personalizzata, cercarla in base al nome o alla categoria con cui è stata creata.

1. Avviare il servizio Criteri di Azure nel portale di Azure. Selezionare Tutti i servizi nel riquadro sinistro e quindi cercare e selezionare Criteri.

2. Nel riquadro sinistro della pagina Criteri di Azure selezionare Definitions.

3. Nella casella di riepilogo a discesa Categoria usare Seleziona tutto per cancellare il filtro e quindi selezionare Kubernetes.

4. Selezionare la definizione di criteri e quindi il pulsante Assegna.

5. Impostare l'Ambito sul gruppo di gestione, la sottoscrizione o il gruppo di risorse del cluster Kubernetes a cui si applica l'assegnazione dei criteri.

   Nota

   Quando si assegna la definizione di Criteri di Azure per Kubernetes, Scope deve includere la risorsa cluster.

6. Fornite all'assegnazione del criterio un Nome e una Descrizione che vi permettano di identificarla facilmente.

7. Impostare Tutela dei criteri sui valori seguenti:

   • Abilitata: applica i criteri nel cluster. Le richieste di ammissione di Kubernetes con violazioni vengono respinte.

   • Disabilitata: non applica i criteri nel cluster. Le richieste di ammissione Kubernetes con violazioni non vengono rifiutate. I risultati della valutazione della conformità sono ancora disponibili. Quando si implementano nuove definizioni di criteri nei cluster in esecuzione, l'opzione Disabilitato è utile per testare la definizione dei criteri, dato che le richieste di ammissione con violazioni non vengono rifiutate.

8. Selezionare Avanti.

9. Impostare i valori di parametro

   • Per escludere i namespace Kubernetes dalla valutazione delle policy, specificare l'elenco di namespace nel parametro Namespace exclusions. È consigliabile escludere: kube-system, gatekeeper-system e azure-arc.

10. Selezionare Rivedi e crea.

In alternativa, usare la guida di avvio rapido Creare un'assegnazione di criteri per identificare le risorse non conformi per trovare e assegnare un criterio Kubernetes. Cerca una definizione di politica Kubernetes invece dell'esempio audit vms.

Valutazione dei criteri

Il componente aggiuntivo si collega al servizio Criteri di Azure per verificare le modifiche delle assegnazioni di policy ogni 15 minuti. Durante questo ciclo di aggiornamento, il componente aggiuntivo controlla le modifiche. Queste modifiche attivano la creazione, l'aggiornamento o l'eliminazione dei modelli di vincolo e dei vincoli.

In un cluster Kubernetes, se uno spazio dei nomi ha l'etichetta appropriata per il cluster, le richieste di ammissione con violazioni non vengono negate. I risultati della valutazione della conformità sono ancora disponibili.

• cluster Kubernetes abilitato per Azure Arc: admission.policy.azure.com/ignore

Ogni 15 minuti il componente aggiuntivo richiede un'analisi completa del cluster. Dopo aver raccolto i dettagli dell'analisi completa ed eventuali valutazioni in tempo reale delle modifiche tentate da parte di Gatekeeper nel cluster, il componente aggiuntivo segnala i risultati ad Criteri di Azure per l'inclusione nei dettagli di compliance come qualsiasi assegnazione di Criteri di Azure. Durante il ciclo di controllo vengono restituiti solo i risultati delle assegnazioni di criteri attive. I risultati del controllo possono anche essere considerati come violazioni elencate nel campo di stato del vincolo non riuscito. Per informazioni dettagliate si risorse non conformi, vedere Dettagli componente per le modalità provider di risorse.

Altre considerazioni:

• Se la sottoscrizione del cluster è registrata con Microsoft Defender per il cloud, i criteri Kubernetes di Microsoft Defender per il cloud vengono applicati automaticamente al cluster.

• Quando un criterio di negazione viene applicato al cluster con risorse Kubernetes esistenti, qualsiasi risorsa preesistente non conforme ai nuovi criteri continua a essere eseguita. Quando la risorsa non conforme viene riprogrammata in un nodo diverso, Gatekeeper blocca la creazione della risorsa.

• Quando un cluster ha un criterio di rifiuto che convalida le risorse, l'utente non riceve un messaggio di rifiuto durante la creazione di una distribuzione. Si consideri, ad esempio, una distribuzione Kubernetes che contiene replicasets e pod. Quando un utente esegue kubectl describe deployment $MY_DEPLOYMENT, non restituisce un messaggio di rifiuto come parte degli eventi. Tuttavia, kubectl describe replicasets.apps $MY_DEPLOYMENT restituisce gli eventi associati al rifiuto.

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

Conflitti di modelli di vincolo

Se i modelli di vincolo hanno lo stesso nome dei metadati della risorsa, ma la definizione dei criteri fa riferimento all'origine in posizioni diverse, le definizioni dei criteri vengono considerate in conflitto. Esempio: due definizioni di criteri fanno riferimento allo stesso file template.yaml archiviato in percorsi di origine diversi, ad esempio l'archivio modelli di Criteri di Azure (store.policy.core.windows.net) e GitHub.

Quando le definizioni dei criteri e i relativi modelli di vincolo vengono assegnati ma non sono già installati nel cluster e sono in conflitto, vengono segnalati come conflitti e non vengono installati nel cluster finché il conflitto non viene risolto. Analogamente, tutte le definizioni di criteri esistenti e i relativi modelli di vincolo già presenti nel cluster in conflitto con definizioni di criteri appena assegnate continuano a funzionare normalmente. Se un'assegnazione esistente viene aggiornata e si verifica un errore durante la sincronizzazione del modello di vincolo, il cluster viene anch’esso contrassegnato come conflitto. Per tutti i messaggi di conflitto, vedere Motivi di conformità per la modalità provider di risorse del servizio Azure Kubernetes

Registrazione

In quanto controller/contenitori Kubernetes, i pod azure-policy e gatekeeper conservano i log nel cluster Kubernetes. In generale, i log azure-policy possono essere usati per risolvere i problemi relativi all'inserimento di criteri nel cluster e nella creazione di report di conformità. I log di pod gatekeeper-controller-manager possono essere usati per risolvere i problemi di rifiuto del runtime. I log di pod gatekeeper-audit possono essere usati per risolvere i problemi relativi ai controlli delle risorse esistenti. I log possono essere esposti nella pagina Informazioni dettagliate del cluster Kubernetes. Per altre informazioni, vedere Monitorare le prestazioni del cluster Kubernetes con Monitoraggio di Azure per contenitori.

Per visualizzare i log del componente aggiuntivo, usare kubectl:

# 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

Se si sta provando a risolvere problemi relativi a un determinato ComplianceReasonCode visualizzato nei risultati di conformità, è possibile cercare tale codice nei log dei pod di azure-policy per visualizzare l'errore completo ad esso associato.

Per altre informazioni, vedere la sezione Debug nella documentazione di Gatekeeper.

Visualizzare artefatti Gatekeeper

Dopo che il componente aggiuntivo scarica le assegnazioni dei criteri e installa i modelli di vincolo e i vincoli nel cluster, annota entrambi con informazioni su Criteri di Azure, come l'ID assegnazione dei criteri e l'ID definizione dei criteri. Per configurare il client in modo da visualizzare gli artefatti correlati al componente aggiuntivo, seguire questa procedura:

1. Configurare kubeconfig per il cluster.

   Per un cluster servizio Azure Kubernetes, usare il interfaccia della riga di comando di Azure seguente:

   # 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. Testare la connessione del cluster.

   Eseguire il comando kubectl cluster-info. In un’esecuzione riuscita, ogni servizio risponde con un URL in cui è in esecuzione.

Visualizzare i modelli di vincolo del componente aggiuntivo

Per visualizzare i modelli di vincolo scaricati dal componente aggiuntivo, eseguire kubectl get constrainttemplates. I modelli di vincolo che iniziano con k8sazure sono quelli installati dal componente aggiuntivo.

Visualizzare i modelli di mutazione dei componenti aggiuntivi

Per visualizzare i modelli di mutazione scaricati dal componente aggiuntivo, eseguire kubectl get assign, kubectl get assignmetadata e kubectl get modifyset.

Ottenere le mappature delle Policy di Azure

Per identificare il mapping tra un modello di vincolo scaricato nel cluster e la definizione dei criteri, usare kubectl get constrainttemplates <TEMPLATE> -o yaml. I risultati sono simili all'output seguente:

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> è l'ID sottoscrizione e <GUID> è l'ID della definizione dei criteri mappata. <URL-OF-YAML> è il percorso di origine del modello di vincolo scaricato dal componente aggiuntivo da installare nel cluster.

Visualizzare i vincoli correlati a un modello di vincolo

Dopo aver ottenuto i nomi dei modelli di vincolo scaricati dal componente aggiuntivo, è possibile usare il nome per visualizzare i vincoli correlati. Usare kubectl get <constraintTemplateName> per ottenere l'elenco. I vincoli installati dal componente aggiuntivo iniziano con azurepolicy-.

Visualizzare i dettagli del vincolo

Il vincolo include informazioni dettagliate sulle violazioni e mapping alla definizione e all'assegnazione dei criteri. Per visualizzare i dettagli, usare kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. I risultati sono simili all'output seguente:

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

Risoluzione dei problemi del componente aggiuntivo

Per altre informazioni sulla risoluzione dei problemi relativi al componente aggiuntivo per Kubernetes, vedere la sezione Kubernetes dell'articolo sulla risoluzione dei problemi di Criteri di Azure.

Per problemi relativi all'estensione Criteri di Azure per l'estensione Arc, vai a:

• Azure Arc abilitato per la risoluzione dei problemi di Kubernetes

Per i problemi correlati ad Criteri di Azure, consultare:

• Inspect Criteri di Azure logs
• Generale risoluzione dei problemi per Criteri di Azure in Kubernetes

Criteri di Azure componente aggiuntivo per AKS Changelog

Il componente aggiuntivo di Criteri di Azure per AKS ha un numero di versione che indica la versione dell'immagine del componente aggiuntivo. Quando il supporto di nuove funzionalità viene introdotto nel componente aggiuntivo, il numero di versione viene aumentato.

Questa sezione consente di identificare la versione dell'Add-on installata nel cluster e di fornire anche una tabella storica delle versioni dell'Add-on Criteri di Azure installate per ciascun cluster AKS.

Identificare la versione del componente aggiuntivo installata nel cluster

Il componente aggiuntivo Criteri di Azure usa lo schema standard Semantic Versioning per ogni versione. Per identificare la versione del componente aggiuntivo Criteri di Azure usata, è possibile eseguire il comando seguente: kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Per identificare la versione gatekeeper usata dal componente aggiuntivo Criteri di Azure, è possibile eseguire il comando seguente: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

Infine, per identificare la versione del cluster del servizio Azure Kubernetes in uso, seguire le indicazioni del servizio Azure Kubernetes correlate.

Versioni del componente aggiuntivo disponibili per ogni versione del cluster del servizio Azure Kubernetes

1.16.1

Introduzione alla generazione dei Criteri di ammissione di convalida (VAP). I Criteri di ammissione di convalida sono risorse dei criteri di ammissione di convalida native di Kubernetes valutate nel processo, consentendo una riduzione della latenza e una valutazione errore-chiusura. Azure Policy che contengono Common Expression Language (CEL) genereranno automaticamente VAP. Per altre informazioni, vedere la documentazione di Gatekeeper. Patch CVE-2026-25679, CVE-2026-27142, CVE-2026-27139 e CVE-2026-32280. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: maggio 2026
• Kubernetes: 1.36+
• Gatekeeper: 3.22.1

Gatekeeper 3.22.1

Versione Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.22.1 Modifiche: https://github.com/open-policy-agent/gatekeeper/compare/v3.20.1...v3.22.1

1.15.5

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: febbraio 2026
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.4

Patch CVE-2025-61727. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: dicembre 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.3

Patch CVE-2025-47914, CVE-2025-58181, CVE-2025-58187 e CVE-2025-22872. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: dicembre 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.15.1

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: novembre 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

1.14.2

Patch CVE-2025-4802. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: ottobre 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.1

Gatekeeper 3.20.1

Versione Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.1 Modifiche: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.1

1.13.1

Patch CVE-2025-47907. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: agosto 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.0

1.13.0

Confine Dati UE ora supportato da Criteri di Azure per Kubernetes su AKS. Per saperne di più in generale sul Confine dei Dati dell'UE, visita: Panoramica del Confine dei Dati dell'UE. Patch CVE-2025-22874. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: luglio 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.20.0

Gatekeeper 3.20.0

Versione Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 Modifiche: https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0

1.12.3

Patch CVE-2025-22874 e GHSA-vrw8-fxc6-2r93. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: luglio 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

1.12.2

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: giugno 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

1.11.1

Patch CVE-2025-22872. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: maggio 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.19.1

Gatekeeper 3.19.1

Versione Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 Modifiche: https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1

1.10.1

Patch CVE-2025-30204 e CVE-2025-22870. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: aprile 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.18.2

1.10.0

CEL è abilitato per impostazione predefinita, è possibile continuare a usare Rego. È stato introdotto un nuovo CRD configpodstatuses.status.gatekeeper.sh (riferimento: https://github.com/open-policy-agent/gatekeeper/issues/2918). Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: febbraio 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.18.2

Gatekeeper 3.18.2

Versione Gatekeeper: https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 Modifiche: https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2

1.9.1

Patch CVE-2024-45337 e CVE-2024-45338. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: gennaio 2025
• Kubernetes: 1.27+
• Gatekeeper: 3.17.1

Gatekeeper 3.17.1

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

1.8.0

I criteri possono ora essere usati per valutare le operazioni CONNECT, ad esempio, per negare exec. Si noti che non è disponibile alcuna conformità brownfield per le operazioni CONNECT non conformi, quindi un criterio con effetto Audit che ha come destinazione CONNECT non è efficace. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: novembre 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.17.1

1.7.1

Introduzione a CEL e VAP. Common Expression Language (CEL) è un linguaggio di espressioni nativo kubernetes che può essere usato per dichiarare le regole di convalida di un criterio. La funzionalità di convalida dei criteri di ammissione (VAP) offre una valutazione dei criteri in albero, riduce la latenza delle richieste di ammissione e migliora l'affidabilità e la disponibilità. Le azioni di convalida supportate includono Deny, Warn e Audit. La creazione di criteri personalizzati per CEL/VAP è consentita e gli utenti esistenti non dovranno convertire rego in CEL perché saranno entrambi supportati e usati per applicare i criteri. Per usare CEL e VAP, gli utenti devono abilitare il flag delle funzionalità AKS-AzurePolicyK8sNativeValidation nello spazio dei nomi Microsoft.ContainerService. Per altre informazioni, vedere la documentazione di Gatekeeper. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: settembre 2024
• Kubernetes: 1.27+ (la generazione di VAP è supportata solo nella versione 1.30+)
• Gatekeeper: 3.17.1

1.7.0

Introduzione all'espansione, una funzionalità di spostamento a sinistra che consente di sapere in anticipo se le risorse del carico di lavoro (distribuzioni, set di repliche, processi e così via) produrranno pod consentiti. L'espansione non deve modificare il comportamento dei criteri; sposta invece la valutazione di Gatekeeper dei criteri con ambito pod in modo che si verifichino in fase di ammissione del carico di lavoro anziché in tempo di ammissione dei pod. Tuttavia, per eseguire questa valutazione, è necessario generare e valutare un pod di simulazione basato sulla specifica di pod definita nel carico di lavoro, i cui metadati potrebbero essere incompleti. Ad esempio, il pod di simulazione non conterrà i riferimenti al proprietario appropriati. A causa di questo piccolo rischio di modifica del comportamento dei criteri, si sta introducendo l'espansione come disabilitata per impostazione predefinita. Per abilitare l'espansione di una determinata definizione di criteri, impostare .policyRule.then.details.source su All. Le funzionalità predefinite verranno aggiornate presto per abilitare la parametrizzazione di questo campo. Se testate la definizione della policy e scoprite che il pod di simulazione generato per scopi di valutazione è incompleto, potete anche utilizzare una mutazione con origine Generated per modificare i pod di simulazione. Per altre informazioni su questa opzione, vedere la documentazione di Gatekeeper. L'espansione è attualmente disponibile solo nei cluster AKS, non nei cluster Arc. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: luglio 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.16.3

1.6.1

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: maggio 2024
• Gatekeeper: 3.14.2

1.5.0

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: maggio 2024
• Kubernetes: 1.27+
• Gatekeeper: 3.16.3

1.4.0

Abilita la mutazione e i dati esterni per impostazione predefinita. Nel peggiore dei casi, il webhook di modifica aggiuntivo e l'aumento della del limite massimo di timeout della convalida del webhook potrebbero aggiungere latenza alle chiamate. Introduce anche il supporto per visualizzare la definizione dei criteri e impostare la versione della definizione nei risultati di conformità. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: maggio 2024
• Kubernetes: 1.25+
• Gatekeeper: 3.14.0

1.3.0

Introduce lo stato di errore per criteri in errore, consentendo di distinguerli da criteri in stati non conformi. Aggiunge il supporto per i modelli di vincolo v1 e l'uso del excludedNamespaces parametro nei criteri di mutazione. Aggiunge un controllo dello stato degli errori nei modelli di vincolo dopo l'installazione. Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: febbraio 2024
• Kubernetes: 1.25+
• Gatekeeper: 3.14.0

1.2.1

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: ottobre 2023
• Kubernetes: 1.25+
• Gatekeeper: 3.13.3

1.1.0

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: luglio 2023
• Kubernetes: 1.27+
• Gatekeeper: 3.11.1

1.0.1

Sono stati introdotti miglioramenti per la sicurezza.

• Data di rilascio: giugno 2023
• Kubernetes: 1.24+
• Gatekeeper: 3.11.1

1.0.0

Criteri di Azure per Kubernetes supporta ora le mutazioni per rimediare ai cluster AKS a livello di vasta scala.

Rimuovere il componente aggiuntivo

Rimuovere il componente aggiuntivo da AKS

Per rimuovere l'add-on Criteri di Azure dal cluster AKS, usare il portale di Azure o interfaccia della riga di comando di Azure.

• portale di Azure

  1. Avviare il servizio Azure Kubernetes nel portale di Azure selezionando Tutti i servizi e poi cercare e selezionare Servizi Kubernetes.

  2. Seleziona il tuo cluster AKS dove vuoi disabilitare il componente aggiuntivo Criteri di Azure.

  3. Selezionare Criteri sul lato sinistro della pagina del servizio Kubernetes.

  4. Nella pagina principale selezionare il pulsante Disabilita componente aggiuntivo.

• interfaccia della riga di comando di Azure

  # 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
  

Rimuovere il componente aggiuntivo da Kubernetes con Azure Arc abilitato.

Per rimuovere il componente aggiuntivo Criteri di Azure e Gatekeeper dal cluster Kubernetes abilitato Azure Arc, eseguire il comando Helm seguente:

helm uninstall azure-policy-addon

Rimuovere il componente aggiuntivo dal motore del servizio Azure Kubernetes

Per rimuovere il componente aggiuntivo Criteri di Azure e Gatekeeper dal cluster dell'AKS Engine, utilizza il metodo corrispondente alla modalità in cui è stato installato il componente aggiuntivo:

• Se l'installazione è stata eseguita impostando la proprietà addons nella definizione del cluster per AKS Engine:

  Ridistribuire la definizione del cluster su AKS Engine dopo aver modificato la proprietà addons di azure-policy su false.

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

  Per altre informazioni, vedere AKS Engine - Disable Criteri di Azure Add-On.

• Se l'installazione è stata eseguita con i grafici Helm, eseguire il comando Helm seguente:

  helm uninstall azure-policy-addon
  

Limiti

• Per consultare le definizioni generali di Criteri di Azure e i limiti delle assegnazioni, visitare i limiti documentati di Criteri di Azure
• Criteri di Azure, componente aggiuntivo per Kubernetes, può essere distribuito solo nei pool di nodi Linux.
• Numero massimo di pod supportati dal componente aggiuntivo Criteri di Azure per cluster: 10.000
• Numero massimo di record non conformi per ogni criterio per cluster: 500
• Numero massimo di record non conformi per sottoscrizione: 1 milione
• Le ragioni per la mancata conformità non sono disponibili per il Microsoft.Kubernetes.Data modalità Resource Provider. Usare Dettagli sui componenti.
• Le esenzioni a livello di componente non sono supportate per le modalità provider di risorse. Il supporto per i parametri è disponibile nelle definizioni di Criteri di Azure per escludere e includere namespace specifici.
• L'uso dell'annotazione metadata.gatekeeper.sh/requires-sync-data in un modello di vincolo per configurare la replica dei dati dal cluster alla cache OPA è attualmente consentito solo per i criteri integrati. La ragione è che ciò, se non usato con attenzione, può aumentare notevolmente l'utilizzo delle risorse dei pod Gatekeeper.

Configurazione di Gatekeeper

La modifica della configurazione di Gatekeeper non è supportata, perché contiene impostazioni di sicurezza critiche. Le modifiche apportate alla configurazione vengono riconciliate.

Utilizzo di data.inventory nei modelli di vincolo

Attualmente, diversi criteri predefiniti usano la replica dei dati, che consente agli utenti di sincronizzare le risorse esistenti nel cluster nella cache OPA e farvi riferimento durante la valutazione di una AdmissionReview richiesta. I criteri di replica dei dati possono essere differenziati in base alla presenza di data.inventory nel Rego e alla presenza dell'annotazione metadata.gatekeeper.sh/requires-sync-data, che informa il componente aggiuntivo Criteri di Azure quali risorse devono essere memorizzate nella cache per il corretto funzionamento della valutazione dei criteri. Questo processo è diverso da Gatekeeper autonomo, in cui questa annotazione è descrittiva, non prescrittiva.

La replica dei dati è al momento bloccata per l'uso nelle definizioni di criteri personalizzate, perché la replica di risorse con conteggi di istanze elevate può aumentare notevolmente l'utilizzo delle risorse dei pod Gatekeeper se non viene usato con attenzione. Quando si tenta di creare una definizione di criteri personalizzata contenente un modello di vincolo con questa annotazione, verrà visualizzato un ConstraintTemplateInstallFailed errore.

La rimozione dell'annotazione può attenuare l'errore visualizzato, ma il componente aggiuntivo dei criteri non sincronizza le risorse necessarie per tale modello di vincolo nella cache. Pertanto, i criteri verranno valutati rispetto a data.inventory vuoto (presupponendo che non venga assegnato alcun valore predefinito che replica le risorse necessarie). Ciò causerà risultati di conformità fuorvianti. Come indicato precedentemente, anche la modifica manuale della configurazione per memorizzare nella cache le risorse necessarie non è consentita.

Le limitazioni seguenti si applicano solo al componente aggiuntivo Criteri di Azure per AKS:

• AKS criteri di sicurezza dei pod e il componente aggiuntivo Criteri di Azure per AKS non possono essere entrambi abilitati. Per ulteriori informazioni, vedere Limitazioni della sicurezza dei pod in AKS.
• Spazi dei nomi esclusi automaticamente dall'add-on di Criteri di Azure per la valutazione: kube-system e gatekeeper-system.

Domande frequenti

Cosa distribuisce nel mio cluster l'estensione Criteri di Azure al momento dell'installazione?

Il componente aggiuntivo Criteri di Azure richiede l'esecuzione di tre componenti Gatekeeper: un pod di audit e due repliche di pod webhook. Anche un pod di Criteri di Azure e un pod webhook di Criteri di Azure vengono installati.

Qual è il consumo di risorse previsto per l'uso del componente aggiuntivo o dell'estensione Criteri di Azure in ogni cluster?

La Policy di Azure per i componenti di Kubernetes che vengono eseguiti sul cluster consuma più risorse man mano che aumenta il numero di risorse Kubernetes e le assegnazioni di criteri nel cluster, il che richiede operazioni di audit e attuazione.

Di seguito sono riportate stime utili per la pianificazione:

• Per meno di 500 pod in un singolo cluster con un massimo di 20 vincoli: due vCPU e 350 MB di memoria per componente.
• Per più di 500 pod in un singolo cluster con un massimo di 40 vincoli: tre vCPU e 600 MB di memoria per componente.

È possibile applicare Criteri di Azure per le definizioni di Kubernetes nei pod Windows?

I pod di Windows non supportano i contesti di sicurezza. Di conseguenza, alcune delle definizioni di Criteri di Azure, come il divieto dei privilegi di root, non possono essere innalzate nei pod Windows e si applicano solo ai pod Linux.

Quale tipo di dati di diagnostica vengono raccolti dal componente aggiuntivo di Criteri di Azure?

Il componente aggiuntivo Criteri di Azure per Kubernetes raccoglie dati di diagnostica del cluster limitati. Questi dati diagnostici sono dati tecnici di importanza vitale correlati al software e alle prestazioni. I dati vengono usati per:

• Mantenere il componente aggiuntivo di Criteri di Azure aggiornato.
• Mantenere il componente aggiuntivo di Criteri di Azure sicuro, affidabile ed efficiente.
• Migliorare il componente aggiuntivo di Criteri di Azure attraverso l'analisi aggregata dell'uso del componente aggiuntivo.

Le informazioni raccolte dal componente aggiuntivo non sono dati personali. Attualmente vengono raccolti i dettagli seguenti:

• Versione dell'agente aggiuntivo di Criteri di Azure
• Tipo di cluster
• Area del cluster
• Gruppo di risorse cluster
• ID della risorsa cluster
• ID sottoscrizione del cluster
• Sistema operativo del cluster (esempio: Linux)
• Città del cluster (esempio: Seattle)
• Stato o provincia del cluster (esempio: Washington)
• Paese o area geografica del cluster (esempio: Stati Uniti)
• Eccezioni/errori rilevati dal componente aggiuntivo di Criteri di Azure durante la valutazione dei criteri e l'installazione dell'agente.
• Numero di definizioni di criteri Gatekeeper non installate dal componente aggiuntivo di Criteri di Azure

Quali sono le procedure consigliate generali da tenere presenti durante l'installazione del componente aggiuntivo Criteri di Azure?

• Usare il pool di nodi di sistema con taint CriticalAddonsOnly per pianificare i pod Gatekeeper. Per altre informazioni, vedere Uso dei pool di nodi di sistema.
• Proteggi il traffico in uscita dai tuoi cluster AKS. Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster.
• Se il cluster ha aad-pod-identity abilitato, i pod di Gestione delle Identità del Nodo (NMI) modificano i nodi iptables per intercettare le chiamate all'endpoint dei metadati delle istanze di Azure. Questa configurazione significa che qualsiasi richiesta inviata all'endpoint dei metadati viene intercettata da NMI, anche se il pod non utilizza aad-pod-identity.
• AzurePodIdentityException È possibile configurare CRD per informare aad-pod-identity che le richieste all'endpoint dei metadati provenienti da un pod che corrispondono alle etichette definite in CRD devono essere inoltrate tramite proxy senza alcuna elaborazione in NMI. I pod di sistema con etichetta di kubernetes.azure.com/managedby: aks in spazio dei nomi kube-system devono essere esclusi in aad-pod-identity configurando il CRD AzurePodIdentityException. Per altre informazioni, vedere Disabilitare aad-pod-identity per un pod o un'applicazione specifica. Per configurare un'eccezione, installare mic-exception YAML.

Passaggi successivi

• Esaminare gli esempi su Criteri di Azure samples.
• Esaminare la struttura delle definizioni delle politiche.
• Leggere Informazioni sugli effetti di Criteri.
• Vedere come creare criteri a livello di codice.
• Leggere le informazioni su come ottenere dati sulla conformità.
• Informazioni su come correggere le risorse non conformi.
• Esaminare le caratteristiche di un gruppo di gestione con Organizzare le risorse con i gruppi di gestione Azure.