Informazioni su Criteri di Azure per i cluster Kubernetes

Criteri di Azure estende Gatekeeper v3, un webhook del controller di ammissione per Open Policy Agent (OPA), per applicare le imposizione e le misure di sicurezza su larga scala nei componenti del cluster in modo centralizzato e coerente. I componenti del cluster includono pod, contenitori e spazi dei nomi.

Con Criteri di Azure è possibile gestire i componenti del cluster Kubernetes e creare report sul loro stato di conformità da un'unica posizione. Usando il componente aggiuntivo o l'estensione di Criteri di Azure, la governance dei componenti del cluster è migliorata con le funzionalità di Criteri di Azure, ad esempio la possibilità di usare selettori e sostituzioni per l'implementazione e l'implementazione sicura dei criteri.

Il servizio Criteri di Azure per Kubernetes supporta gli ambienti cluster seguenti:

• servizio Azure Kubernetes (servizio Azure Kubernetes) tramite il componente aggiuntivo di Criteri di Azure per il servizio Azure Kubernetes
• Kubernetes con abilitazione di Azure Arc tramite l'estensione di Criteri di Azure per Arc

Importante

Il modello Helm Criteri di Azure componente aggiuntivo e il componente aggiuntivo per il motore del servizio Azure Kubernetes sono stati deprecati. Seguire le istruzioni per rimuovere i componenti aggiuntivi.

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 le assegnazioni dei criteri al cluster.
• Distribuisce le definizioni dei criteri nel cluster come modello di vincolo e vincoli risorse personalizzate o come risorsa modello di mutazione (a seconda del contenuto della definizione dei criteri).
• Restituisce i dettagli di controllo e conformità al servizio Criteri di Azure.

Per abilitare e usare Criteri di Azure con il cluster Kubernetes, eseguire le operazioni 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 (a seconda del tipo di cluster).

   Nota

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

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 Criteri di Azure per il servizio Azure Kubernetes

Prerequisiti

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

   • Portale di Azure:

     Registrare i Microsoft.PolicyInsights provider di risorse. 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. È necessario che sia installata e configurata l'interfaccia della riga di comando di Azure versione 2.12.0 o successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

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

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

4. Porte aperte 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	Porta
   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 del servizio Azure Kubernetes che si vuole gestire.

• Azure portal

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

  2. Selezionare uno dei cluster del servizio Azure Kubernetes.

  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 sia installato il componente aggiuntivo più recente eseguendo questo comando dell'interfaccia della riga di comando di Azure, sostituendo <rg> con il nome del gruppo di risorse e <cluster-name> con il nome del cluster del servizio Azure Kubernetes: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. Il risultato dovrebbe essere simile all'output seguente per i cluster che usano entità servizio:

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

E l'output seguente per i cluster che usano l'identità gestita:

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

Installare l'estensione Criteri di Azure per Kubernetes con abilitazione di 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 creare, visualizzare lo stato dell'estensione ed eliminare il Criteri di Azure per l'estensione Kubernetes.

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

Prerequisiti

Se è già stato distribuito Criteri di Azure per Kubernetes in un cluster Azure Arc usando Helm direttamente senza estensioni, seguire le istruzioni per eliminare il grafico 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 nelle distribuzioni Kubernetes seguenti.

2. Assicurarsi di aver soddisfatto tutti i prerequisiti comuni per le estensioni Kubernetes elencate di seguito , inclusa la connessione del cluster ad Azure Arc.

   Nota

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

3. Porte aperte 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	Porta
   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 di abilitare una delle funzionalità del servizio, la sottoscrizione deve abilitare i Microsoft.PolicyInsights provider di risorse.

   Nota

   Per abilitare il provider di risorse, seguire la procedura descritta in Provider di risorse e tipi oppure eseguire il comando dell'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

Nota

Per la creazione dell'estensione Criteri di Azure, tenere presente quanto segue:

• L'aggiornamento automatico è abilitato per impostazione predefinita, che aggiornerà Criteri di Azure versione secondaria dell'estensione se vengono distribuite nuove modifiche.
• Tutte le variabili proxy passate come parametri a connectedk8s verranno propagate all'estensione Criteri di Azure per supportare il proxy in uscita.

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 riuscita 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 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 di Criteri di Azure per la gestione di Kubernetes segue quella delle definizioni dei 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. L'estensione vs code di Criteri di Azure può essere usata per convertire un modello di vincolo o un modello di mutazione esistente in una definizione di criteri di Criteri di Azure personalizzata.

Con una modalità provider di risorse di Microsoft.Kubernetes.Data, il controllo degli effetti, negare, disabilitare e modificare vengono usati per gestire i cluster Kubernetes.

