Condividi tramite

Accesso dei contenitori di sicurezza alle risorse tramite funzionalità di sicurezza Linux predefinite

Questo articolo illustra come proteggere l'accesso dei contenitori alle risorse per i carichi di lavoro del servizio Azure Kubernetes.

Importante

A partire dal 30 novembre 2025, il servizio Azure Kubernetes non supporta più o fornisce aggiornamenti della sicurezza per Azure Linux 2.0. L'immagine del nodo Linux 2.0 di Azure è bloccata alla versione 202512.06.0. A partire dal 31 marzo 2026, le immagini dei nodi verranno rimosse e non sarà possibile ridimensionare i pool di nodi. Eseguire la migrazione a una versione di Linux di Azure supportata aggiornando i pool di nodi a una versione di Kubernetes supportata o eseguendo la migrazione ad osSku AzureLinux3. Per altre informazioni, vedere [Ritiro] Pool di nodi di Azure Linux 2.0 nel servizio Azure Kubernetes.

Panoramica

Allo stesso modo in cui è necessario concedere agli utenti o ai gruppi i privilegi minimi necessari, è anche necessario limitare i contenitori solo alle azioni e ai processi necessari. Per ridurre al minimo il rischio di attacco, evitare di configurare applicazioni e contenitori che richiedono privilegi di escalation o accesso radice.

È possibile usare contesti di sicurezza dei pod Kubernetes integrati per definire altre autorizzazioni, ad esempio utente o gruppo da eseguire, le funzionalità Linux da esporre o impostare allowPrivilegeEscalation: false nel manifesto del pod. Per altre procedure consigliate, vedere Proteggere l'accesso dei pod alle risorse.

Per migliorare l'isolamento dell'host e ridurre lo spostamento laterale in Linux, è possibile usare gli spazi dei nomi utente.

Per un controllo ancora più granulare delle azioni dei contenitori, è possibile usare funzionalità di sicurezza predefinite di Linux, come AppArmor e seccomp.

  1. Definire le funzionalità di sicurezza di Linux a livello di nodo.
  2. Implementare le funzionalità tramite un manifesto del pod.

Le funzionalità di sicurezza Linux predefinite sono disponibili solo nei nodi e nei pod Linux.

Note

Attualmente, gli ambienti Kubernetes non sono completamente sicuri per l'utilizzo multi-tenant ostile. Funzionalità di sicurezza aggiuntive, ad esempio Microsoft Defender per contenitori, AppArmor, seccomp, spazi dei nomi utente, ammissione di sicurezza dei pod o controllo degli accessi in base al ruolo di Kubernetes per i nodi, bloccano in modo efficiente gli exploit.

Per una vera sicurezza quando si eseguono carichi di lavoro multi-tenant ostili, considerare attendibile solo un hypervisor. Il dominio di sicurezza per Kubernetes diventa l'intero cluster, non un singolo nodo.

Per questi tipi di carichi di lavoro multi-tenant ostili è consigliabile usare cluster fisicamente isolati.

