Informazioni su seccomp in GKE

Questa pagina fornisce informazioni sulla modalità di computing sicuro (seccomp) di Linux in Google Kubernetes Engine (GKE). Utilizza queste informazioni per capire quali azioni possono eseguire le tue applicazioni containerizzate sulla macchina virtuale (VM) host che supporta i tuoi nodi.

Questa pagina è rivolta agli esperti di sicurezza che utilizzano seccomp nell'ambito della strategia di sicurezza della loro 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 utente e attività comuni di GKE Enterprise.

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 ottimizzato per i container con il runtime del 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 il profilo seccomp predefinito o un profilo seccomp personalizzato ai tuoi workload.

Il profilo seccomp containerd predefinito fornisce un'implementazione di base della sicurezza, 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 di Linux

I processi non root eseguiti 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 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 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 container.

Inoltre, è stato negato perché la funzionalità CAP_SYS_ADMIN è stata eliminata.
bpf

Limita la creazione di programmi eBPF nel kernel da parte dei processi, il che può portare all'escalation dei privilegi sul nodo. Ad esempio, CVE-2021-3490 utilizzava la chiamata di sistema bpf. Inoltre, è stato negato 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 ha utilizzato la syscall unshare. Inoltre, è stato negato 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. Negato anche perché le funzionalità CAP_DAC_READ_SEARCH e CAP_SYS_ADMIN sono state eliminate.

Come utilizzare seccomp in GKE

Nei cluster Autopilot, GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i tuoi carichi di lavoro. Non sono necessarie ulteriori azioni. I tentativi di effettuare chiamate di sistema 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.

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 effettuare una chiamata di sistema che viola il profilo seccomp predefinito del runtime, il pod o il workload potrebbe avere un comportamento imprevisto. Ad esempio, un pod che esegue una chiamata di sistema con restrizioni durante l'avvio non verrà avviato. Se un'applicazione tenta di effettuare una chiamata di sistema con restrizioni durante l'esecuzione del pod, potresti notare errori nel container. La gravità di una chiamata di sistema non riuscita dipende dal modo in cui 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. Questa procedura richiede l'accesso al file system sul nodo. Per un tutorial su come caricare e utilizzare profili seccomp personalizzati, consulta l'articolo Limitare le chiamate di sistema di un container con seccomp.

Passaggi successivi