Proteggi l'accesso ai contenitori alle risorse per i carichi di lavoro del servizio Azure Kubernetes (AKS) utilizzando funzionalità di sicurezza Linux integrate.

Prerequisiti per gli spazi dei nomi utente

• Un cluster del servizio Azure Kubernetes pre-esistente. Se non si ha un cluster, crearne uno usando l'interfaccia della riga di comando di Azure, Azure PowerShello il portale di Azure.
• Versione minima di Kubernetes 1.33 per il piano di controllo e i nodi di lavoro. Se non si usa Kubernetes versione 1.33 o successiva, è necessario aggiornare la versione di Kubernetes.
• Nodi di lavoro che eseguono Azure Linux 3.0 o Ubuntu 24.04 per assicurarsi di soddisfare i requisiti di stack minimi per abilitare gli spazi dei nomi utente. Se è necessario aggiornare la versione del sistema operativo, vedere Aggiornare la versione del sistema operativo.

Limitazioni per gli spazi dei nomi utente

• La funzionalità degli spazi dei nomi utente è per il kernel Linux e non è supportata per i pool di nodi Windows.
• Per eventuali altre limitazioni, vedere la documentazione di Kubernetes per gli spazi dei nomi utente .

Panoramica dei namespace utente

Per impostazione predefinita, i pod Linux vengono eseguiti usando diversi spazi dei nomi: uno spazio dei nomi di rete per isolare l'identità di rete e uno spazio dei nomi PID per isolare i processi. Uno spazio dei nomi utente (user_namespace) isola gli utenti all'interno del contenitore dagli utenti dell'host. Limita anche l'ambito delle funzionalità e le interazioni del pod con il resto del sistema.

Gli UID e i GID all'interno del contenitore vengono mappati negli utenti senza privilegi sull'host, quindi tutte le interazioni con il resto dell'host avvengono come quelle UID e GID senza privilegi. Ad esempio, la radice all'interno del contenitore (UID 0) può essere mappata nell'utente 65536 sull'host. Kubernetes crea il mapping per garantire che non si sovrapponga ad altri pod usando spazi dei nomi utente nel sistema.

L'implementazione di Kubernetes presenta alcuni vantaggi chiave. Per altre informazioni, vedere la documentazione relativa agli spazi dei nomi utente di Kubernetes.

Abilitare gli spazi dei nomi utente

1. Creare un file denominato mypod.yaml e copiarlo nel manifesto seguente. Per usare gli spazi dei nomi utente, YAML deve avere il campo hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Distribuire l'applicazione usando il comando kubectl apply e specificare il nome del manifesto YAML.

   kubectl apply -f mypod.yaml
   

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

   kubectl get pods
   

4. Accedere al pod usando il comando kubectl exec.

   kubectl exec -ti userns -- bash
   

5. All'interno del pod, controllare /proc/self/uid_map utilizzando il comando seguente:

   cat /proc/self/uid_map
   

   L'output deve avere 65536 nell'ultima colonna. Per esempio:

   0  833617920      65536
   

   Questo output indica che l'utente root all'interno del contenitore (UID 0) è mappato all'utente 65536 sul host.

Vulnerabilità ed esposizioni comuni (CVE) attenuate dagli spazi dei nomi degli utenti

La tabella seguente illustra alcune vulnerabilità ed esposizioni comuni (CVE) parzialmente o completamente attenuate tramite user_namespaces:

Tenere presente che questo elenco non è esaustivo. Per altre informazioni, vedere Kubernetes v1.33: spazi dei nomi utente abilitati per impostazione predefinita.

Prerequisiti di AppArmor

• Un cluster del servizio Azure Kubernetes pre-esistente. Se non si ha un cluster, crearne uno usando l'interfaccia della riga di comando di Azure, Azure PowerShello il portale di Azure.

Panoramica di AppArmor

Per limitare le azioni del contenitore, è possibile usare il modulo di sicurezza del kernel AppArmor Linux. AppArmor è disponibile come parte del sistema operativo (OS) del nodo AKS sottostante di Azure Kubernetes Service ed è abilitato di default. È possibile creare profili AppArmor che limitano le azioni di lettura, scrittura o esecuzione o funzioni di sistema come il montaggio di file system. I profili AppArmor predefiniti limitano l'accesso a vari percorsi /proc e /sys e consentono di isolare logicamente i contenitori dal nodo sottostante. AppArmor funziona non solo per i pod Kubernetes ma per qualsiasi applicazione in esecuzione su Linux.

Proteggere i pod con AppArmor

È possibile specificare i profili AppArmor a livello di pod o contenitore. Il profilo AppArmor del contenitore ha la precedenza sul profilo AppArmor del pod. In assenza di parametri specificati, il contenitore viene eseguito senza restrizioni. Per altre informazioni sui profili AppArmor, vedere la documentazione relativa alla protezione di un pod con AppArmor Kubernetes.

Configurare un profilo AppArmor personalizzato

Nell'esempio seguente viene creato un profilo che impedisce la scrittura nei file all'interno di un contenitore.

1. Connettersi tramite SSH a un nodo del servizio Azure Kubernetes.

2. Creare un file denominato deny-write.profile e incollarlo nel contenuto seguente:

   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   

3. Caricare il profilo AppArmor nel nodo.

   # This example assumes that node names match host names, and are reachable via SSH.
   NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))
   
   for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   EOF'
   done
   

Distribuire un pod con il profilo AppArmor personalizzato