Il controllo e la negazione devono fornire proprietà dettagliate 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. Grazie al supporto di uno standard esistente per la gestione di Kubernetes, Criteri di Azure consente di riutilizzare le regole esistenti e di associarle a Criteri di Azure per un'esperienza di creazione di report di conformità cloud unificata. Per altre informazioni, vedere Informazioni su Rego.

Assegnare una definizione di criteri

Per assegnare una definizione di criteri al cluster Kubernetes, è necessario avere ricevuto le operazioni di assegnazione dei criteri appropriate per il Controllo degli accessi in base al ruolo di Azure. I ruoli predefiniti di Azure Collaboratore ai criteri di risorse e Proprietario includono queste operazioni. Per altre informazioni, vedere Autorizzazioni di Controllo degli accessi in base al ruolo di Azure in Criteri di Azure.

Trovare le definizioni dei criteri predefinite per la gestione del cluster eseguendo questa procedura nel portale di Azure. 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 a sinistra della pagina Criteri di Azure selezionare Definizioni.

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 Ambito sul gruppo di gestione, sulla sottoscrizione o sul gruppo di risorse del cluster Kubernetes in cui si applicherà l'assegnazione dei criteri.

   Nota

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

6. Compilare i campi Nome e Descrizione dell'assegnazione dei criteri per identificarla più facilmente.

7. Impostare l'imposizione dei criteri su uno dei valori seguenti:

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

   • 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 implementa nuove definizioni di criteri per l'esecuzione di cluster, l'opzione Disabilitata è utile per testare la definizione dei criteri perché le richieste di ammissione con violazioni non vengono negate.

8. Selezionare Avanti.

9. Impostare i valori di parametro

   • Per escludere gli spazi dei nomi Kubernetes dalla valutazione dei criteri, specificare l'elenco di spazi dei nomi nel parametro Esclusioni per gli spazi dei nomi. È 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. Cercare una definizione di criteri Kubernetes anziché le vm di controllo di esempio.

Importante

Le definizioni di criteri predefinite sono disponibili per i cluster Kubernetes nella categoria Kubernetes. Per un elenco di definizioni di criteri predefinite, vedere gli esempi di Kubernetes.

Valutazione dei criteri

Il componente aggiuntivo sincronizza le modifiche alle assegnazioni dei criteri con il servizio Criteri di Azure 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 vincoli e dei modelli di vincolo.

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

Nota

Anche se un amministratore del cluster può avere l'autorizzazione per creare e aggiornare i modelli di vincolo e le risorse vincolo installati dal componente aggiuntivo Criteri di Azure, questi scenari non sono supportati in quanto gli aggiornamenti manuali vengono sovrascritti. Gatekeeper continua a valutare i criteri che esistevano prima dell'installazione del componente aggiuntivo e dell'assegnazione delle definizioni dei criteri di Criteri di Azure.

Ogni 15 minuti il componente aggiuntivo richiede un'analisi completa del cluster. Dopo aver raccolto tramite Gatekeeper i dettagli dell'analisi completa e di eventuali valutazioni in tempo reale delle modifiche apportate al cluster, il componente aggiuntivo restituisce i risultati a Criteri di Azure in modo che vengano inclusi nei dettagli di conformità 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 sulle risorse non conformi , vedere Dettagli del componente per le modalità del provider di risorse.

Nota

Ogni report di conformità in Criteri di Azure per i cluster Kubernetes include tutte le violazioni verificatesi negli ultimi 45 minuti. Il timestamp indica il momento in cui si è verificata una violazione.

Altre considerazioni:

• Se la sottoscrizione del cluster viene registrata con Microsoft Defender per il cloud, Microsoft Defender per il cloud criteri Kubernetes 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 negazione 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 set di repliche e pod. Quando un utente esegue , non restituisce kubectl describe deployment $MY_DEPLOYMENTun messaggio di rifiuto come parte degli eventi. Restituisce kubectl describe replicasets.apps $MY_DEPLOYMENT tuttavia gli eventi associati al rifiuto.

Nota

I contenitori Init possono essere inclusi durante la valutazione dei criteri. Per verificare se sono inclusi contenitori init, esaminare il CRD per ottenere una dichiarazione simile o seguente:

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 template.yaml file archiviato in posizioni di origine diverse, 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 le 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 anche contrassegnato come conflitto. Per tutti i messaggi in conflitto, vedere Motivi di conformità per la modalità provider di risorse del servizio Azure Kubernetes

Registrazione

