Como proteger um pod do Kubernetes com Regula e Open Policy Agent

A Fugue lançou recentemente o suporte ao Kubernetes no Regula, nosso mecanismo de políticas de código aberto para verificar infraestrutura como código. Além de verificar seus arquivos Terraform e CloudFormation em busca de violações de segurança e conformidade, o Regula agora também pode verificar manifestos YAML do Kubernetes!

Nesta publicação, vamos mostrar como executar o Regula em um manifesto do Kubernetes para detectar um pod inseguro e, em seguida, protegê-lo. Como bônus, a versão final do manifesto estará em conformidade com o CIS Kubernetes Benchmark v1.6.1, um conjunto de recomendações para proteger ambientes Kubernetes.

Tudo pronto? Vamos lá!

Primeiros passos

Primeiro, instale o Regula. Se você usa o Homebrew, execute os seguintes comandos:

brew tap fugue/regula
brew install regula

Você também pode instalar um binário pré-compilado para sua plataforma ou, se preferir, executar o Regula com o Docker.

Ao escrever esta publicação, usamos o Regula v1.5.0.

Em seguida, acesse nosso gist do GitHub, selecione o botão Download ZIP e extraia os arquivos. São dois:

• pod.yaml: um manifesto do Kubernetes inseguro e fora de conformidade

• pod-compliant.yaml: uma versão protegida e em conformidade do mesmo manifesto

À medida que explicamos como corrigir cada violação, você pode acompanhar editando manualmente o pod.yaml ou simplesmente consultar a versão protegida pod-compliant.yaml.

Analisando o manifesto

Nosso manifesto declara um pod simples chamado hello, com um único contêiner BusyBox, também chamado hello:

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']

Não parece inseguro, certo? Mas vamos executar o Regula para ter certeza.

Executando o Regula

No terminal, navegue até o diretório que contém os arquivos baixados. Vamos executar o Regula em pod.yaml com a opção --format compact para economizar espaço:

regula run pod.yaml --format compact

O resultado é o seguinte:

Eita! Nosso pod está longe de ser tão seguro quanto poderia. O Regula encontrou 6 problemas.

Não se preocupe: podemos corrigir todos eles! Vamos analisar cada violação para resolvê-la.

Corrigindo as violações

Tokens de conta de serviço

A violação: “Service account ‘automountServiceAccountToken’ should be set to ‘false’ [Medium]”

Controle CIS Kubernetes v1.6.1: 5.1.6, “Ensure that Service Account Tokens are only mounted where necessary”

Por que isso importa: Os tokens de conta de serviço são usados para autenticar solicitações de processos dentro do cluster ao servidor da API do Kubernetes. Por padrão, os tokens de conta de serviço são montados automaticamente em todos os pods. No entanto, se um agente mal-intencionado conseguir comprometer um único pod, poderá usar o token da conta de serviço para iniciar um ataque de escalonamento de privilégios e obter controle de todo o cluster.

Por isso, se uma carga de trabalho não precisa se comunicar com o servidor da API, é melhor evitar a montagem automática de um token de conta de serviço. Isso está de acordo com o princípio de segurança do menor privilégio.

Como corrigir: defina automountServiceAccountToken como false na especificação do pod:

spec:
  automountServiceAccountToken: false

Consulte a linha 10 em pod-compliant.yaml.

Usuário root

A violação: “Pods should not run containers as the root user [Medium]”

Controle CIS Kubernetes v1.6.1: 5.2.6, “Minimize the admission of root containers”

Por que isso importa: Executar como root sem necessidade é quase sempre uma má ideia. Se um contêiner for executado como root, um invasor poderá obter privilégios de root no sistema host caso consiga escapar do contêiner.

Como corrigir: defina runAsUser como qualquer ID de usuário diferente de zero na especificação do pod, já que 0 corresponde ao root:

spec:
  securityContext:
    runAsUser: 1001

Consulte as linhas 8–9 em pod-compliant.yaml.

Verifique se o usuário especificado aqui está definido na imagem do Docker. Muitas vezes, um usuário sem privilégios de root é criado executando o comando Linux useradd no Dockerfile; em seguida, o ID do usuário é especificado pelo comando USER.

Recursos do Linux

As duas próximas violações estão relacionadas e, no nosso exemplo, podem ser corrigidas da mesma maneira.

A violação: “Pods should not run containers with the NET_RAW capability [Medium]”

Controle CIS Kubernetes v1.6.1: 5.2.7, “Minimize the admission of containers with the NET_RAW capability”

