Sobre o seccomp no GKE

Autopilot Standard

Nesta página, você encontra informações sobre o modo de computação segura (seccomp) do Linux no Google Kubernetes Engine (GKE). Use essas informações para entender quais ações seus aplicativos conteinerizados podem executar na máquina virtual (VM) do host que fornece suporte aos nós.

O que é o seccomp?

O modo de computação seguro, ou seccomp, é um recurso de segurança no Linux que permite restringir as chamadas do sistema (syscalls) que um processo pode fazer para o kernel do Linux.

Por padrão, os nós do GKE usam o sistema operacional Container-Optimized OS com o ambiente de execução do contêiner containerd. O containerd protege o kernel do Linux limitando os recursos do Linux permitidos a uma lista padrão, e é possível limitar ainda mais as chamadas do sistema permitidas com um perfil seccomp. O containerd tem um perfil seccomp padrão disponível. A aplicação do perfil seccomp padrão pelo GKE depende do modo de cluster que você usa, da seguinte maneira:

Autopilot (recomendado): o GKE aplica automaticamente o perfil seccomp padrão do containerd a todas as cargas de trabalho.
Standard: o GKE não aplica automaticamente o perfil seccomp padrão do containerd a todas as cargas de trabalho. Recomendamos que você aplique o perfil seccomp padrão ou um perfil seccomp personalizado às cargas de trabalho.

O perfil padrão containerd seccomp oferece aumento da proteção de valor de referência, mantendo a compatibilidade com a maioria das cargas de trabalho. A definição completa do perfil de seccomp para o containerd está disponível no GitHub.

Recursos e chamadas do sistema Linux

Processos não raiz executados em sistemas Linux podem exigir privilégios específicos para executar ações como o usuário raiz. O Linux usa recursos para dividir os privilégios disponíveis em grupos para que um processo não raiz possa executar uma ação específica sem receber todos os privilégios. Para que um processo faça uma chamada de sistema específica, ele precisa ter os privilégios correspondentes concedidos por um recurso.

Para uma lista de todos os recursos do Linux, consulte recursos.

Chamadas de sistema negadas no perfil seccomp padrão do GKE

O perfil seccomp padrão containerd bloqueia todas as chamadas do sistema e, em seguida, permite seletivamente chamadas do sistema. Algumas delas dependem da arquitetura de CPU da VM do nó e da versão do kernel. A variável syscalls na função DefaultProfile lista as chamadas do sistema permitidas para todas as arquiteturas.

O perfil seccomp padrão bloqueia chamadas de sistema que podem ser usadas para ignorar limites de isolamento de contêineres e permitir acesso privilegiado ao nó ou a outros contêineres. A tabela a seguir descreve algumas das chamadas do sistema importantes que o perfil seccomp padrão nega:

Chamadas do sistema negadas
`mount`, `umount`, `umount2`, `fsmount`, `mount_setattr`	Restringem processos de acessar ou manipular o sistema de arquivos do nó fora dos limites do contêiner. Também negadas porque o recurso `CAP_SYS_ADMIN` foi descartado.
`bpf`	Restringem processos de criar programas eBPF no kernel, o que pode levar ao escalonamento de privilégios no nó. Por exemplo, CVE-2021-3490 usou a chamada de sistema `bpf`. Também negadas porque o recurso `CAP_SYS_ADMIN` foi descartado.
`clone`, `clone3`, `unshare`	Restringem processos de criar novos processos em novos namespaces que possam estar fora do namespace restrito do contêiner. Esses novos processos podem ter permissões e recursos elevados. Por exemplo, CVE-2022-0185 usou a chamada de sistema `unshare`. Também negadas porque o recurso `CAP_SYS_ADMIN` foi descartado.
`reboot`	Restringem processos de reinicializar o nó. Também negadas porque o recurso `CAP_SYS_BOOT` foi descartado.
`open_by_handle_at`, `name_to_handle_at`	Restringem o acesso a arquivos fora do contêiner. Essas chamadas do sistema foram usadas em uma das primeiras explorações de escape de contêiner do Docker. Também negadas porque o recurso `CAP_DAC_READ_SEARCH` e o recurso `CAP_SYS_ADMIN` são descartados.

Como usar o seccomp no GKE

Nos clusters do Autopilot, o GKE aplica automaticamente o perfil seccomp padrão containerd a todas as suas cargas de trabalho. Você não precisa fazer mais nada. As tentativas de fazer chamadas do sistema restritas falham. O Autopilot não permite perfis seccomp personalizados porque o GKE gerencia os nós.

Nos clusters padrão, é necessário aplicar manualmente um perfil seccomp. O GKE não aplica um perfil para você.

Ativar o seccomp em clusters padrão

Aplique um perfil seccomp manualmente definindo o contexto de segurança do pod ou contêiner usando o campo spec.securityContext.seccompProfile na especificação do pod, como no exemplo a seguir. Recomendamos que você use um perfil seccomp para suas cargas de trabalho, a menos que seu caso de uso exija o uso de chamadas do sistema restritas. Os dois tipos de seccompProfile compatíveis são os seguintes:

RuntimeDefault: o perfil padrão especificado pelo ambiente de execução containerd.
Localhost: uma definição do perfil personalizado.

O manifesto de exemplo a seguir define o perfil seccomp como o perfil padrão do ambiente de execução:

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 você implanta esse manifesto, se um contêiner no pod tentar fazer uma chamada de sistema que viole o perfil seccomp padrão do ambiente de execução, o pod ou a carga de trabalho poderão ter um comportamento inesperado. Por exemplo, um pod que faz uma chamada do sistema restrita durante a inicialização falha. Se um aplicativo tentar fazer uma chamada do sistema restrita enquanto o pod estiver em execução, talvez você encontre erros no contêiner. A gravidade de uma chamada de sistema com falha depende de como o aplicativo processa os erros.

Usar um perfil seccomp personalizado em clusters padrão

Se o perfil seccomp padrão do ambiente de execução for muito restritivo para seu aplicativo (ou não for restritivo o suficiente), você poderá aplicar um perfil seccomp personalizado aos pods em clusters padrão. Esse processo requer acesso ao sistema de arquivos no nó. Para ver um tutorial sobre como carregar e usar perfis seccomp personalizados, consulte Como restringir as chamadas do sistema de um contêiner com o seccomp.