Informazioni su seccomp in GKE

Questa pagina fornisce informazioni sulla modalità di calcolo sicuro (seccomp) di Linux in Google Kubernetes Engine (GKE). Utilizza queste informazioni per capire quali azioni possono essere eseguite dalle tue applicazioni containerizzate sulla macchina virtuale (VM) host di supporto dei tuoi nodi.

Questa pagina è rivolta agli esperti di sicurezza che utilizzano seccomp nell'ambito della strategia di sicurezza della loro organizzazione e vogliono capire in che modo GKE interagisce con i profili seccomp. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti 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 di 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. Per containerd è disponibile un profilo seccomp predefinito. 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 carichi di lavoro.

Il profilo seccomp di containerd predefinito fornisce un'applicazione di misure di sicurezza 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 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 capabilities per suddividere i privilegi disponibili in gruppi, in modo che un processo non root possa eseguire un'azione specifica senza che vengano concessi tutti i privilegi. Affinché un processo possa eseguire 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 capabilities.

Chiamate di sistema rifiutate nel profilo seccomp GKE predefinito

Il profilo seccomp predefinito di containerd blocca tutte le chiamate di sistema e poi consente in modo selettivo 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 confini 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 vengono negate dal profilo seccomp predefinito:

Chiamata di sistema rifiutata
mount, umount, umount2, fsmount, mount_setattr

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

Inoltre, la richiesta è stata rifiutata perché la funzionalità CAP_SYS_ADMIN è stata ritirata.
bpf

Impedire ai processi di creare programmi eBPF nel kernel, il che può portare a un'escalation dei privilegi sul nodo. Ad esempio, CVE-2021-3490 utilizzava la chiamata di sistema bpf. Inoltre, la richiesta è stata rifiutata perché la funzionalità CAP_SYS_ADMIN è stata ritirata.
clone, clone3, unshare

Impedire ai processi di creare nuovi processi in nuovi spazi dei nomi che potrebbero essere esterni allo spazio dei nomi con limitazioni del contenitore. Queste nuove procedure potrebbero avere autorizzazioni e funzionalità elevate. Ad esempio, CVE-2022-0185 ha utilizzato la chiamata di sistema unshare. Inoltre, la richiesta è stata rifiutata perché la funzionalità CAP_SYS_ADMIN è stata ritirata.
reboot

Impedisci ai processi di riavviare il nodo.

Rifiutato perché la funzionalità CAP_SYS_BOOT non è supportata.
open_by_handle_at, name_to_handle_at

Limitare l'accesso ai file esterni al contenitore. Questi syscalls sono stati utilizzati in uno dei primi exploit di container escape Docker. Inoltre, la richiesta è stata rifiutata perché la funzionalità CAP_DAC_READ_SEARCH e la funzionalità CAP_SYS_ADMIN vengono ignorate.

Come utilizzare seccomp in GKE

Nei cluster Autopilot, GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i carichi di lavoro. Non sono necessarie altre azioni. I tentativi di eseguire chiamate di sistema limitate non vanno a buon fine. Autopilot non consente profili seccomp personalizzati perché i nodi sono gestiti da GKE.

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

Attivare 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 chiamate di sistema limitate. I due tipi di seccompProfile supportati sono i seguenti:

Il manifest di esempio seguente 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 eseguire una chiamata di sistema che viola il profilo seccomp predefinito del runtime, il pod o il carico di lavoro potrebbe presentare un comportamento imprevisto. Ad esempio, un pod che esegue una chiamata di sistema limitata durante l'avvio non riesce ad avviarsi. Se un'applicazione tenta di eseguire una chiamata di sistema limitata mentre il pod è in esecuzione, potresti notare errori nel contenitore. 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 Limitare le chiamate di sistema di un contenitore con seccomp.

Passaggi successivi