Proteggere il cluster usando criteri di sicurezza pod nel Servizio Azure Kubernetes (AKS) (anteprima)

Importante

La funzionalità dei criteri di sicurezza dei pod è stata deprecata il 1° agosto 2023 e rimossa dalle versioni 1.25 del servizio Azure Kubernetes e versioni successive.

È consigliabile eseguire la migrazione a controller di ammissione di sicurezza dei pod o criteri di Azure per rimanere all'interno del supporto di Azure. Ammissione di sicurezza dei pod è una soluzione di criteri predefinita per le implementazioni di un singolo cluster. Per chi è alla ricerca di criteri di livello aziendale, Criteri di Azure è la scelta migliore.

Operazioni preliminari

• Questo articolo presuppone che si disponga di un cluster del servizio Azure Kubernetes esistente. Se è necessario un cluster del servizio Azure Kubernetes, crearne uno usando Interfaccia della riga di comando di Azure, Azure PowerShello il portale di Azure.
• È necessario che sia installata e configurata l'interfaccia della riga di comando di Azure 2.0.61 o versioni successive. 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.

Installare l'estensione aks-preview dell'interfaccia della riga di comando di Azure.

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

• Criteri di supporto del Servizio Azure Kubernetes (AKS)
• Domande frequenti relative al supporto tecnico di Azure

1. Installare l'estensione aks-preview usando il comando az extension add.

   az extension add --name aks-preview
   

2. Eseguire l'aggiornamento alla versione più recente dell'estensione usando il comando az extension update.

   az extension update --name aks-preview
   

Registrare il flag di funzionalità PodSecurityPolicyPreview

1. Registrare il flag di funzionalità PodSecurityPolicyPreview usando il comando az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
   

   Sono necessari alcuni minuti per visualizzare lo stato Registered.

2. Verificare lo stato della registrazione usando il comando az feature show.

   az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
   

3. Quando lo stato riflette Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register.

   az provider register --namespace Microsoft.ContainerService
   

Panoramica dei criteri di sicurezza dei pod

I cluster Kubernetes usano i controller di ammissione per intercettare le richieste al server API quando una risorsa sta per essere creata. Il controller di ammissione può quindi convalidare la richiesta di risorsa in base a un insieme di regole o modificare la risorsa per cambiare i parametri di distribuzione.

PodSecurityPolicy è un controller di ammissione che convalida la specifica di un pod che soddisfa i requisiti definiti. Questi requisiti possono limitare l'uso di contenitori privilegiati, l'accesso a determinati tipi di archiviazione o l'utente o il gruppo in cui il container può essere eseguito. Quando si tenta di distribuire una risorsa in cui le specifiche dei pod non soddisfano i requisiti descritti nei criteri di sicurezza dei pod, la richiesta viene negata. Questa possibilità di controllare quali pod possono essere pianificati nel cluster del servizio Azure Kubernetes previene alcune possibili vulnerabilità della sicurezza o escalation di privilegi.

Quando si abilitano i criteri di sicurezza dei pod in un cluster del servizio Azure Kubernetes, vengono applicati alcuni criteri predefiniti. Questi criteri offrono un'esperienza immediata per definire quali pod possono essere pianificati. Tuttavia, si potrebbero verificare problemi nella distribuzione dei pod finché non si definiscono criteri personalizzati. L'approccio consigliato è:

1. Creare un cluster del servizio Azure Kubernetes.
2. Definire i propri criteri di sicurezza dei pod.
3. Abilitare la funzionalità dei criteri di sicurezza dei pod.

Modifiche del comportamento tra i criteri di sicurezza dei pod e i Criteri Azure