Come controller/contenitore Kubernetes, i pod azure-policy e gatekeeper mantengono i log nel cluster Kubernetes. In generale, i log di criteri di Azure possono essere usati per risolvere i problemi relativi all'inserimento di criteri nel cluster e nella creazione di report di conformità. I log dei pod gatekeeper-controller-manager possono essere usati per risolvere i problemi di negazione del runtime. I log dei 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 i 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 tentando di risolvere i problemi relativi a un determinato codice ComplianceReasonCode visualizzato nei risultati di conformità, è possibile cercare nel codice il codice corrispondente nei log dei pod di azure-policy.

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

Visualizzare gli 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 Criteri di Azure informazioni come l'ID assegnazione dei criteri e l'ID definizione dei criteri. Per configurare il client per visualizzare gli artefatti correlati al componente aggiuntivo, seguire questa procedura:

1. Configurare kubeconfig per il cluster.

   Per un cluster servizio Azure Kubernetes, usare l'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 cluster.

   Eseguire il comando kubectl cluster-info. Un'esecuzione riuscita ha ogni servizio che 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 assignmetadatae kubectl get modifyset.

Ottenere mapping di Criteri 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 i 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 del componente aggiuntivo per Kubernetes, vedere la sezione Kubernetes dell'articolo sulla risoluzione dei problemi di Criteri di Azure.

Per Criteri di Azure problemi correlati all'estensione Arc, vedere:

• Risoluzione dei problemi di Kubernetes con abilitazione di Azure Arc

Per Criteri di Azure problemi correlati, vedere:

• Esaminare i log di Criteri di Azure
• Risoluzione dei problemi generali per Criteri di Azure in Kubernetes

Criteri di Azure componente aggiuntivo per il registro modifiche del servizio Azure Kubernetes

il componente aggiuntivo di Criteri di Azure per il servizio Azure Kubernetes ha un numero di versione che indica la versione dell'immagine del componente aggiuntivo. Poiché il supporto delle funzionalità è stato appena introdotto nel componente aggiuntivo, il numero di versione viene aumentato.

Questa sezione consente di identificare la versione del componente aggiuntivo installata nel cluster e di condividere anche una tabella cronologica della versione del componente aggiuntivo Criteri di Azure installata per ogni cluster del servizio Azure Kubernetes.

Identificare la versione del componente aggiuntivo installata nel cluster

Il componente aggiuntivo Criteri di Azure usa lo schema di controllo delle versioni semantiche standard per ogni versione. Per identificare la versione del componente aggiuntivo Criteri di Azure in uso, è 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 collegate.

Versioni dei componenti aggiuntivi disponibili per ogni versione del cluster del servizio Azure Kubernetes

1.3.0

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

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

1.2.1

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

1.1.0

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

1.0.1

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

1.0.0

Criteri di Azure per Kubernetes supporta ora la mutazione per correggere i cluster del servizio Azure Kubernetes su larga scala.

Rimuovere il componente aggiuntivo

Rimuovere il componente aggiuntivo dal servizio Azure Kubernetes

Per rimuovere il componente aggiuntivo Criteri di Azure dal cluster del servizio Azure Kubernetes, usare il portale di Azure o l'interfaccia della riga di comando di Azure:

• Azure portal

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

  2. Selezionare il cluster del servizio Azure Kubernetes in cui si vuole 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 abilitazione di Azure Arc

Nota

Criteri di Azure modello Helm del componente aggiuntivo è ora deprecato. Scegliere invece l'estensione Criteri di Azure per Kubernetes con abilitazione di Azure Arc.

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

helm uninstall azure-policy-addon

Rimuovere il componente aggiuntivo dal motore del servizio Azure Kubernetes

Nota

Il prodotto motore del servizio Azure Kubernetes è ora deprecato per i clienti del cloud pubblico di Azure. Prendere in considerazione l'uso di servizio Azure Kubernetes (AKS) per Kubernetes gestito o il provider di API cluster di Azure per Kubernetes autogestito. Non sono previste nuove funzionalità; questo progetto verrà aggiornato solo per cves e simili, con Kubernetes 1.24 come versione finale per ricevere gli aggiornamenti.

Per rimuovere il componente aggiuntivo Criteri di Azure e Gatekeeper dal cluster del motore del servizio Azure Kubernetes, usare il metodo appropriato alla modalità di installazione del componente aggiuntivo:

• Se l'installazione è stata eseguita impostando la proprietà addons nella definizione del cluster per il motore del servizio Azure Kubernetes:

  Ridistribuire la definizione del cluster nel motore del servizio Azure Kubernetes dopo aver impostato la proprietà addons di azure-policy su false:

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

  Per altre informazioni, vedere Motore del servizio Azure Kubernetes - Disabilitare il componente aggiuntivo Criteri di Azure.

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

  helm uninstall azure-policy-addon
  

