Snyk @ Snyk: habilitando RBAC do Kubernetes para os desenvolvedores da Snyk

Como disse o Tio Ben certa vez: “Com grandes poderes vêm grandes responsabilidades.” Isso também vale para a API do Kubernetes. Ela é muito poderosa e permite criar coisas incríveis, mas tem seu preço: um usuário mal-intencionado também pode usá-la para fazer coisas ruins.

Conheça o Kubernetes RBAC (controle de acesso baseado em função), que permite usar a API de forma controlada, concedendo apenas os privilégios necessários e seguindo o princípio do menor privilégio.

O Kubernetes permite definir funções em namespaces e funções de cluster fora deles.

Mas isso só transfere o problema para outro lugar: precisamos de bons processos para gerenciar os recursos de RBAC; caso contrário, um simples erro de configuração pode causar um impacto grave na segurança. Imagine um desenvolvedor que “acidentalmente” concede a função de administrador do cluster à conta de serviço padrão no namespace padrão. Que horror!

Foto de https://unsplash.com/@arnykoor

Uma abordagem guiada para a segurança do Kubernetes

O ideal seria permitir que cada desenvolvedor criasse permissões de RBAC como preferisse, mantendo proteções para bloquear configurações inseguras. Uma forma de fazer isso é exigir uma revisão de código pela equipe de AppSec para qualquer alteração que inclua recursos de RBAC. Embora isso possa funcionar, há algumas desvantagens:

• A equipe de AppSec vira um gargalo e atrasa os desenvolvedores.

• A segurança vira uma “mágica” conhecida apenas pela equipe de AppSec, já que não há diretrizes publicadas sobre o que ela procura ao revisar essas alterações.

• Acabamos reforçando os silos e impedindo que os desenvolvedores assumam responsabilidades pela segurança. Isso agrava ainda mais o problema: a equipe de AppSec vira um gargalo e atrasa os desenvolvedores.

Checklist de segurança do Kubernetes RBAC

Na Snyk, enfrentamos desafios semelhantes. Queríamos dar autonomia aos desenvolvedores para usar a API do Kubernetes sem atrasá-los. Começamos compilando uma lista de requisitos de segurança para regras de RBAC. A lista é bem curta e se baseia principalmente nos benchmarks CIS do Kubernetes:

• Não usar curingas para recursos ou verbos

• Não usar regras integradas, pois concedem permissões demais

• Não vincular contas de serviço ao namespace padrão (que deve estar vazio) nem ao namespace kube-system (que executa cargas de trabalho confidenciais)

• Não vincular à conta de serviço padrão

• Não usar permissões perigosas, como criar pods ou ler segredos

Com a lista pronta, podemos fazer algumas coisas:

• Publique isso como nossas diretrizes internas e exija que todos os objetos de RBAC sigam essa lista. Agora, os critérios não têm nada de “mágico”.

• Pedir que desenvolvedores e engenheiros de segurança documentem qualquer violação da lista como um risco de segurança e informem a equipe de AppSec.

• Pedir feedback e convidar todos os desenvolvedores a contribuir e atualizar a lista, rompendo os silos.

• AUTOMAÇÃO. Afinal, com uma lista em mãos, queremos facilitar ao máximo os testes.

Automatizando verificações de configuração do Kubernetes com Snyk IaC

No fim de 2020, a Snyk anunciou um novo produto: Snyk Infrastructure as Code (Snyk IaC). O Snyk IaC inclui um conjunto de regras que podemos usar para testar nosso código de IaC, incluindo manifestos do Kubernetes (e também Terraform, mas isso fica para outro artigo). Uma das vantagens de trabalhar na Snyk é ter acesso antecipado a qualquer recurso e, melhor ainda, poder contribuir com o produto.

Depois de compilar nossa lista, entramos em contato com a equipe do Snyk IaC para conversar sobre nosso checklist de Kubernetes RBAC — e pronto! Agora temos cinco novas verificações no Snyk IaC para automatizar nossas verificações de segurança e garantir que a equipe de AppSec não seja um gargalo!

Segurança de IaC mais simples do que nunca para os desenvolvedores da Snyk

O Snyk IaC pode fazer varreduras por meio do GitHub Actions e gerar resultados no formato Sarif, que pode ser integrado ao GitHub Security. Mas queríamos ir além e mostrar as violações diretamente nos nossos PRs, algo que o Snyk IaC ainda não faz. Nossa equipe de AppSec criou uma integração própria com o GitHub: assim, toda alteração nos arquivos de manifesto do Kubernetes é verificada automaticamente pelo Snyk no momento do commit e, se houver uma violação, o desenvolvedor recebe um alerta no PR:

Agora, todos os nossos desenvolvedores podem fazer alterações de RBAC sem parar para envolver a equipe de AppSec, que pode ficar mais tranquila sabendo que o Snyk está cuidando da segurança.

Quer algo parecido para sua equipe? Confira o repositório de exemplo aqui e crie sua conta na Snyk — você pode começar a usar IaC gratuitamente!