Informazioni su Criteri di Azure per i cluster Kubernetes

Articolo
09/30/2024

Il servizio Criteri di Azure estende Gatekeeper v3, un webhook del controller di ammissione per Open Policy Agent (OPA), per applicare tutele e misure di sicurezza su larga scala ai 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 è ottimizzata con le funzionalità di Criteri di Azure, ad esempio la possibilità di usare selettori e sostituzioni per l'implementazione e il rollback sicuri di criteri.

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

Servizio Azure Kubernetes (AKS), tramite il componente aggiuntivo 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 del componente aggiuntivo Criteri di Azure 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 risorse personalizzate di vincolo 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:

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 Risolvere i problemi relativi al componente aggiuntivo Criteri di Azure.
Creare o usare una definizione di Criteri di Azure di esempio per Kubernetes
Assegnare una definizione al cluster Kubernetes
Attendere la convalida
Registrazione e risoluzione dei problemi
Esaminare le limitazioni e i consigli nella sezione domande frequenti

Installare il componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes

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

Prerequisiti

Registrare i provider di risorse e le funzionalità di anteprima.
- Portale di Azure:
  
  Registrare i provider 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
```
È necessario che sia installata e configurata l'interfaccia della riga di comando di Azure versione 2.12.0 o successiva. Per trovare la versione, eseguire il comando az --version. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Come installare l'interfaccia della riga di comando di Azure.
Il cluster del servizio Azure Kubernetes deve essere una versione di Kubernetes supportata nel servizio Azure Kubernetes (AKS). 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
```
Porte aperte per l'estensione Criteri di Azure. L'estensione Criteri di Azure usa questi domini e queste 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

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

Una volta completati i passaggi relativi ai prerequisiti, installare il componente aggiuntivo Criteri di Azure nel cluster del servizio Azure Kubernetes da gestire.

Azure portal
1. Avviare il 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>. Per cluster che usano entità servizio, il risultato dovrebbe essere simile all'output seguente:

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

E all'output seguente per 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

Con Criteri di Azure per Kubernetes è possibile gestire i cluster Kubernetes e creare report sul loro stato di conformità 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 l'estensione Criteri di Azure per Kubernetes.

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

Prerequisiti

Se Criteri di Azure per Kubernetes è già stato distribuito in un cluster Azure Arc usando direttamente Helm senza estensioni, seguire queste istruzioni per eliminare il grafico Helm. Al termine dell'eliminazione, è possibile procedere.

Assicurarsi che il cluster Kubernetes sia una distribuzione supportata.

Nota

L'estensione Criteri di Azure per Arc è supportata nelle distribuzioni Kubernetes seguenti.
Assicurarsi di aver soddisfatto tutti i prerequisiti comuni per le estensioni Kubernetes elencate qui, inclusa la connessione del cluster ad Azure Arc.

Nota

L'estensione Criteri di Azure è supportata per i cluster Kubernetes abilitati per Arc in queste aree.
Porte aperte per l'estensione Criteri di Azure. L'estensione Criteri di Azure usa questi domini e queste 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
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 la procedura descritta in Provider e tipi di risorse, oppure eseguire l'interfaccia della riga di comando di Azure o il comando 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'
```

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

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, aggiornerà la versione secondaria dell'estensione di Criteri di Azure se dovessero essere 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"
}

Visualizzare l'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 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 campione da assegnare nella libreria criteri integrata di Criteri di Azure, i quali possono essere usati per gestire i componenti del cluster.

Criteri di Azure per Kubernetes supporta anche la creazione di definizioni personalizzate a livello di componente per i cluster del servizio Azure Kubernetes e 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 Visual Studio Code di Criteri di Azure può essere usata per convertire un modello di vincolo o un modello di mutazione esistenti in una definizione di criteri di Azure personalizzata.

Con una modalità provider di risorse di Microsoft.Kubernetes.Data, gli effetti controllare, rifiutare, disattivato e mutare vengono usati 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 l'URI o il valore 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.

Avviare il servizio Criteri di Azure nel portale di Azure. Selezionare Tutti i servizi nel riquadro sinistro e quindi cercare e selezionare Criteri.
Nel riquadro a sinistra della pagina Criteri di Azure selezionare Definizioni.
Nella casella di riepilogo a discesa Categoria usare Seleziona tutto per cancellare il filtro e quindi selezionare Kubernetes.
Selezionare la definizione di criteri e quindi il pulsante Assegna.
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, l'ambito deve includere la risorsa cluster.
Compilare i campi Nome e Descrizione dell'assegnazione dei criteri per identificarla più facilmente.
Impostare Tutela dei criteri sui 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 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.
Selezionare Avanti.
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.
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 al posto del valore campione audit vms.

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 con abilitazione di Azure Arc: admission.policy.azure.com/ignore

Nota

Anche se un amministratore del cluster potrebbe avere l'autorizzazione per creare e aggiornare modelli di vincolo e 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 si risorse non conformi, vedere Dettagli componente per le modalità 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 è registrata con Microsoft Defender per il Cloud, i criteri di Microsoft Defender per il cloud 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 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 pod e . 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.

Nota

I contenitori init potrebbero essere inclusi durante la valutazione dei criteri. Per verificare se contenitori init siano inclusi, cercare una dichiarazione identica o simile alla seguente nel CRD:

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 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 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 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 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 di criteri e installa i modelli di vincolo e i vincoli nel cluster, annota entrambi con le informazioni di Criteri di Azure, ad esempio 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:

Configurare kubeconfig per il cluster.

Per un cluster del 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>

Testare la connessione 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 i 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 di cui è stato eseguito il mapping. <URL-OF-YAML> è il percorso di origine del modello di vincolo scaricato dal componente aggiuntivo da installare nel cluster.

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

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

Risoluzione dei problemi di Kubernetes con abilitazione di Azure Arc

Per problemi correlati a Criteri di Azure, passare a:

Componente aggiuntivo Criteri di Azure 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. Quando il supporto di nuove funzionalità viene 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 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 delle versioni semantiche standard 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 di Gatekeeper usata dal componente aggiuntivo Criteri di Azure, 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.