Informazioni su seccomp in GKE

Questo documento descrive la modalità di calcolo sicuro (seccomp) di Linux in Google Kubernetes Engine (GKE). Questo documento presuppone che tu conosca le seguenti informazioni:

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

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

Che cos'è seccomp?

La modalità di calcolo sicuro, o seccomp, è una funzionalità di sicurezza in 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 syscall consentite con un profilo seccomp. containerd ha un profilo seccomp predefinito disponibile. Se GKE applica il profilo seccomp predefinito dipende dalla modalità del cluster che utilizzi, come indicato di seguito:

  • 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 il profilo seccomp predefinito o un profilo seccomp personalizzato ai tuoi carichi di lavoro.

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

Funzionalità e syscall di 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 possa effettuare correttamente una syscall specifica, deve disporre dei privilegi corrispondenti concessi da una funzionalità.

Per un elenco di tutte le funzionalità di Linux, consulta la pagina relativa alle funzionalità .

Syscall negate nel profilo seccomp GKE predefinito

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

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

Syscall negate
mount, umount, umount2, fsmount, mount_setattr

Impedisci ai processi di accedere o manipolare il file system del nodo al di fuori dei limiti del container.

Negato anche perché la CAP_SYS_ADMIN funzionalità viene 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 CAP_SYS_ADMIN funzionalità viene 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 unshare syscall. Negato anche perché la CAP_SYS_ADMIN funzionalità viene eliminata.
reboot

Impedisci ai processi di riavviare il nodo.

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

Limita l'accesso ai file al di fuori del container. Queste syscall sono state utilizzate in uno dei primi exploit di container escape di Docker. Negato anche perché la CAP_DAC_READ_SEARCH funzionalità e la CAP_SYS_ADMIN funzionalità vengono eliminate.

Come utilizzare seccomp in GKE

Nei cluster Autopilot, GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i carichi di lavoro. Non è richiesta alcuna ulteriore azione. I tentativi di effettuare syscall con limitazioni 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.

Abilitare seccomp nei cluster standard

Applica manualmente un profilo seccomp impostando il contesto di sicurezza del pod o del container Security Context 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 syscall con limitazioni. I due tipi di seccompProfile supportati sono i seguenti:

Il seguente manifest di esempio imposta il profilo seccomp sul profilo predefinito del 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 syscall che viola il profilo seccomp predefinito del runtime, il pod o il carico di lavoro potrebbero avere un comportamento imprevisto. Ad esempio, un pod che effettua una syscall con limitazioni durante l'avvio non verrà avviato. Se un'applicazione tenta di effettuare una syscall con limitazioni mentre il pod è in esecuzione, 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 del runtime è troppo restrittivo per la tua applicazione (o non abbastanza restrittivo), puoi applicare un profilo seccomp personalizzato ai pod nei cluster standard. Questa procedura richiede l'accesso al file system sul nodo. Per un tutorial su come caricare e utilizzare i profili seccomp personalizzati, consulta il documento Limitare le syscall di un container con seccomp.

Passaggi successivi