Informazioni su seccomp in GKE

Questa pagina fornisce informazioni sulla modalità di computing sicuro (seccomp) di Linux in Google Kubernetes Engine (GKE). Usa queste informazioni per capire quali azioni le tue applicazioni containerizzate possono essere eseguite sulla macchina virtuale (VM) host che esegue il backup dei nodi.

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. Indica se GKE applica il profilo seccomp predefinito per dipende dalla modalità cluster che utilizzi, come segue:

  • Autopilot (consigliato): GKE applica automaticamente il profilo seccomp predefinito di containerd a tutti i carichi di lavoro.
  • Standard: GKE non applica il profilo seccomp predefinito di containerd automaticamente 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 containerd predefinito fornisce una protezione di base mentre mantenendo la compatibilità con la maggior parte dei carichi di lavoro. Il profilo seccomp completo la definizione di containerd è disponibile GitHub.

Funzionalità e chiamate di sistema Linux

I processi non root in esecuzione su sistemi Linux potrebbero richiedere privilegi specifici per eseguire azioni come l'utente root. Linux utilizza le funzionalità 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 non effettui correttamente una specifica chiamata di sistema, il processo deve avere privilegi concessi da una capacità.

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

Chiamate di sistema negate nel profilo Secure GKE predefinito

Il profilo seccomp predefinito di containerd blocca tutte le chiamate di sistema e poi selettivamente consente chiamate di sistema specifiche, alcune delle quali dipendono dall'architettura della CPU alla VM del nodo e alla 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:

Chiamate di sistema negate
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

Impediscono ai processi di creare programmi eBPF nel kernel, che può portare all'escalation dei privilegi sul nodo. Ad esempio, CVE-2021-3490 ha utilizzato la chiamata di sistema bpf.

Negato anche perché Funzionalità di CAP_SYS_ADMIN viene eliminato.
clone, clone3, unshare

Impedisci ai processi di creare nuovi processi in nuovi spazi dei nomi che potrebbe trovarsi al di fuori dello spazio dei nomi limitato del container. 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.

Negato anche perché Funzionalità di CAP_SYS_BOOT viene eliminato.
open_by_handle_at, name_to_handle_at

Limitare l'accesso ai file esterni al contenitore. Queste chiamate di sistema sono stati usati in uno dei primi Exploit di container escape Docker.

Negato anche perché Funzionalità di CAP_DAC_READ_SEARCH e ai CAP_SYS_ADMIN funzionalità vengono eliminati.

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é 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 manualmente un profilo seccomp impostando il pod o il container Contesto di sicurezza utilizzando il campo spec.securityContext.seccompProfile nella specifica del pod, come nell'esempio che segue. 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 valore di runtime predefinito profilo:

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 syscall limitato mentre il pod è in esecuzione, potresti notare errori nella containerizzato. La gravità di una chiamata di sistema non riuscita dipende dal modo in cui l'applicazione e gestire 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 restrittive), puoi applicare un profilo seccomp personalizzato ai pod in di 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