Limiti

• Per le definizioni di Criteri di Azure generali e i limiti di assegnazione, esaminare 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 installazioni di Gatekeeper al di fuori del componente aggiuntivo Criteri di Azure non sono supportate. Disinstallare tutti i componenti installati da un'installazione precedente di Gatekeeper prima di abilitare il componente aggiuntivo Criteri di Azure.
• I motivi della mancata conformità non sono disponibili per la modalità Provider di risorse Microsoft.Kubernetes.Data. Usare i dettagli del componente.
• Le esenzioni a livello di componente non sono supportate per le modalità del provider di risorse. Il supporto dei parametri è disponibile nelle definizioni di Criteri di Azure da escludere e includere spazi dei nomi specifici.
• L'uso dell'annotazione metadata.gatekeeper.sh/requires-sync-data in un modello di vincolo per configurare la replica dei dati dal cluster nella cache OPA è attualmente consentito solo per i criteri predefiniti. Ciò è dovuto al fatto che può aumentare notevolmente l'utilizzo delle risorse dei pod gatekeeper se non viene usato attentamente.

Le limitazioni seguenti si applicano solo al componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes:

• I criteri di sicurezza dei pod del servizio Azure Kubernetes e il componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes non possono essere entrambi abilitati. Per altre informazioni, vedere Limitazione della sicurezza dei pod del servizio Azure Kubernetes.
• Spazi dei nomi esclusi automaticamente da Criteri di Azure componente aggiuntivo per la valutazione: kube-system e gatekeeper-system.

Domande frequenti

Cosa distribuisce l'estensione Criteri di Azure componente aggiuntivo/Criteri di Azure nel cluster al momento dell'installazione?

Il componente aggiuntivo Criteri di Azure richiede l'esecuzione di tre componenti gatekeeper: Un pod di controllo e due repliche pod webhook. Verrà installato anche un pod Criteri di Azure e un pod webhook Criteri di Azure.

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

Il Criteri di Azure per i componenti Kubernetes eseguiti nel cluster utilizza più risorse perché aumenta il numero di risorse e assegnazioni di criteri Kubernetes nel cluster, che richiede operazioni di controllo e imposizione. Di seguito sono riportate le stime che consentono di pianificare:

• 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 Windows non supportano i contesti di sicurezza. Di conseguenza, alcune delle definizioni di Criteri di Azure, ad esempio la disallowing dei privilegi radice, non possono essere inoltrate nei pod Windows e si applicano solo ai pod Linux.

Quale tipo di dati di diagnostica viene raccolto da Criteri di Azure componente aggiuntivo?

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. Vengono usati per:

• Mantenere aggiornato il componente aggiuntivo Criteri di Azure
• Garantire la sicurezza, l'affidabilità e l'efficienza del componente aggiuntivo Criteri di Azure
• Migliorare il componente aggiuntivo Criteri di Azure tramite l'analisi aggregata dell'utilizzo del componente aggiuntivo

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

• Versione dell'agente del componente aggiuntivo Criteri di Azure
• Tipo di cluster
• Area del cluster
• Gruppo di risorse cluster
• ID della risorsa cluster
• ID sottoscrizione del cluster
• Sistema operativo 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 Criteri di Azure durante l'installazione dell'agente nella valutazione dei criteri
• Numero di definizioni dei criteri Gatekeeper non installate dal componente aggiuntivo 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 CriticalAddonsOnly taint per pianificare i pod Gatekeeper. Per altre informazioni, vedere Uso dei pool di nodi di sistema.
• Proteggere il traffico in uscita dai cluster del servizio Azure Kubernetes. 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 identità gestita del nodo modificano le tabelle iptable dei nodi per intercettare le chiamate all'endpoint dei metadati dell'istanza di Azure. Questa configurazione indica che qualsiasi richiesta inviata all'endpoint metadati viene intercettata da NMI anche se il pod non usa aad-pod-identity.
• AzurePodIdentityException CRD può essere configurato per informare aad-pod-identity che qualsiasi richiesta all'endpoint metadati proveniente da un pod che corrisponde alle etichette definite in CRD deve essere trasmessa tramite proxy senza alcuna elaborazione in NMI. I pod di sistema con kubernetes.azure.com/managedby: l'etichetta del servizio Azure Kube-system nello spazio dei nomi kube-system deve essere esclusa 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

• Vedere gli esempi in Esempi di Criteri di Azure.
• Vedere Struttura delle definizioni di criteri di Azure.
• 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.
• Rivedere le caratteristiche di un gruppo di gestione illustrate in Organizzare le risorse con i gruppi di gestione di Azure.