Informazioni su seccomp in GKE

Questo documento descrive la modalità di secure computing (seccomp) di Linux in Google Kubernetes Engine (GKE). Questo documento presuppone che tu conosca quanto segue:

Utilizza le informazioni contenute in questo documento per capire quali azioni possono eseguire le tue applicazioni containerizzate sulla macchina virtuale (VM) host che supporta i tuoi nodi.

Questo documento è rivolto agli esperti di sicurezza che utilizzano seccomp nell'ambito della strategia di sicurezza della propria organizzazione e vogliono capire come GKE interagisce con i profili seccomp. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Che cos'è seccomp?

La modalità di computing sicuro, o seccomp, è una funzionalità di sicurezza di Linux che consente di limitare le chiamate di sistema (syscall) 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à Linux consentite a un elenco predefinito e 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à del cluster utilizzata, come segue:

  • Autopilot (consigliato): 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 workload il profilo seccomp predefinito o un profilo seccomp personalizzato.

Il profilo seccomp predefinito di containerd fornisce un'applicazione di hardening di base mantenendo la compatibilità con la maggior parte dei workload. La definizione completa del profilo seccomp per containerd è disponibile su GitHub.

Funzionalità e chiamate di sistema Linux

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

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

Chiamate di sistema negate nel profilo seccomp GKE predefinito

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

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

Chiamate di sistema negate
mount, umount, umount2, fsmount, mount_setattr

Limitare l'accesso o la manipolazione del file system del nodo da parte dei processi al di fuori dei limiti del contenitore.

Negato anche perché la funzionalità CAP_SYS_ADMIN è stata eliminata.
bpf

Impedisci ai processi di creare programmi eBPF nel kernel, il che può portare all'escalation dei privilegi sul nodo. Ad esempio, CVE-2021-3490 utilizzava la syscall bpf. Negato anche perché la funzionalità CAP_SYS_ADMIN è stata eliminata.
clone, clone3, unshare

Impedisci ai processi di creare nuovi processi in nuovi spazi dei nomi che potrebbero trovarsi al di fuori dello spazio dei nomi con limitazioni del container. Questi nuovi processi potrebbero avere autorizzazioni e funzionalità elevate. Ad esempio, CVE-2022-0185 utilizzava la syscall unshare. Inoltre, è stata negata perché la funzionalità CAP_SYS_ADMIN è stata eliminata.
reboot

Limita i processi dal riavvio del nodo.

Negato perché la funzionalità CAP_SYS_BOOT è stata eliminata.
open_by_handle_at, name_to_handle_at

Limitare l'accesso ai file al di fuori del contenitore. Queste chiamate di sistema sono state utilizzate in uno dei primi exploit di container escape Docker. Anche l'accesso è negato perché la funzionalità CAP_DAC_READ_SEARCH e la funzionalità CAP_SYS_ADMIN sono state rimosse.

Come utilizzare seccomp in GKE

Nei cluster Autopilot, GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i tuoi workload. Non sono necessarie ulteriori azioni. I tentativi di eseguire syscall con restrizioni non vanno a buon fine. Autopilot non consente profili seccomp personalizzati perché GKE gestisce i nodi.

Nei cluster Standard, devi applicare manualmente un profilo seccomp. GKE non applica un profilo per te.

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 tuoi carichi di lavoro, a meno che il tuo caso d'uso non richieda l'utilizzo di syscalls con limitazioni. I due tipi di seccompProfile supportati sono i seguenti:

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 eseguire una syscall che viola il profilo seccomp predefinito del runtime, il pod o il workload potrebbero avere un comportamento imprevisto. Ad esempio, un pod che effettua una syscall limitata durante l'avvio non si avvia. Se un'applicazione tenta di effettuare una chiamata di sistema con limitazioni durante l'esecuzione del pod, potresti notare errori nel container. La gravità di una syscall non riuscita dipende da come l'applicazione gestisce gli errori.

Utilizzare 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.

Passaggi successivi