Spazi dei nomi 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 isola gli utenti all'interno del contenitore dagli utenti nell'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 principali:

  • Maggiore isolamento dell’host: se un contenitore esegue l'escape dei limiti del pod, anche se viene eseguito come radice all'interno del contenitore, non dispone di privilegi per l'host. Il motivo è che gli UID e i GID del contenitore vengono mappati in utenti senza privilegi nell'host. Se è presente un escape del contenitore, gli spazi dei nomi utente proteggono notevolmente i file nell'host in cui un contenitore può leggere/scrivere, il processo a cui può inviare segnali. Le funzionalità concesse sono valide solo all'interno dello spazio dei nomi utente e non nell'host.

  • Prevenzione dello spostamento laterale: man mano che gli UID e i GID per contenitori diversi vengono mappati in UID e GID diversi non sovrapposti nell'host, i contenitori hanno un tempo più difficile da attaccare l'uno all'altro. Si supponga, ad esempio, che il contenitore A venga eseguito con UID e GID diversi nell'host rispetto al contenitore B. In caso di interruzione del contenitore, le operazioni che può eseguire sui file e sui processi del contenitore B sono limitate: solo lettura/scrittura di ciò che un file consente ad altri utenti. Ma non è nemmeno possibile, poiché esiste una prevenzione aggiuntiva nella directory padre del volume radice del pod per assicurarsi che solo il POD GID possa accedervi.

  • Rispettare il principio dei privilegi minimi: man mano che gli UID e i GID vengono mappati negli utenti senza privilegi nell'host, solo gli utenti che necessitano del privilegio nell'host (e disabilitano gli spazi dei nomi utente) lo ottengono. Senza spazi dei nomi utente, non esiste alcuna separazione tra gli utenti del contenitore e gli utenti dell'host. Non è possibile evitare di concedere privilegi all'host ai processi che non ne hanno bisogno, quando hanno bisogno di privilegi solo all'interno del contenitore.

  • Abilitazione dei nuovi casi d'uso: gli spazi dei nomi utente consentono ai contenitori di ottenere determinate funzionalità all'interno del proprio spazio dei nomi utente senza influire sull'host. Le funzionalità concesse con restrizioni al pod sbloccano nuove possibilità, ad esempio l'esecuzione di applicazioni che richiedono operazioni con privilegi senza concedere l'accesso radice completo nell'host. I nuovi casi d'uso comuni che possono essere implementati in modo sicuro sono: l'esecuzione di contenitori annidati e le compilazioni di contenitori senza privilegi.

  • Configurazione del contenitore senza privilegi: la maggior parte della creazione e dell'installazione del contenitore non viene eseguita come radice nell'host, il che limita significativamente l'impatto di molti CVE.

Nessuna di queste cose è vera quando gli spazi dei nomi utente non vengono usati. Se il contenitore viene eseguito come radice, quando gli spazi dei nomi utente non vengono usati, il processo viene eseguito come radice nell'host, le funzionalità sono valide nell'host e l'installazione del contenitore viene eseguita come radice nell'host.

Prima di iniziare

Prima di iniziare, verificare di disporre di quanto segue:

Limitazioni

Abilitare gli spazi dei nomi utente

Non sono necessarie configurazioni per usare questa funzionalità. Se si usa la versione del servizio Azure Kubernetes necessaria, tutto funziona correttamente.

  1. Creare un file denominato mypod.yaml e copiarlo nel manifesto seguente:

    Per usare gli spazi dei nomi utente, il file yaml deve disporre del 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. Procedere all'esecuzione nel pod da controllare /proc/self/uid_map usando il comando kubectl exec:

    kubectl exec -ti userns -- bash
# Now inside the pod run
cat /proc/self/uid_map

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

0  833617920      65536

CVE mitigati

Ecco alcuni CVE completamente o parzialmente mitigati con spazi dei nomi utente.

Tenere presente che l'elenco non è esaustivo, è solo una selezione di CVE mitigati con punteggio elevato:

Per altre informazioni, leggere questo post di blog con informazioni aggiuntive sugli spazi dei nomi utente.

AppArmor

Per limitare le azioni del contenitore, è possibile usare il modulo di sicurezza del kernel AppArmor Linux. Il modulo è disponibile come parte del sistema operativo del nodo del servizio Azure Kubernetes sottostante ed è abilitato per impostazione predefinita. È 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.

Note

Azure Linux 3.0 non offre il supporto AppArmor. Per i nodi Linux 3.0 di Azure, è consigliabile usare SELinux anziché AppArmor per il controllo di accesso obbligatorio.

Profili AppArmor in uso in un cluster del servizio Azure Kubernetes per limitare le azioni dei contenitori