Scenario	Criteri di sicurezza dei pod	Criteri di Azure
Installazione	Abilitare la funzionalità dei criteri di sicurezza dei pod	Abilitare il componente aggiuntivo Criteri di Azure
Distribuire i criteri	Distribuire la risorsa dei criteri di sicurezza dei pod	Assegnare i criteri di Azure all'ambito della sottoscrizione o del gruppo di risorse. Il componente aggiuntivo Criteri di Azure è necessario per le applicazioni di risorse Kubernetes.
Criteri predefiniti	Quando i criteri di sicurezza dei pod sono abilitati nel servizio Azure Kubernetes, vengono applicati i criteri con privilegi predefiniti e senza restrizioni.	Non vengono applicati criteri predefiniti abilitando il componente aggiuntivo Criteri di Azure. È necessario abilitare in modo esplicito i criteri in Criteri di Azure.
Chi può creare e assegnare criteri	L'amministratore del cluster crea una risorsa dei criteri di sicurezza dei pod	Gli utenti devono avere un ruolo minimo di autorizzazioni "proprietario" o "Collaboratore criteri risorse" nel gruppo di risorse del cluster del servizio Azure Kubernetes. - Tramite l'API, gli utenti possono assegnare criteri nell'ambito della risorsa cluster del servizio Azure Kubernetes. L'utente deve avere almeno le autorizzazioni "proprietario" o "Collaboratore criteri risorse" per la risorsa cluster del servizio Azure Kubernetes. - Nel portale di Azure i criteri possono essere assegnati a livello di gruppo di gestione/sottoscrizione/gruppo di risorse.
Autorizzazione dei criteri	Gli utenti e gli account di servizio richiedono autorizzazioni esplicite per usare i criteri di sicurezza dei pod.	Non è necessaria alcuna assegnazione aggiuntiva per autorizzare i criteri. Una volta assegnati i criteri in Azure, tutti gli utenti del cluster possono usarli.
Applicabilità dei criteri	L'utente amministratore ignora l'applicazione dei criteri di sicurezza dei pod.	Tutti gli utenti (amministratore e non amministratore) vedono gli stessi criteri. Non esistono maiuscole e minuscole speciali in base agli utenti. L'applicazione dei criteri può essere esclusa a livello di spazio dei nomi.
Ambito dei criteri	I criteri di sicurezza dei pod non sono presenti a livello di spazio dei nomi	I modelli di vincolo usati da Criteri di Azure non sono presenti a livello di spazio dei nomi.
Azione di negazione/controllo/mutazione	I criteri di sicurezza dei pod supportano solo azioni di negazione. La mutazione può essere eseguita con i valori predefiniti nelle richieste di creazione. La convalida può essere eseguita durante le richieste di aggiornamento.	Criteri di Azure supporta sia le azioni di controllo che di negazione. La mutazione non è ancora supportata.
Conformità dei criteri di sicurezza dei pod	Non c'è visibilità sulla conformità dei pod che esistevano prima dell'attivazione dei criteri di sicurezza dei pod. I pod non conformi creati dopo l'abilitazione dei criteri di sicurezza dei pod vengono negati.	I pod non conformi che esistevano prima dell'applicazione dei criteri di Azure venivano visualizzati nelle violazioni dei criteri. I pod non conformi creati dopo l'abilitazione dei criteri di Azure vengono negati se i criteri sono impostati con effetto di negazione.
Come visualizzare i criteri nel cluster	kubectl get psp	kubectl get constrainttemplate: vengono restituiti tutti i criteri.
Standard dei criteri di sicurezza dei pod: Con privilegi	Una risorsa dei criteri di sicurezza dei pod con privilegi viene creata per impostazione predefinita quando si abilita la funzionalità.	La modalità con privilegi non implica alcuna restrizione, di conseguenza equivale a non avere alcuna assegnazione di Criteri di Azure.
Criteri di sicurezza dei pod: Baseline/default	L'utente installa una risorsa di base dei criteri di sicurezza dei pod.	Criteri di Azure offre un'iniziativa di base predefinita che esegue il mapping ai criteri di sicurezza dei pod di base.
Standard di sicurezza dei pod: Con restrizioni	L'utente installa una risorsa con restrizioni per i criteri di sicurezza dei pod.	Criteri di Azure offre un'iniziativa con restrizioni predefinita che esegue il mapping ai criteri di sicurezza dei pod con restrizioni.

