Seccomp em Kubernetes: 7 coisas que você precisa saber desde o início

Nota perev. : Apresentando a tradução de um artigo por um engenheiro de segurança de aplicativos sênior da empresa britânica ASOS.com. Com ela, ele inicia uma série de publicações sobre como melhorar a segurança no Kubernetes através do uso do seccomp. Se os leitores gostarem da introdução, seguiremos o autor e continuaremos com seus futuros materiais sobre este tópico.



Este artigo é a primeira de uma série de publicações sobre como criar perfis seccomp no espírito do SecDevOps sem recorrer à magia e à bruxaria. Na primeira parte, falarei sobre os conceitos básicos e internos da implementação do seccomp no Kubernetes.

O ecossistema Kubernetes oferece uma ampla variedade de maneiras para garantir a segurança e o isolamento dos contêineres. Este artigo é sobre o Secure Computing Mode, também conhecido como seccomp . Sua essência está nas chamadas do sistema de filtragem disponíveis para execução dos contêineres.

Por que isso é importante? Um contêiner é apenas um processo em execução em uma máquina específica. E ele usa o kernel em pé de igualdade com outros aplicativos. Se os contêineres pudessem fazer chamadas do sistema, muito em breve o malware seria aproveitado para contornar o isolamento do contêiner e afetar outros aplicativos: interceptar informações, alterar configurações do sistema etc.

Os perfis seccomp determinam quais chamadas do sistema devem ser permitidas ou negadas. O tempo de execução do contêiner os ativa durante seu lançamento, para que o kernel possa controlar sua execução. O uso desses perfis permite limitar o vetor de ataque e reduzir os danos se algum programa dentro do contêiner (ou seja, suas dependências ou suas dependências) começar a fazer o que não é permitido.

Compreendendo o básico

O perfil base seccomp inclui três elementos: defaultAction , architectures (ou archMap ) e syscalls :

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp" ], "action": "SCMP_ACT_ALLOW" } ] } 

( medium-basic-seccomp.json )

defaultAction determina o destino padrão de qualquer chamada do sistema não especificada na seção syscalls . Para simplificar a tarefa, focamos em dois valores principais que serão usados:

• SCMP_ACT_ERRNO - bloqueia a execução de uma chamada do sistema,
• SCMP_ACT_ALLOW - permite.

A seção architectures lista as arquiteturas de destino. Isso é importante, pois o próprio filtro, aplicado no nível do kernel, depende dos identificadores de chamadas do sistema, e não dos nomes registrados no perfil. Antes de usar, o tempo de execução do contêiner mapeia-os para identificadores. O ponto é que as chamadas do sistema podem ter IDs completamente diferentes, dependendo da arquitetura do sistema. Por exemplo, a chamada do sistema recvfrom (usada para obter informações de um soquete) possui ID = 64 em sistemas x64 e ID = 517 em x86. Aqui você pode encontrar uma lista de todas as chamadas do sistema para arquiteturas x86-x64.

A seção syscalls lista todas as chamadas do sistema e indica o que fazer com elas. Por exemplo, você pode criar uma lista de permissões definindo defaultAction como SCMP_ACT_ERRNO e atribuir chamadas à seção SCMP_ACT_ALLOW a SCMP_ACT_ALLOW . Assim, você só permite chamadas registradas na seção syscalls e proíbe todas as outras. Para a lista negra, você deve alterar os valores e ações defaultAction para o oposto.

Agora, algumas palavras devem ser ditas sobre as nuances que não são tão óbvias. Observe que as recomendações abaixo vêm do fato de você estar implantando uma linha de aplicativos de negócios no Kubernetes e é importante que eles trabalhem com o mínimo de privilégios.

1. AllowPrivilegeEscalation = false

Há um parâmetro AllowPrivilegeEscalation no securityContext contêiner. Se estiver definido como false , os contêineres começarão com o bit no_new_priv definido como ( on ). O significado desse parâmetro é óbvio no nome: ele não permite que o contêiner inicie novos processos com privilégios maiores do que aqueles que possui.

Um efeito colateral desse parâmetro definido como true (o valor padrão) é que o tempo de execução do contêiner aplica o perfil seccomp no início do processo de inicialização. Portanto, todas as chamadas do sistema necessárias para iniciar os processos internos do tempo de execução (por exemplo, configurando identificadores de usuário / grupo, eliminando alguns recursos) devem ser permitidas no perfil.

O contêiner que executa o echo hi banal echo hi precisará das seguintes permissões:

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "brk", "capget", "capset", "chdir", "close", "execve", "exit_group", "fstat", "fstatfs", "futex", "getdents64", "getppid", "lstat", "mprotect", "nanosleep", "newfstatat", "openat", "prctl", "read", "rt_sigaction", "statfs", "setgid", "setgroups", "setuid", "stat", "uname", "write" ], "action": "SCMP_ACT_ALLOW" } ] } 

( hi-pod-seccomp.json )