Per una dimostrazione di AppArmor in azione, l'esempio seguente crea un profilo che impedisce la scrittura nei file.

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

  2. Creare un file denominato deny-write.profile.

  3. Copiare e incollare il contenuto seguente:

    #include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  # Deny all file writes.
  deny /** w,
}

Per aggiungere profili AppArmor occorre usare il comando apparmor_parser.

  1. Aggiungere il profilo ad AppArmor.

  2. Specificare il nome del profilo creato nel passaggio precedente:

    sudo apparmor_parser deny-write.profile

    Se il profilo viene analizzato correttamente e applicato ad AppArmor, non verrà visualizzato alcun output e verrà restituito al prompt dei comandi.

  3. Dal computer locale creare un manifesto del pod denominato aks-apparmor.yaml. Questo manifesto:

    • Definisce un'annotazione per container.apparmor.security.beta.kubernetes.
    • Fa riferimento al profilo di deny-write creato nei passaggi precedenti.
    apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: hello
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  4. Con il pod distribuito, eseguire il comando seguente e verificare che il pod hello-apparmor mostri uno stato di In esecuzione:

    kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
aks-ssh          1/1     Running   0          4m2s
hello-apparmor   0/1     Running   0          50s

Per altre informazioni su AppArmor, vedere AppArmor nella documentazione di Kubernetes.

Secure computing (seccomp)

Mentre AppArmor funziona con qualsiasi applicazione Linux, seccomp (secure computing, elaborazione sicura) funziona a livello di processo. Anche seccomp è un modulo di protezione del kernel di Linux ed è supportato in modo nativo dal runtime containerd usato dai nodi del servizio Azure Kubernetes. 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.

Configurare un profilo seccomp predefinito (anteprima)

È possibile applicare profili seccomp predefiniti usando configurazioni di nodo personalizzate durante la creazione di un nuovo pool di nodi Linux. Sono supportati due valori nel servizio Azure Kubernetes: 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 avere esito negativo 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.

Limitazioni

  • SeccompDefault non è un parametro supportato per i pool di nodi Windows.
  • SeccompDefault è disponibile a partire dall'API 2024-09-02-preview.

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e con consenso esplicito. 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 ambienti di produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

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

Limitare le chiamate di sistema del contenitore con seccomp

1. Seguire i passaggi per applicare un profilo seccomp nella configurazione di kubelet specificando "seccompDefault": "RuntimeDefault".

RuntimeDefault usa il profilo seccomp predefinito di containerd, limitando determinate chiamate di sistema per migliorare la sicurezza. Le chiamate di sistema con restrizioni avranno esito negativo. Per altre informazioni, vedere il profilo seccomp predefinito containerD.

2. Verificare che la configurazione sia stata applicata.

È possibile verificare che le impostazioni vengano applicate ai nodi connettendosi all'host e verificando che nel file system siano state apportate modifiche alla configurazione.

3. Risolvere gli errori del carico di lavoro.

Quando SeccompDefault è abilitato, il profilo seccomp predefinito del runtime del contenitore viene usato per impostazione predefinita per tutti i carichi di lavoro pianificati nel nodo. Ciò potrebbe causare un errore dei carichi di lavoro a causa di chiamate di sistema bloccate. Se si è verificato un errore del carico di lavoro, è possibile che vengano visualizzati errori come:

  • Il carico di lavoro è esistente in modo imprevisto dopo l'abilitazione della funzionalità, con 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 gli errori precedenti, è consigliabile modificare il profilo seccomp in Unconfined. Unconfined non applica restrizioni a syscall, consentendo tutte le chiamate di sistema, riducendo così la sicurezza.

Configurare un profilo seccomp personalizzato

Con un profilo seccomp personalizzato, è possibile avere un controllo più granulare sulle syscall con restrizioni. Allineare alla procedura consigliata di concedere al contenitore l'autorizzazione minima solo per l'esecuzione da:

  • Definizione con filtra le azioni da consentire o negare.
  • Annotazione all'interno di un manifesto YAML del pod da associare al filtro seccomp.

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.
    • Fa riferimento al filtro di prevent-chmod creato nel passaggio precedente.
    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 comando kubectl apply:

    kubectl apply -f ./aks-seccomp.yaml

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

    • Il pod segnala un errore.
    • Come illustrato nell'output di esempio, il filtro seccomp impedisce l'esecuzione del comando chmod:
    kubectl get pods

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

Per informazioni sulla risoluzione dei problemi del profilo seccomp, vedere l'articolo Risolvere i problemi di configurazione del profilo seccomp nel servizio Azure Kubernetes.

Opzioni del profilo di sicurezza Seccomp

I profili di sicurezza Seccomp sono un set consentito o limitato di syscall definite. La maggior parte dei runtime di contenitori ha un profilo seccomp predefinito simile se non uguale a quello usato da Docker. Per altre informazioni sui profili disponibili, vedere pofili seccomp predefiniti Docker o containerD.

Il servizio Azure Kubernetes usa il profilo seccomp predefinito containerD per RuntimeDefault quando si configura seccomp usando la configurazione personalizzata dei nodi.

Syscall significativi bloccati dal profilo predefinito

Sia Docker che containerD mantengono elenchi consentiti di chiamate syscall sicure. Questa tabella elenca le chiamate di sistema significative (ma non tutte) bloccate in modo efficace perché non sono presenti nell'elenco elementi consentiti. Se una delle chiamate di sistema bloccate è richiesta dal carico di lavoro, non usare il profilo seccomp RuntimeDefault.

Quando vengono apportate modifiche a Docker e containerD, il servizio Azure Kubernetes aggiorna la configurazione predefinita in modo che corrisponda. Gli aggiornamenti a questo elenco possono causare un errore del carico di lavoro. Per gli aggiornamenti delle versioni, vedere Note sulla versione del servizio Azure Kubernetes.

Syscall bloccato Descrizione
acct Accounting di syscall che potrebbe consentire ai contenitori di disabilitare i propri limiti di risorse o di elaborare la contabilità. Gestito anche da CAP_SYS_PACCT.
add_key Impedire ai contenitori di usare il keyring del kernel, che non è spazio dei nomi.
bpf Negare il caricamento di programmi bpf potenzialmente persistenti nel kernel, già controllato da CAP_SYS_ADMIN.
clock_adjtime L'ora e la data non sono spazi dei nomi. Gestito anche da CAP_SYS_TIME.
clock_settime L'ora e la data non sono spazi dei nomi. Gestito anche da CAP_SYS_TIME.
clone Negare la clonazione di nuovi spazi dei nomi. Anche gestito da flag CAP_SYS_ADMIN for CLONE_*, ad eccezione di CLONE_NEWUSER.
create_module Nega manipolazione e funzioni sui moduli del kernel. Obsoleto. Gestito anche da CAP_SYS_MODULE.
delete_module Nega manipolazione e funzioni sui moduli del kernel. Gestito anche da CAP_SYS_MODULE.
finit_module Nega manipolazione e funzioni sui moduli del kernel. Gestito anche da CAP_SYS_MODULE.
get_kernel_syms Nega il recupero dei simboli del kernel e del modulo esportati. Obsoleto.
get_mempolicy Syscall che modifica le impostazioni di memoria del kernel e NUMA. Già controllato da CAP_SYS_NICE.
init_module Nega manipolazione e funzioni sui moduli del kernel. Gestito anche da CAP_SYS_MODULE.
ioperm Impedire ai contenitori di modificare i livelli dei privilegi di I/O del kernel. Già controllato da CAP_SYS_RAWIO.
iopl Impedire ai contenitori di modificare i livelli dei privilegi di I/O del kernel. Già controllato da CAP_SYS_RAWIO.
kcmp Limitare le funzionalità di ispezione dei processi, già bloccate eliminando CAP_SYS_PTRACE.
kexec_file_load Famiglia syscall di kexec_load che fa la stessa cosa, argomenti leggermente diversi. Gestito anche da CAP_SYS_BOOT.
kexec_load Negare il caricamento di un nuovo kernel per un'esecuzione successiva. Gestito anche da CAP_SYS_BOOT.
keyctl Impedire ai contenitori di usare il keyring del kernel, che non è spazio dei nomi.
lookup_dcookie Traccia/profilatura syscall, che potrebbe causare perdite di informazioni sull'host. Gestito anche da CAP_SYS_ADMIN.
mbind Syscall che modifica le impostazioni di memoria del kernel e NUMA. Già controllato da CAP_SYS_NICE.
mount Negare montaggio, già gestito da CAP_SYS_ADMIN.
move_pages Syscall che modifica le impostazioni di memoria del kernel e NUMA.
nfsservctl Negare l'interazione con il daemon nfs del kernel. Obsoleto a partire da Linux 3.1.
open_by_handle_at Causa di un'interruzione del contenitore precedente. Gestito anche da CAP_DAC_READ_SEARCH.
perf_event_open Traccia/profilatura syscall, che potrebbe causare perdite di informazioni sull'host.
personality Impedire al contenitore di abilitare l'emulazione BSD. Non intrinsecamente pericoloso, ma scarsamente testato, potenziale per vulns del kernel.
pivot_root Negare pivot_root, deve essere un'operazione con privilegi.
process_vm_readv Limitare le funzionalità di ispezione dei processi, già bloccate eliminando CAP_SYS_PTRACE.
process_vm_writev Limitare le funzionalità di ispezione dei processi, già bloccate eliminando CAP_SYS_PTRACE.
ptrace Traccia/profilatura syscall. Bloccato nelle versioni del kernel Linux precedenti a 4.8 per evitare il bypass seccomp. I processi arbitrari di traccia/profilatura sono già bloccati eliminando CAP_SYS_PTRACE, perché potrebbero perdere informazioni sull'host.
query_module Nega manipolazione e funzioni sui moduli del kernel. Obsoleto.
quotactl Quota di syscall che potrebbe consentire ai contenitori di disabilitare i propri limiti di risorse o di elaborare la contabilità. Gestito anche da CAP_SYS_ADMIN.
reboot Non consentire ai contenitori di riavviare l'host. Gestito anche da CAP_SYS_BOOT.
request_key Impedire ai contenitori di usare il keyring del kernel, che non è spazio dei nomi.
set_mempolicy Syscall che modifica le impostazioni di memoria del kernel e NUMA. Già controllato da CAP_SYS_NICE.
setns Negare l'associazione di un thread a uno spazio dei nomi. Gestito anche da CAP_SYS_ADMIN.
settimeofday L'ora e la data non sono spazi dei nomi. Gestito anche da CAP_SYS_TIME.
stime L'ora e la data non sono spazi dei nomi. Gestito anche da CAP_SYS_TIME.
swapon Negare avvio/arresto dello scambio in file/dispositivo. Gestito anche da CAP_SYS_ADMIN.
swapoff Negare avvio/arresto dello scambio in file/dispositivo. Gestito anche da CAP_SYS_ADMIN.
sysfs Syscall obsoleto.
_sysctl Obsoleto, sostituito da /proc/sys.
umount Deve essere un'operazione con privilegi. Gestito anche da CAP_SYS_ADMIN.
umount2 Deve essere un'operazione con privilegi. Gestito anche da CAP_SYS_ADMIN.
unshare Negare la clonazione di nuovi spazi dei nomi per i processi. Gestito anche da CAP_SYS_ADMIN, ad eccezione di unshare --user.
uselib Syscall precedente correlata alle librerie condivise, non utilizzata per molto tempo.
userfaultfd Gestione dell’errore di pagina nello spazio utente, in gran parte necessaria per la migrazione dei processi.
ustat Syscall obsoleto.
vm86 Nella macchina virtuale in modalità reale x86 del kernel. Gestito anche da CAP_SYS_ADMIN.
vm86old Nella macchina virtuale in modalità reale x86 del kernel. Gestito anche da CAP_SYS_ADMIN.

Passaggi successivi

Per le procedure consigliate associate, vedere Procedure consigliate per la sicurezza e gli aggiornamenti del cluster nel servizio Azure Kubernetes e Procedure consigliate per la sicurezza dei pod nel servizio Azure Kubernetes.

  • Last updated on