Informazioni su seccomp in GKE

Autopilot Standard

Questa pagina fornisce informazioni sulla modalità di secure computing (seccomp) di Linux in Google Kubernetes Engine (GKE). Utilizza queste informazioni per comprendere quali azioni possono essere eseguite dalle applicazioni containerizzate sulla macchina virtuale host (VM) che supporta i nodi.

Che cos'è seccomp?

La modalità di elaborazione sicura, o seccomp, è una funzionalità di sicurezza di Linux che consente di limitare le chiamate di sistema (chiamate di sistema) che un processo può effettuare al kernel Linux.

Per impostazione predefinita, i nodi GKE utilizzano il sistema operativo Container-Optimized OS con il runtime container containerd. containerd protegge il kernel Linux limitando le funzionalità consentite di Linux a un elenco predefinito. Inoltre, puoi limitare ulteriormente le chiamate di sistema consentite con un profilo seccomp. containerd ha un profilo seccomp predefinito disponibile. L'applicazione del profilo seccomp predefinito da parte di GKE dipende dalla modalità cluster utilizzata, come segue:

Autopilot (opzione consigliata): GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i carichi di lavoro.
Standard: GKE non applica automaticamente il profilo seccomp predefinito di containerd a tutti i carichi di lavoro. Ti consigliamo di applicare ai tuoi carichi di lavoro il profilo seccomp predefinito o un profilo seccomp personalizzato.

Il profilo seccomp containerd predefinito fornisce una protezione di riferimento, mantenendo al contempo la compatibilità con la maggior parte dei carichi di lavoro. La definizione completa del profilo seccomp per containerd è disponibile su GitHub.

Funzionalità di Linux e chiamate di sistema

I processi non root in esecuzione su sistemi Linux potrebbero richiedere privilegi specifici per eseguire azioni come utente root. Linux utilizza le capabilities per suddividere i privilegi disponibili in gruppi, in modo che un processo non radice possa eseguire un'azione specifica senza che vengano concessi tutti i privilegi. Affinché un processo effettui correttamente una chiamata di sistema specifica, deve disporre dei privilegi corrispondenti concessi da una funzionalità.

Per un elenco di tutte le funzionalità di Linux, consulta la sezione capabilities.

Chiamate di sistema negate nel profilo di sicurezza GKE predefinito

Il profilo seccomp predefinito di containerd blocca tutte le chiamate di sistema e consente selettivamente chiamate di sistema specifiche, alcune delle quali dipendono dall'architettura della CPU della VM del nodo e dalla versione del kernel. La variabile syscalls nella funzione DefaultProfile elenca le chiamate di sistema consentite per tutte le architetture.

Il profilo seccomp predefinito blocca le chiamate di sistema che possono essere utilizzate per aggirare i limiti di isolamento dei container e consentire l'accesso con privilegi al nodo o ad altri container. La seguente tabella descrive alcune delle chiamate di sistema significative negate dal profilo seccomp predefinito:

Chiamate di sistema negate
`mount`, `umount`, `umount2`, `fsmount` e `mount_setattr`	Impedisce ai processi di accedere al file system del nodo o manipolarlo al di fuori dei confini del container. Rifiutata anche perché la funzionalità `CAP_SYS_ADMIN` è stata eliminata.
`bpf`	Limita i processi relativi alla creazione di programmi eBPF nel kernel, il che può portare all'escalation dei privilegi sul nodo. Ad esempio, CVE-2021-3490 ha utilizzato la chiamata di sistema `bpf`. Rifiutata anche perché la funzionalità `CAP_SYS_ADMIN` è stata eliminata.
`clone`, `clone3`, `unshare`	Limita la creazione di nuovi processi in nuovi spazi dei nomi che potrebbero essere al di fuori dello spazio dei nomi limitato del container. Questi nuovi processi potrebbero avere autorizzazioni e funzionalità elevate. Ad esempio, CVE-2022-0185 ha utilizzato la chiamata di sistema `unshare`. Rifiutata anche perché la funzionalità `CAP_SYS_ADMIN` è stata eliminata.
`reboot`	Limita i processi relativi al riavvio del nodo. Rifiutata anche perché la funzionalità `CAP_SYS_BOOT` è stata eliminata.
`open_by_handle_at`, `name_to_handle_at`	Limita l'accesso ai file all'esterno del contenitore. Queste chiamate di sistema sono state utilizzate in uno dei primi exploit di container escape Docker. Rifiutata anche perché la funzionalità `CAP_DAC_READ_SEARCH` e la funzionalità `CAP_SYS_ADMIN` vengono eliminate.

Come utilizzare seccomp in GKE

Nei cluster Autopilot, GKE applica automaticamente il profilo seccomp predefinito del containerd a tutti i carichi di lavoro. Non sono necessarie ulteriori azioni. I tentativi di effettuare chiamate di sistema limitate hanno esito negativo. Autopilot non consente i profili seccomp personalizzati perché GKE gestisce i nodi.

Nei cluster standard, devi applicare manualmente un profilo seccomp. GKE non applica un profilo al posto tuo.

Abilita seccomp nei cluster standard

Applica un profilo seccomp manualmente impostando il contesto di sicurezza del pod o del container utilizzando il campo spec.securityContext.seccompProfile nella specifica del pod, come nell'esempio seguente. Ti consigliamo vivamente di utilizzare un profilo seccomp per i carichi di lavoro, a meno che il tuo caso d'uso non richieda l'utilizzo di chiamate di sistema limitate. I due tipi di seccompProfile supportati sono i seguenti:

RuntimeDefault: il profilo predefinito specificato dal runtime containerd.
Localhost: una definizione di profilo personalizzata.

Il seguente manifest di esempio imposta il profilo seccomp sul profilo predefinito di runtime:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: default-pod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default-pod
  template:
    metadata:
      labels:
        app: default-pod
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: seccomp-test
        image: nginx

Quando esegui il deployment di questo manifest, se un container nel pod tenta di effettuare una chiamata di sistema che viola il profilo di sicurezza predefinito del runtime, il pod o il carico di lavoro potrebbero riscontrare comportamenti imprevisti. Ad esempio, un pod che effettua una chiamata di sistema limitata durante l'avvio non si avvia. Se un'applicazione tenta di effettuare una chiamata di sistema limitata mentre il pod è in esecuzione, potresti notare errori nel container. La gravità di una chiamata di sistema non riuscita dipende dal modo in cui l'applicazione gestisce gli errori.

Usa un profilo seccomp personalizzato nei cluster Standard

Se il profilo seccomp predefinito di runtime è troppo restrittivo per la tua applicazione (o non abbastanza restrittivo), puoi applicare un profilo seccomp personalizzato ai pod nei cluster Standard. Questo processo richiede l'accesso al file system sul nodo. Per un tutorial su come caricare e utilizzare profili seccomp personalizzati, consulta Limitare le chiamate di sistema di un container con seccomp.