Condividi tramite

Informazioni su Criteri di Azure per i cluster Kubernetes

  • Articolo

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:

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:

  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 Risolvere i problemi relativi al componente aggiuntivo 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 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

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

  2. È 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.

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

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

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.

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

    Nota

    L'estensione Criteri di Azure per Arc è supportata nelle distribuzioni Kubernetes seguenti.

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

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

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

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.

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

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

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

  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 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:

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

  2. 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:

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.

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

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 registrarsi nel flag AKS-AzurePolicyK8sNativeValidation di funzionalità nello spazio dei Microsoft.ContainerService nomi . Per altre informazioni, vedere la documentazione di Gatekeeper.

Sono stati introdotti miglioramenti per la sicurezza.

  • Data di rilascio: set 2024
  • Kubernetes 1.27+ (la generazione di VAP è supportata solo su 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, che potrebbe avere metadati 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 si testa la definizione dei criteri e si scopre che il pod di simulazione generato per scopi di valutazione è incompleto, è anche possibile usare una mutazione con origine Generated per modificare i pod di simulazione. Per altre informazioni su questa opzione, vedere la documentazione di Gatekeeper.

Sono stati introdotti miglioramenti per la sicurezza.

  • Data di rilascio: 2024 luglio 2021
  • 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à.

  • 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 modelli di vincolo v1 e l'uso del parametro excludedNamespaces in 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 rimediare 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 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

Il modello Helm del componente aggiuntivo Criteri di Azure è correntemente deprecato. È invece consigliabile scegliere 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 è correntemente deprecato per clienti del cloud pubblico di Azure. Prendere in considerazione l'uso del servizio Azure Kubernetes per Kubernetes gestito o del provider di API del cluster Azure per Kubernetes autogestito. Non sono previste nuove funzionalità; questo progetto verrà aggiornato solo per CVE e simili, con Kubernetes 1.24 come versione finale che riceva 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 definizioni generali di Criteri di Azure e limiti di assegnazione, vedere Limiti documentati di Criteri di Azure
  • Il componente aggiuntivo Criteri di Azure 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 all'esterno 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 Dettagli sui componenti.
  • Le esenzioni a livello di componente non sono supportate per le modalità provider di risorse. Il supporto dei parametri è disponibile nelle definizioni di Criteri di Azure per 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 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.

Uso 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 nell'oggetto Rego e alla presenza dell'annotazionemetadata.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 il servizio Azure Kubernetes:

Domande frequenti

Che cosa distribuisce il componente aggiuntivo Criteri di Azure/l’estensione 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. Sono installati anche un pod di Criteri di Azure e un pod webhook di Criteri di Azure.

Quanto consumo di risorse è necessario far sì che il componente aggiuntivo/l’estensione di Criteri di Azure venga usato in ogni cluster?

I componenti di Criteri di Azure per Kubernetes eseguiti nel cluster utilizzano più risorse man mano che il numero di risorse e assegnazioni di criteri Kubernetes nel cluster aumenta, il che richiede operazioni di controllo e imposizione.

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 le definizioni di Criteri di Azure per Kubernetes in pod Windows?

I pod Windows non supportano contesti di sicurezza. Di conseguenza, alcune delle definizioni di Criteri di Azure, ad esempio la disabilitazione dei privilegi radice, non possono essere inoltrate in pod Windows e si applicano solo a pod Linux.

Quale tipo di dati di diagnostica viene raccolto dal componente aggiuntivo 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 aggiornato il componente aggiuntivo Criteri di Azure.
  • Mantenere il componente aggiuntivo Criteri di Azure sicuro, affidabile ed efficiente.
  • 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 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 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 taint CriticalAddonsOnly 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 è aad-pod-identity abilitato, i pod di identità gestita del nodo modificano i nodi iptables per intercettare le chiamate all'endpoint dei metadati dell'istanza di Azure. Questa configurazione significa che qualsiasi richiesta inviata all'endpoint dei metadati viene intercettata dall’identità gestita del nodo, anche se il pod non usa 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 kubernetes.azure.com/managedby: aks etichetta nello spazio dei nomi kube-system devono essere esclusi aad-pod-identity configurando il AzurePodIdentityException CRD. Per altre informazioni, vedere Disabilitare aad-pod-identity per un pod o un'applicazione specifica. Per configurare un'eccezione, installare il YAML mic-exception.

Passaggi successivi