Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni su seccomp in GKE

Autopilot Standard

Questa pagina fornisce informazioni sulla modalità di secure computing Linux (seccomp) 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.

Che cos'è seccomp?

La modalità di computing sicura, o seccomp, è una funzionalità di sicurezza di Linux che consente Puoi limitare le chiamate di sistema (syscall) che un processo può effettuare verso Linux in un kernel.

Per impostazione predefinita, i nodi GKE utilizzano il sistema operativo Container-Optimized OS sistema operativo con il runtime del container container. containerd protegge il kernel Linux limitando il numero funzionalità a un elenco predefinito. Puoi limitare ulteriormente le syscall con un profilo seccomp. containerd ha un profilo seccomp predefinito disponibili. 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. 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 usa le funzionalità per dividere privilegi disponibili in gruppi, in modo che un processo non root possa eseguire un'azione specifica senza disporre di 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à Linux, consulta abilità di Google.

Chiamate di sistema rifiutate nel profilo seccomp 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 bypassare il container limiti di isolamento e consentire l'accesso privilegiato al nodo o ad altre containerizzati. Nella tabella seguente vengono descritte alcune delle syscall più significative che il profilo seccomp predefinito nega:

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 trovarsi al di fuori dello spazio dei nomi con limitazioni del contenitore. Queste nuove potrebbero avere autorizzazioni e capacità elevate. Ad esempio: CVE-2022-0185 è stata utilizzata la chiamata di sistema `unshare`. Negato anche perché Funzionalità di `CAP_SYS_ADMIN` viene eliminato.
`reboot`	Limita il riavvio del nodo da parte dei processi. Negato anche perché Funzionalità di `CAP_SYS_BOOT` viene eliminato.
`open_by_handle_at`, `name_to_handle_at`	Limita l'accesso ai file all'esterno del 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 per tutti i tuoi carichi di lavoro. Non sono necessarie altre azioni. I tentativi di rendere le chiamate di sistema limitate non hanno esito positivo. 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.

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:

RuntimeDefault: il profilo predefinito specificato dal runtime containerd.
Localhost: una definizione del profilo personalizzato.

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.

Usa 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 a Limita le chiamate di sistema di un container con seccomp.