Abilitare i criteri di sicurezza dei pod in un cluster del servizio Azure Kubernetes

Nota

Per l'uso reale, non abilitare i criteri di sicurezza dei pod finché non si definiscono i criteri personalizzati. In questo articolo, si abilitano i criteri di sicurezza dei pod come primo passaggio per vedere come i criteri predefiniti limitano le distribuzioni dei pod.

• Abilitare i criteri di sicurezza dei pod usando il comando az aks update.

  az aks update \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --enable-pod-security-policy
  

Criteri predefiniti del servizio Azure Kubernetes

Quando si abilitano i criteri di sicurezza dei pod, il servizio Azure Kubernetes crea un criterio predefinito denominato con privilegi. Non modificare o rimuovere i criteri predefiniti. Creare invece criteri personalizzati che definiscono le impostazioni da controllare. Si esaminerà prima di tutto il modo in cui questi criteri predefiniti influiscono sulle distribuzioni dei pod.

1. Visualizzare i criteri disponibili usando il comando kubectl get psp.

   kubectl get psp
   

   L'output sarà simile all'output di esempio seguente:

   NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
   

   I criteri di sicurezza dei pod con privilegi vengono applicati a qualsiasi utente autenticato nel cluster del servizio Azure Kubernetes. Questa assegnazione è controllata da ClusterRoles e ClusterRoleBindings.

2. Cercare l'associazione default:privileged: nello spazio dei nomi kube-system usando il comando kubectl get rolebindings.

   kubectl get rolebindings default:privileged -n kube-system -o yaml
   

   L'output di esempio condensato seguente mostra che psp:privilegedClusterRole viene assegnato a qualsiasi utente system:authenticated. Questa capacità fornisce un livello di privilegio di base senza che vengano definiti i propri criteri.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     [...]
     name: default:privileged
     [...]
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp:privileged
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   

È importante comprendere come questi criteri predefiniti interagiscono con le richieste di pianificazione dei pod da parte degli utenti prima di iniziare a creare i propri criteri di sicurezza dei pod. Nelle sezioni successive, verranno pianificati alcuni pod per vedere in azione i criteri predefiniti.

Creare un utente di test in un cluster del servizio Azure Kubernetes

Quando si usa il comando az aks get-credentials, le credenziali di amministratore per il cluster del servizio Azure Kubernetes vengono aggiunte alla configurazione kubectl per impostazione predefinita. L'utente amministratore ignora l'applicazione dei criteri di sicurezza dei pod. Se si usa l'integrazione di Microsoft Entra per i cluster del servizio Azure Kubernetes, è possibile accedere con le credenziali di un utente non amministratore per vedere l'applicazione dei criteri in azione.

1. Creare uno spazio dei nomi di esempio denominato psp-aks per le risorse di test usando il comando kubectl create namespace.

   kubectl create namespace psp-aks
   

2. Creare un account di servizio denominato nonadmin-user usando il comando kubectl create serviceaccount.

   kubectl create serviceaccount --namespace psp-aks nonadmin-user
   

3. Creare un RoleBinding per il nonadmin-user per eseguire azioni di base nello spazio dei nomi usando il comando kubectl create rolebinding.

   kubectl create rolebinding \
       --namespace psp-aks \
       psp-aks-editor \
       --clusterrole=edit \
       --serviceaccount=psp-aks:nonadmin-user
   

Creare comandi alias per l'amministratore e l'utente non amministratore

Quando si usa kubectl, è possibile evidenziare le differenze tra l'utente amministratore normale e l'utente non amministratore creando due alias della riga di comando:

1. L'alias kubectl-admin per l'utente amministratore normale, che ha come ambito lo spazio dei nomi psp-aks.
2. Alias di kubectl-nonadminuser per il nonadmin-user creato nel passaggio precedente, che ha come ambito lo spazio dei nomi psp-aks.

• Creare i due alias usando i comandi seguenti.

  alias kubectl-admin='kubectl --namespace psp-aks'
  alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'
  

Testare la creazione di un pod con privilegi

Si esaminerà ora 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. Il criterio di sicurezza del servizio Azure Kubernetes con privilegio predefinito dovrebbe negare questa richiesta.

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

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

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

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   L'output di esempio seguente mostra che il pod non è stato pianificato:

   Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
   

   Poiché il pod non raggiunge la fase di pianificazione, non sono presenti risorse da eliminare prima di procedere.

Testare la creazione di un pod senza privilegi

Nell'esempio precedente, la specifica del pod ha richiesto l'escalation dei privilegi. Questa richiesta è negata dal privilegiodei criteri di sicurezza dei pod predefinito, quindi non è possibile pianificare il pod. Provare a eseguire lo stesso pod NGINX senza la richiesta di escalation dei privilegi.

1. Creare un file denominato nginx-unprivileged.yaml e incollare nei contenuti del manifesto YAML seguente.

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

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

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   L'output di esempio seguente mostra che il pod non è stato pianificato:

   Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
   

   Poiché il pod non raggiunge la fase di pianificazione, non sono presenti risorse da eliminare prima di procedere.

Testare la creazione di un pod con un contesto utente specifico

Nell'esempio precedente l'immagine del contenitore ha cercato di usare automaticamente la radice per associare NGINX alla porta 80. Questa richiesta è stata negata dal privilegio predefinito dei criteri di sicurezza dei pod, quindi non è possibile avviare il pod. Provare a eseguire lo stesso pod NGINX con un contesto utente specifico, ad esempio runAsUser: 2000.

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged-nonroot
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           runAsUser: 2000
   

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

   kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
   

   L'output di esempio seguente mostra che il pod non è stato pianificato:

   Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []
   

   Poiché il pod non raggiunge la fase di pianificazione, non sono presenti risorse da eliminare prima di procedere.

Creare criteri di sicurezza dei pod personalizzati

Dopo aver visto il comportamento dei criteri di sicurezza dei pod predefinite è possibile consentire al nonadmin-user di pianificare correttamente i pod.

Verrà creato un criterio per rifiutare i pod che richiedono l'accesso con privilegi. Altre opzioni, ad esempio runAsUser o volumi consentiti, non sono limitate in modo esplicito. Questo tipo di criteri nega una richiesta di accesso con privilegi, ma consente al cluster di eseguire i pod richiesti.

1. Creare un file denominato psp-deny-privileged.yaml e incollare nel manifesto YAML seguente.

   apiVersion: policy/v1beta1
   kind: PodSecurityPolicy
   metadata:
     name: psp-deny-privileged
   spec:
     privileged: false
     seLinux:
       rule: RunAsAny
     supplementalGroups:
       rule: RunAsAny
     runAsUser:
       rule: RunAsAny
     fsGroup:
       rule: RunAsAny
     volumes:
    - '*'
   

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

   kubectl apply -f psp-deny-privileged.yaml
   

3. Visualizzare i criteri disponibili usando il comando kubectl get psp.

   kubectl get psp
   

   Nell'output di esempio seguente confrontare i criteri psp-deny-privileged con il criterio del privilegio predefinito applicato negli esempi precedenti per creare un pod. Solo l'uso dell'escalation PRIV è negato dai propri criteri. Non esistono restrizioni per l'utente o per il gruppo per il criterio psp-deny-privileged.

   NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
   psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *          
   

Consentire all'account utente di usare i criteri di sicurezza dei pod personalizzati