... em vez destes:

 { "defaultAction": "SCMP_ACT_ERRNO", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "brk", "close", "execve", "exit_group", "futex", "mprotect", "nanosleep", "stat", "write" ], "action": "SCMP_ACT_ALLOW" } ] } 

( hi-container-seccomp.json )

Mas, novamente, por que isso é um problema? Pessoalmente, eu evitaria colocar na lista branca as seguintes chamadas do sistema (se elas não forem realmente necessárias): capset , set_tid_address , setgid , setgroups e setuid . No entanto, a dificuldade real é que, ao permitir processos sobre os quais você não tem absolutamente nenhum controle, você vincula perfis à implementação do tempo de execução do contêiner. Em outras palavras, um dia você pode encontrar o fato de que, após atualizar o ambiente de tempo de execução do contêiner (por você ou, mais provavelmente, pelo provedor de serviços em nuvem), os contêineres pararão repentinamente.

Dica 1 : execute contêineres com AllowPrivilegeEscaltion=false . Isso reduzirá o tamanho dos perfis seccomp e os tornará menos sensíveis às alterações no tempo de execução do contêiner.

2. Configurando perfis seccomp no nível do contêiner

O perfil seccomp pode ser definido no nível do pod:

 annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json" 

... ou no nível do contêiner:

 annotations: container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json" 

Observe que a sintaxe acima será alterada quando o Kubernetes seccomp se tornar GA (este evento é esperado na próxima versão do Kubernetes - 1.18 - aprox. Transl.).

Poucas pessoas sabem que o Kubernetes sempre teve um bug que fazia com que os perfis seccomp fossem aplicados ao contêiner de pausa . O tempo de execução compensa parcialmente essa desvantagem, mas esse contêiner não desaparece dos pods, pois é usado para configurar sua infraestrutura.

O problema é que esse contêiner sempre começa com AllowPrivilegeEscalation=true , levando aos problemas AllowPrivilegeEscalation=true no parágrafo 1, e isso não pode ser alterado.

Ao aplicar perfis seccomp no nível do contêiner, você evita essa interceptação e pode criar um perfil que será "aguçado" para um contêiner específico. Isso terá que ser feito até que os desenvolvedores consertem o bug e a nova versão (talvez 1,18?) Fique disponível para todos.

Dica 2 : defina perfis seccomp no nível do contêiner.

Em um sentido prático, essa regra geralmente serve como uma resposta universal à pergunta: "Por que meu perfil seccomp funciona com o docker run , mas não funciona após a implantação em um cluster Kubernetes?"

3. Use o tempo de execução / padrão como último recurso

O Kubernetes possui duas opções para perfis internos: runtime/default e docker/default . Ambos são implementados pelo tempo de execução do contêiner, não pelo Kubernetes. Portanto, eles podem diferir dependendo do tempo de execução usado e de sua versão.

Em outras palavras, como resultado da alteração do tempo de execução, o contêiner pode acessar outro conjunto de chamadas do sistema que podem ser usadas ou não. A maioria dos tempos de execução usa uma implementação do Docker . Se você deseja usar esse perfil, verifique se ele combina com você.

O docker/default perfil docker/default está obsoleto desde o Kubernetes 1.11, portanto, evite usá-lo.

Na minha opinião, o perfil de runtime/default é perfeito para a finalidade para a qual foi criado: proteger os usuários dos riscos associados à execução do docker run em suas máquinas. No entanto, se falarmos sobre aplicativos de negócios executados em clusters do Kubernetes, ousaria afirmar que esse perfil é muito aberto e que os desenvolvedores devem se concentrar na criação de perfis para seus aplicativos (ou tipos de aplicativos).

Dica # 3 : Crie perfis seccomp para aplicativos específicos. Se isso não for possível, lide com perfis para tipos de aplicativos, por exemplo, crie um perfil avançado que inclua todas as APIs de aplicativos da web Golang. Somente como último recurso, use o tempo de execução / padrão.

Nas próximas publicações, mostrarei como criar perfis secccomp no espírito do SecDevOps, automatizar e testá-los em pipelines. Em outras palavras, você não terá desculpas para não mudar para perfis para aplicativos específicos.

4. Não confinado NÃO é uma opção

Desde a primeira auditoria de segurança do Kubernetes, o seccomp foi desativado por padrão. Isso significa que, se você não especificar um PodSecurityPolicy que o habilitará no cluster, todos os pods para os quais o perfil seccomp não está definido funcionarão no modo seccomp=unconfined .

Trabalhar nesse modo significa que uma camada inteira de isolamento é perdida, o que fornece proteção de cluster. Essa abordagem não é recomendada pelos profissionais de segurança.

Dica # 4 : Nenhum contêiner em um cluster deve funcionar no modo seccomp=unconfined , especialmente em ambientes de produção.

5. "Modo de auditoria"

Este ponto não é exclusivo do Kubernetes, mas ainda se enquadra na categoria de "o que você deve saber antes de começar".

