Esta página fornece informações sobre o modo de computação segura (seccomp) do Linux no Google Kubernetes Engine (GKE). Use estas informações para compreender que ações as suas aplicações contentorizadas podem realizar na máquina virtual (VM) anfitriã que suporta os seus nós.
Esta página destina-se a especialistas de segurança que usam o seccomp como parte da estratégia de segurança da respetiva organização e querem compreender como o GKE interage com os perfis do seccomp. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud
O que é o seccomp?
O modo de computação seguro, ou seccomp, é uma capacidade de segurança no Linux que lhe permite restringir as chamadas do sistema (syscalls) que um processo pode fazer ao kernel do Linux.
Por predefinição, os nós do GKE usam o sistema operativo Container-Optimized OS com o runtime de contentores containerd. O containerd protege o kernel do Linux limitando as capacidades do Linux permitidas a uma lista predefinida, e pode limitar ainda mais as chamadas de sistema permitidas com um perfil seccomp. O containerd tem um perfil seccomp predefinido disponível. Se o GKE aplica o perfil seccomp predefinido por si, depende do modo do cluster que usa, da seguinte forma:
- Autopilot (recomendado): o GKE aplica o perfil seccomp predefinido do containerd a todas as cargas de trabalho automaticamente.
- Padrão: O GKE não aplica o perfil seccomp predefinido do containerd a todas as cargas de trabalho automaticamente. Recomendamos que aplique o perfil seccomp predefinido ou um perfil seccomp personalizado às suas cargas de trabalho.
O perfil seccomp do containerd predefinido oferece uma proteção básica, ao mesmo tempo que mantém a compatibilidade com a maioria das cargas de trabalho. A definição completa do perfil seccomp para o containerd está disponível no GitHub.
Capacidades e chamadas de sistema do Linux
Os processos não root executados em sistemas Linux podem exigir privilégios específicos para realizar ações como utilizador root. O Linux usa capacidades para dividir os privilégios disponíveis em grupos, para que um processo não root possa realizar uma ação específica sem lhe serem concedidos todos os privilégios. Para que um processo faça uma chamada de sistema específica com êxito, o processo tem de ter os privilégios correspondentes concedidos por uma capacidade.
Para ver uma lista de todas as capacidades do Linux, consulte as capacidades .
Syscalls recusados no perfil seccomp do GKE predefinido
O perfil seccomp predefinido do containerd bloqueia todas as chamadas de sistema e, em seguida, permite seletivamente chamadas de sistema específicas, algumas das quais dependem da arquitetura da CPU da VM do nó e da versão do kernel. A variável syscalls na função DefaultProfile lista as chamadas de sistema permitidas para todas as arquiteturas.
O perfil seccomp predefinido bloqueia as chamadas de sistema que podem ser usadas para contornar os limites de isolamento do contentor e permitir o acesso privilegiado ao nó ou a outros contentores. A tabela seguinte descreve algumas das chamadas de sistema significativas que o perfil seccomp predefinido nega:
| Syscalls recusados | |
|---|---|
mount, umount, umount2,
fsmount, mount_setattr |
Restrinja os processos de acesso ou manipulação do sistema de ficheiros do nó fora dos limites do contentor. Também recusado porque a capacidade |
bpf |
Restringir os processos de criação de programas eBPF no kernel, o que pode levar a uma escalada de privilégios no nó. Por exemplo,
CVE-2021-3490
usou o syscall |
clone, clone3, unshare |
Restringir processos de criação de novos processos em novos espaços de nomes
que possam estar fora do espaço de nomes restrito do contentor. Estes novos processos podem ter autorizações e capacidades elevadas. Por exemplo,
CVE-2022-0185
usou o syscall |
reboot |
Restrinja os processos de reinício do nó. Recusado porque a capacidade |
open_by_handle_at, name_to_handle_at |
Restringir o acesso a ficheiros fora do contentor. Estas chamadas de sistema foram usadas num dos primeiros exploits de fuga de contentores do Docker. Também negado porque a capacidade |
Como usar o seccomp no GKE
Nos clusters do Autopilot, o GKE aplica automaticamente o perfil seccomp predefinido do containerd a todas as suas cargas de trabalho. Não é necessária nenhuma ação adicional. As tentativas de fazer chamadas de sistema restritas falham. O Autopilot não permite perfis seccomp personalizados porque o GKE gere os nós.
Nos clusters padrão, tem de aplicar manualmente um perfil seccomp. O GKE não aplica um perfil por si.
Ative o seccomp em clusters padrão
Aplique um perfil seccomp manualmente definindo o contexto de segurança do pod ou do contentor usando o campo spec.securityContext.seccompProfile na especificação do pod, como no exemplo seguinte. Recomendamos vivamente que use um perfil seccomp para as suas cargas de trabalho, a menos que o seu exemplo de utilização exija a utilização de quaisquer chamadas de sistema restritas. Os dois tipos de seccompProfile suportados são os seguintes:
RuntimeDefault: o perfil predefinido especificado pelo tempo de execução do containerd.Localhost: uma definição de perfil personalizada.
O exemplo de manifesto seguinte define o perfil seccomp para o perfil predefinido de tempo 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 implementa este manifesto, se um contentor no pod tentar fazer uma chamada de sistema que viole o perfil seccomp predefinido do tempo de execução, o pod ou a carga de trabalho podem ter um comportamento inesperado. Por exemplo, um pod que faça uma chamada de sistema restrita durante o arranque não é iniciado. Se uma aplicação tentar fazer uma chamada de sistema restrita enquanto o pod estiver em execução, pode notar erros no contentor. A gravidade de uma chamada de sistema falhada depende da forma como a aplicação processa os erros.
Use um perfil seccomp personalizado em clusters padrão
Se o perfil seccomp predefinido do tempo de execução for demasiado restritivo para a sua aplicação (ou não for suficientemente restritivo), pode aplicar um perfil seccomp personalizado aos pods em clusters padrão. Este processo requer acesso ao sistema de ficheiros no nó. Para ver um tutorial sobre como carregar e usar perfis seccomp personalizados, consulte o artigo Restrinja as chamadas do sistema de um contentor com seccomp.
O que se segue?
- Use o PodSecurityAdmission para aplicar políticas predefinidas ao nível do pod
- Use o serviço de políticas da organização para definir políticas ao nível do projeto ou da organização