Nel passaggio precedente è stato creato un criterio di sicurezza dei pod per rifiutare i pod che richiedono l'accesso con privilegi. Per consentire l'uso dei criteri, creare un Ruolo o un ClusterRole. Quindi, si associa uno di questi ruoli usando un RoleBinding o un ClusterRoleBinding. Per questo esempio verrà creato un ClusterRole che consente di usare il criterio psp-deny-privileged creato nel passaggio precedente.

1. Creare un file denominato psp-deny-privileged-clusterrole.yaml e incollare nel manifesto YAML seguente.

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: psp-deny-privileged-clusterrole
   rules:
   - apiGroups:
     - extensions
      resources:
     - podsecuritypolicies
      resourceNames:
     - psp-deny-privileged
      verbs:
     - use
   

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

   kubectl apply -f psp-deny-privileged-clusterrole.yaml
   

3. Creare un file denominato psp-deny-privileged-clusterrolebinding.yaml e incollare nel manifesto YAML seguente.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: psp-deny-privileged-clusterrolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp-deny-privileged-clusterrole
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   

4. Creare il ClusterRoleBinding usando il comando kubectl apply e specificare il nome del manifesto YAML.

   kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
   

Nota

Nei primi passaggi di questo articolo, la funzionalità dei criteri di sicurezza dei pod è stata abilitata nel cluster del servizio Azure Kubernetes. La procedura consigliata consiste nell'abilitare solo la funzionalità dei criteri di sicurezza dei pod dopo aver definito criteri personalizzati. Questa è la fase in cui si abilita la funzionalità dei criteri di sicurezza dei pod. Sono stati definiti uno o più criteri personalizzati e gli account utente sono stati associati a tali criteri. Ora è possibile abilitare in modo sicuro la funzionalità dei criteri di sicurezza dei pod e ridurre al minimo i problemi causati dai criteri predefiniti.

Testare di nuovo la creazione di un pod senza privilegi

Con i criteri di sicurezza dei pod personalizzati applicati e un'associazione per l'account utente che deve usare i criteri, provare a creare di nuovo un pod senza privilegi.

Questo esempio illustra come creare criteri di sicurezza dei pod personalizzati per definire l'accesso al cluster del servizio Azure Kubernetes per utenti o gruppi diversi. I criteri predefiniti del servizio Azure Kubernetes forniscono controlli rigorosi su ciò che i pod possono eseguire, quindi è necessario creare criteri personalizzati per definire correttamente le restrizioni necessarie.

1. Usare il manifesto nginx-privileged.yaml per creare il pod usando il comando kubectl apply.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

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

   kubectl-nonadminuser get pods
   

   L'output di esempio seguente mostra che il pod è stato pianificato correttamente ed è In esecuzione:

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          7m14s
   

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

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Pulire le risorse

1. Disabilitare i criteri di sicurezza dei pod usando il comando az aks update.

   az aks update \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --disable-pod-security-policy
   

2. Eliminare il ClusterRole e il ClusterRoleBinding usando il comando kubectl delete.

   kubectl delete -f psp-deny-privileged-clusterrole.yaml
   

3. Eliminare il ClusterRoleBinding usando il comando kubectl delete.

   kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
   

4. Eliminare i criteri di sicurezza usando il comandokubectl delete e specificare il nome del manifesto YAML.

   kubectl delete -f psp-deny-privileged.yaml
   

5. Eliminare lo spazio dei nomi psp-aks usando il comando kubectl delete.

   kubectl delete namespace psp-aks
   

Passaggi successivi

Questo articolo ha mostrato come creare i criteri di sicurezza dei pod per impedire l'uso di accessi con privilegi. I criteri possono applicare molte funzionalità, come il tipo di volume o l'utente RunAs. Per altre informazioni sulle opzioni disponibili, vedere la Documentazione di riferimento sui criteri di sicurezza dei pod Kubernetes.

Per altre informazioni sulla limitazione del traffico di rete dei pod, vedere Proteggere il traffico tra i pod usando i criteri di rete nel servizio Azure Kubernetes.