A violação: “Pods should not run containers with default capabilities assigned [Medium]”

Controle CIS Kubernetes v1.6.1: 5.2.9, “Minimize the admission of containers with capabilities assigned”

Por que isso importa: Quando um contêiner Linux é executado, ele recebe um conjunto padrão de recursos que concedem privilégios específicos de root aos processos. O recurso NET_RAW é especialmente perigoso, pois um invasor pode usá-lo para espionar o tráfego de rede ou gerar tráfego IP com endereços falsificados.

Muitos serviços não precisam de todos os recursos padrão. Por isso, é recomendável removê-los primeiro e depois adicionar de volta apenas os necessários. Neste exemplo, não vamos adicionar nenhum, mas você pode fazer isso com add: ["FOO"].

Como corrigir: defina um securityContext para o contêiner e especifique capabilities com drop: ["ALL"] para corrigir as duas violações de uma só vez (ou drop: ["NET_RAW"] para corrigir apenas a 5.2.7, se preferir):

spec:
  containers:
    - name: hello
      securityContext:
        capabilities:
          drop: ["ALL"]  

Consulte as linhas 15–17 em pod-compliant.yaml.

Perfil seccomp

A violação: “Pod seccomp profile should be set to ‘docker/default’ [Medium]”

Controle CIS Kubernetes v1.6.1: 5.7.2, “Ensure that the seccomp profile is set to docker/default in your pod definitions”

Por que isso importa: No Linux, o modo de computação segura (seccomp) restringe quais chamadas de sistema (syscalls) são permitidas. Em geral, ambientes de execução de contêineres como o Docker oferecem um perfil seccomp padrão que desativa várias chamadas de sistema, aumentando a segurança.

Observe que o perfil docker/default foi descontinuado no Kubernetes 1.11. Portanto, apesar do que diz o CIS Kubernetes v1.6.1, é melhor usar runtime/default.

Como corrigir: Há algumas maneiras de fazer isso, dependendo da sua versão do Kubernetes. Nas versões anteriores à v1.19, você pode usar a anotação seccomp.security.alpha.kubernetes.io/pod nos metadados do pod:

metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Consulte as linhas 5–6 em pod-compliant.yaml.

Contexto de segurança

A violação: “Pods and containers should apply a security context [Medium]”

Controle CIS Kubernetes v1.6.1: 5.7.3, “Apply Security Context to Your Pods and Containers”

Por que isso importa: Um contexto de segurança para um pod ou contêiner define várias configurações de segurança relacionadas ao controle de acesso, aos recursos do Linux e aos privilégios. É recomendável definir os parâmetros relevantes para o seu caso de uso específico.

Como corrigir: Você pode definir um contexto de segurança no nível do pod ou do contêiner. Se as configurações forem definidas nos dois níveis e houver sobreposição, as configurações do contêiner prevalecem sobre as do pod.

Anteriormente, definimos um securityContext no nível do pod para impedir a execução como root e, no nível do contêiner, para remover todos os recursos. Portanto, essa violação já está corrigida.

Consulte as linhas 8–9 e as linhas 15–17 em pod-compliant.yaml.

Executando o Regula novamente

Agora que corrigimos as 6 violações, vamos ver o que o Regula diz sobre nosso pod recém-protegido. Aqui está o manifesto atualizado, que disponibilizamos para você como pod-compliant.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: hello
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default" 
spec:
  securityContext:
    runAsUser: 1001
  automountServiceAccountToken: false
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      securityContext:
        capabilities:
          drop: ["ALL"]

Se você editou o pod.yaml ao longo do processo, execute o mesmo comando de antes:

regula run pod.yaml --format compact

Se você não editou o pod.yaml (sem julgamentos!), basta executar o Regula no manifesto pod-compliant.yaml:

regula run pod-compliant.yaml --format compact

E o resultado é este:

No problems found. Nailed it.

Pronto! Corrigimos com sucesso todos os problemas encontrados pelo Regula em nosso pod inseguro. Bom trabalho!

E agora?

Agora que você aprendeu a usar o Regula para proteger um manifesto do Kubernetes, confira outras práticas recomendadas de segurança para Kubernetes.

Saiba mais sobre o Regula em regula.dev. Lá, você encontra a lista completa de nossas regras do Kubernetes. Também pode aprender a dispensar o resultado de uma regra ou até mesmo desativar uma regra por completo se ela não for relevante para sua organização.