Aconteceu que a criação de perfis seccomp sempre foi um negócio complicado e foi amplamente baseado em tentativa e erro. O fato é que os usuários simplesmente não têm a oportunidade de testá-los em ambientes de produção sem arriscar "abandonar" o aplicativo.

Após o advento do kernel Linux 4.14, tornou-se possível executar partes do perfil no modo de auditoria, registrando informações sobre todas as chamadas do sistema no syslog, mas não as bloqueando. Você pode ativar este modo usando o parâmetro SCMT_ACT_LOG :

SCMP_ACT_LOG : o seccomp não afetará a operação de um encadeamento que faz uma chamada do sistema se não se enquadrar em nenhuma regra do filtro, mas as informações sobre a chamada do sistema serão registradas.

Aqui está um exemplo de estratégia para usar esse recurso:

1. Permitir chamadas do sistema que são necessárias.
2. Sistemas de chamada em bloco que se sabe não serem úteis.
3. Registre informações sobre todas as outras chamadas no log.

Um exemplo simplificado é o seguinte:

 { "defaultAction": "SCMP_ACT_LOG", "architectures": [ "SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32" ], "syscalls": [ { "names": [ "arch_prctl", "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp" ], "action": "SCMP_ACT_ALLOW" }, { "names": [ "add_key", "keyctl", "ptrace" ], "action": "SCMP_ACT_ERRNO" } ] } 

( medium-mixed-seccomp.json )

Mas lembre-se de que você precisa bloquear todas as chamadas que são conhecidas por não serem utilizadas e que podem prejudicar o cluster. Uma boa base para a listagem é a documentação oficial do Docker . Ele explica em detalhes quais chamadas do sistema estão bloqueadas no perfil padrão e por quê.

No entanto, há uma captura. Embora o SCMT_ACT_LOG suportado pelo kernel Linux desde o final de 2017, ele entrou recentemente apenas no ecossistema Kubernetes. Portanto, para usar esse método, você precisará do kernel Linux 4.14 e da versão runC não inferior à v1.0.0-rc9 .

Dica 5 : você pode criar um perfil de modo de auditoria para teste em produção combinando listas em preto e branco e registrar todas as exceções.

6. Use listas brancas

Criar listas brancas requer esforços adicionais, pois você precisa identificar todas as chamadas que o aplicativo possa precisar, mas essa abordagem melhora significativamente a segurança:

É altamente recomendável que você use a abordagem da lista de permissões, pois é mais simples e mais confiável. A lista negra precisará ser atualizada sempre que uma chamada do sistema potencialmente perigosa (ou sinalizador / opção perigosa, se estiverem na lista negra) for adicionada. Além disso, você pode alterar frequentemente a apresentação de um parâmetro sem alterar sua essência e, assim, contornar as limitações da lista negra.

Para aplicativos Go, desenvolvi uma ferramenta especial que acompanha o aplicativo e coleta todas as chamadas feitas em tempo de execução. Por exemplo, para o seguinte aplicativo:

 package main import "fmt" func main() { fmt.Println("test") } 

... execute gosystract assim:

 go install https://github.com/pjbgf/gosystract gosystract --template='{{- range . }}{{printf "\"%s\",\n" .Name}}{{- end}}' application-path 

... e obtenha o seguinte resultado:

 "sched_yield", "futex", "write", "mmap", "exit_group", "madvise", "rt_sigprocmask", "getpid", "gettid", "tgkill", "rt_sigaction", "read", "getpgrp", "arch_prctl", 

Até agora, este é apenas um exemplo - detalhes sobre as ferramentas serão mais detalhados.

Dica # 6 : permita apenas chamadas que você realmente precisa e bloqueie todos os outros.

7. Estabeleça as bases (ou prepare-se para comportamentos inesperados)

O kernel monitorará a conformidade com o perfil, não importa o que você registrou nele. Mesmo que isso não seja exatamente o que eu queria. Por exemplo, se você bloquear o acesso a chamadas como exit ou exit_group , o contêiner não poderá concluir o trabalho corretamente e mesmo um comando simples como echo hi suspenderá por um período indeterminado. Como resultado, você obterá alta utilização da CPU no cluster:



Nesses casos, o utilitário strace pode ser útil - mostrará qual é o problema:


sudo strace -c -p 9331

Verifique se os perfis contêm todas as chamadas do sistema que o aplicativo precisa enquanto está em execução.

Dica 7 : Preste atenção às pequenas coisas e verifique se todas as chamadas necessárias do sistema estão incluídas na lista branca.

Com isso, a primeira parte de uma série de artigos sobre o uso do seccomp no Kubernetes no espírito do SecDevOps chega ao fim. Nas partes a seguir, falaremos sobre por que isso é importante e como automatizar o processo.

PS do tradutor

Leia também em nosso blog:

• " Segurança para contêineres do Docker ";
• “ 33+ Ferramentas de segurança Kubernetes ”;
• “ Docker e Kubernetes em ambientes exigentes de segurança ”;
• " 9 Práticas recomendadas de segurança do Kubernetes ."