1. Distribuire un pod "Hello AppArmor" con il profilo deny-write.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
   spec:
     securityContext:
       appArmorProfile:
         type: Localhost
         localhostProfile: k8s-apparmor-example-deny-write
     containers:
     - name: hello
       image: busybox:1.28
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

2. Applicare il manifesto del pod usando il kubectl apply comando .

   kubectl apply -f hello-apparmor.yaml
   

3. Accedere al pod e verificare che il contenitore sia in esecuzione con il profilo AppArmor.

   kubectl exec hello-apparmor -- cat /proc/1/attr/current
   

   L'output dovrebbe mostrare il profilo AppArmor in uso. Per esempio:

   k8s-apparmor-example-deny-write (enforce)
   

Prerequisiti di Seccomp

• Un cluster del servizio Azure Kubernetes pre-esistente. Se non si ha un cluster, crearne uno usando l'interfaccia della riga di comando di Azure, Azure PowerShello il portale di Azure.
• È necessario registrare il KubeletDefaultSeccompProfilePreview flag di funzionalità per usare i profili seccomp predefiniti nei pool di nodi.

Registrare il flag di funzionalità KubeletDefaultSeccompProfilePreview

1. Registrare il flag della funzionalità KubeletDefaultSeccompProfilePreview usando il comando az feature register.

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

   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 "KubeletDefaultSeccompProfilePreview"
   

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
   

Limitazioni di Seccomp

• AKS supporta solo i profili seccomp predefiniti (RuntimeDefault e Unconfined). I profili seccomp personalizzati non sono supportati.
• SeccompDefault non è un parametro supportato per i pool di nodi Windows.

Panoramica dei profili seccomp predefiniti (anteprima)

Mentre AppArmor funziona per qualsiasi applicazione Linux, seccomp (o secure computing) funziona a livello di processo. Seccomp è anche un modulo di sicurezza kernel Linux. Il containerd runtime usato dai nodi del servizio Azure Kubernetes fornisce il supporto nativo per seccomp. Con seccomp, è possibile limitare le chiamate di sistema di un contenitore. Seccomp stabilisce un ulteriore livello di protezione da vulnerabilità comuni delle chiamate di sistema sfruttate da attori malintenzionati e consente di specificare un profilo predefinito per tutti i carichi di lavoro nel nodo.

È possibile applicare profili seccomp predefiniti usando configurazioni di nodo personalizzate durante la creazione di un nuovo pool di nodi Linux. AKS supporta i valori RuntimeDefault e Unconfined. Alcuni carichi di lavoro potrebbero richiedere un numero inferiore di restrizioni per le chiamate di sistema rispetto ad altri. Ciò significa che possono ritrovarsi in errore durante il runtime con il profilo RuntimeDefault. Per attenuare un errore di questo tipo, è possibile specificare il profilo Unconfined. Se il carico di lavoro richiede un profilo personalizzato, vedere Configurare un profilo seccomp personalizzato.

Limitare le chiamate di sistema dei contenitori con seccomp

1. Seguire la procedura per applicare un profilo seccomp nella configurazione di kubelet specificando "seccompDefault": "RuntimeDefault".
2. Connettersi all'host.
3. Verificare che la configurazione sia stata applicata ai nodi.

Risolvere gli errori del carico di lavoro con seccomp

Quando SeccompDefault è abilitata, il profilo seccomp predefinito del runtime del contenitore viene usato per tutti i carichi di lavoro pianificati nel nodo, il che può causare errori nei carichi di lavoro a causa di chiamate di sistema bloccate. Se si verifica un errore del carico di lavoro, è possibile che vengano visualizzati errori come:

• Il carico di lavoro si interrompe in modo imprevisto dopo l'abilitazione della funzionalità, con l'errore "autorizzazione negata".
• I messaggi di errore seccomp possono essere visualizzati anche in auditd o syslog sostituendo SCMP_ACT_ERRNO con SCMP_ACT_LOG nel profilo predefinito.

Se si verificano questi errori, è consigliabile modificare il profilo seccomp in Unconfined. Unconfined non applica restrizioni alle chiamate di sistema, consentendo l'esecuzione di tutte le chiamate di sistema.

Panoramica dei profili seccomp personalizzati

Con un profilo seccomp personalizzato, è possibile avere un controllo più granulare sulle chiamate di sistema limitate per i contenitori. È possibile creare profili seccomp personalizzati in base a:

• Uso dei filtri per specificare le azioni da consentire o negare.
• Annotazione all'interno di un manifesto YAML del pod da associare al filtro seccomp.

Configurare un profilo seccomp personalizzato

Per una dimostrazione di seccomp in azione, creare un filtro che impedisce di cambiare le autorizzazioni su un file.

1. Connettersi tramite SSH a un nodo del servizio Azure Kubernetes.

2. Creare un filtro seccomp denominato /var/lib/kubelet/seccomp/prevent-chmod.

3. Copiare e incollare il contenuto seguente:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   Nella versione 1.19 e successive è necessario configurare:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. Dal computer locale creare un manifesto pod denominato aks-seccomp.yaml e incollare il contenuto seguente. Questo manifesto definisce un'annotazione per seccomp.security.alpha.kubernetes.io e fa riferimento al filtro prevent-chmod esistente.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   Nella versione 1.19 e successive è necessario configurare:

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Distribuire il pod di esempio usando il kubectl apply comando :

   kubectl apply -f ./aks-seccomp.yaml
   

6. Visualizzare lo stato del pod usando il kubectl get pods comando .

   kubectl get pods
   

   Nell'output, dovresti vedere che il pod segnala un errore. Come illustrato nell'output di esempio, il filtro seccomp impedisce l'esecuzione del comando chmod:

   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s