Proteggere i cluster del servizio Azure Kubernetes con Criteri di Azure

  • Articolo

È possibile applicare e far rispettare i criteri di sicurezza predefiniti nei cluster del servizio Azure Kubernetes usando Criteri di Azure. Criteri di Azure consente di applicare gli standard dell'organizzazione e valutare la conformità su larga scala. Dopo aver installato il componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes, è possibile applicare al cluster singole definizioni di criteri o gruppi di definizioni di criteri denominati iniziative (talvolta denominati criteri). Per un elenco completo delle definizioni di criteri e delle iniziative del servizio Azure Kubernetes, vedere Definizioni predefinite di Criteri di Azure Kubernetes.

Questo articolo illustra come applicare le definizioni dei criteri al cluster e verificare che tali assegnazioni vengano applicate.

Prerequisiti

Assegnare una definizione o un'iniziativa di criteri predefiniti

È possibile applicare una definizione o un'iniziativa di criteri nel portale di Azure seguendo questa procedura:

  1. Passare al servizio Criteri di Azure nel portale di Azure denominato Criteri.
  2. Nel riquadro a sinistra della pagina Criteri di Azure selezionare Definizioni.
  3. In Categorie, selezionare Kubernetes.
  4. Scegliere la definizione o l'iniziativa di criteri da applicare. Per questo esempio, selezionare l'iniziativa standard di base per la sicurezza dei pod del cluster Kubernetes per i carichi di lavoro basati su Linux.
  5. Seleziona Assegna.
  6. Impostare l’Ambito sul gruppo di risorse del cluster del servizio Azure Kubernetes con il componente aggiuntivo Criteri di Azure abilitato.
  7. Selezionare la pagina Parametri e aggiornare l’effetto da audit a deny per bloccare le nuove distribuzioni violando l'iniziativa di base. È anche possibile aggiungere spazi dei nomi aggiuntivi da escludere dalla valutazione. Per questo esempio, mantenere i valori predefiniti.
  8. Selezionare Rivedi e crea> Crea per inviare l'assegnazione dei criteri.

Creare e assegnare una definizione di criteri personalizzata

I criteri personalizzati consentono di definire regole per l'uso di Azure. Ad esempio, è possibile applicare i tipi di regole seguenti:

  • Procedure di sicurezza
  • Gestione dei costi
  • Regole specifiche dell'organizzazione (come denominazioni o posizioni)

Prima di creare un criterio personalizzato, controllare l'elenco di modelli ed esempi comuni per verificare se il caso è già trattato.

Le definizioni di criteri personalizzate vengono scritte in JSON. Per altre informazioni sulla creazione di un criterio personalizzato, vedere Struttura delle definizioni di Criteri di Azure e Creare una definizione di criteri personalizzata.

Nota

Criteri di Azure usa ora una nuova proprietà nota come templateInfo che consente di definire il tipo di origine per il modello di vincolo. Quando si definisce templateInfo nelle definizioni dei criteri, non è necessario definire le proprietà constraintTemplate o constraint. È comunque necessario definire apiGroup e tipi. Per altre informazioni su questo argomento, vedere Informazioni sugli effetti di Criteri di Azure.

Dopo aver creato la definizione dei criteri personalizzata, vedere Assegnare una definizione di criteri per una procedura dettagliata sull'assegnazione dei criteri al cluster Kubernetes.

Verificare che criteri di Azure sia in esecuzione

  • Verificare che le assegnazioni dei criteri vengano applicate al cluster usando il comando kubectl get seguente.

    kubectl get constrainttemplates

    Nota

    Le assegnazioni di criteri possono richiedere fino a 20 minuti per la sincronizzazione in ogni cluster.

    L'output dovrebbe essere simile all'output di esempio seguente:

    NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Convalidare il rifiuto di un pod con privilegi

Si esaminerà prima di tutto cosa accade quando si pianifica un pod con il contesto di sicurezza di privileged: true. Questo contesto di sicurezza esegue l'escalation dei privilegi del pod. L'iniziativa non consente pod con privilegi, quindi la richiesta viene negata, il che comporta il rifiuto della distribuzione.

  1. Creare un file denominato nginx-privileged.yaml e incollarlo nel manifesto YAML seguente.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        privileged: true

  2. Creare il pod usando il comando kubectl apply e specificare il nome del manifesto YAML.

    kubectl apply -f nginx-privileged.yaml

    Come previsto, non è possibile pianificare il pod, come illustrato nell'output di esempio seguente:

    Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}

    Il pod non raggiunge la fase di pianificazione, quindi non ci sono risorse da eliminare prima di procedere.

Testare la creazione di un pod senza privilegi

Nell'esempio precedente l'immagine del contenitore ha tentato di usare automaticamente la radice per associare NGINX alla porta 80. L'iniziativa dei criteri nega questa richiesta, quindi l'avvio del pod non riesce. A questo punto, provare a eseguire lo stesso pod NGINX senza accesso con privilegi.

  1. Creare un file denominato nginx-unprivileged.yaml e incollarlo nel manifesto YAML seguente.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

  2. Creare il pod usando il comando kubectl apply e specificare il nome del manifesto YAML.

    kubectl apply -f nginx-unprivileged.yaml

  3. Controllare lo stato del pod usando il comando kubectl get pods.

    kubectl get pods

    L'output dovrebbe essere simile all'output di esempio seguente, che mostra che il pod è stato pianificato correttamente e ha lo stato In esecuzione:

    NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s

    Questo esempio mostra l'iniziativa di base che interessa solo le distribuzioni che violano i criteri nella raccolta. Le distribuzioni consentite continuano a funzionare.

  4. Eliminare il pod non privilegiato NGINX usando il comando kubectl delete e specificare il nome del manifesto YAML.

    kubectl delete -f nginx-unprivileged.yaml

Disabilitare un criterio o un'iniziativa

È possibile rimuovere l'iniziativa di base nel portale di Azure seguendo questa procedura:

  1. Passare al riquadro Criteri nel portale di Azure.
  2. Selezionare Assegnazioni.
  3. Selezionare il pulsante ... accanto all'iniziativa standard di base di sicurezza dei pod del cluster Kubernetes per i carichi di lavoro basati su Linux.
  4. Selezionare Elimina assegnazione.

Passaggi successivi

Per altre informazioni sul funzionamento di Criteri di Azure, vedere gli articoli seguenti: