A segurança precisa se adaptar à entrega contínua cada vez mais rápida no mundo container/Kubernetes, e isso significa segurança em relação ao código, argumentou Mateo Burillo, na RebelCon.io 2019. Burillo demonstrou como implementar um processo DevSecOps com segurança contínua.
Os seres humanos não podem rever vários builds por dia de maneira razoável. Precisamos de uma equipe de segurança que seja capaz de pensar em requisitos de segurança, restrições e práticas recomendadas automatizando-as usando ferramentas que compreendam nativamente os microservices. Para aproveitar ao máximo a agilidade e a capacidade de resposta do DevOps, a segurança deve desempenhar um papel integrado no ciclo completo das aplicações. A segurança deve ser integrada ao pipeline, disse Burillo, usando a segurança como abordagem de código.
Burillo mencionou os benefícios da implementação da segurança como código:
- A primeira e mais importante automação: É preciso dimensionar e acelerar o processo de segurança para alcançar o mundo de microservices e containers;
- Visibilidade: Qualquer membro da equipe pode acessar e discutir as regras de segurança, eliminando silos de conhecimento;
- Rastreabilidade: Agora temos controle de versão e propriedade para todas as alterações feitas.
Os containers são caixas pretas, o que é bom para operações, mas ruim para segurança, segundo Burillo. Podemos levar dias ou semanas até que as violações sejam detectadas. É como ser membro do CSI, mas sem a parte dos cadáveres, já que o contêiner provavelmente desaparecem depois que a violação aconteceu.
O passo mais óbvio a ser feito no momento da criação para criar segurança no produto é a integração da ferramenta CI/CD com um scanner de imagem. As pessoas geralmente associam a varredura de imagens de containers a vulnerabilidades e exposições comuns (conhecidas como listas de CVEs - Common Vulnerabilities and Exposures - ou apenas "vulnerabilidades") e varreduras de vulnerabilidades, mas isso é apenas o começo, disse Burillo. Há muito mais coisas que podemos fazer com um scanner avançado de imagens, de verificações de conformidade (NIST, PCI, MITRE), descobrindo credenciais vazadas, implementando as próprias práticas de segurança em nível de aplicativo.
Existem vários padrões de conformidade de segurança específicos para cada container, e um bom conjunto de recursos de segurança fornecidos pelo Kubernetes, portanto, evitemos ter que reinventar a roda.
O caso de uso mais comum hoje em dia é a integração do software de digitalização de imagens com o pipeline de CI/CD, seja Jenkins, AWS CI/CD, Bamboo ou qualquer outra solução. Burillo mencionou outro caso de uso que talvez seja mais inovador, mas não menos necessário: Fazer verificações regulares de imagem para seus containers de tempo de execução. O que acontece se uma nova vulnerabilidade de 0 dias for descoberta após a imagem ser declarada "limpa" pelo CI/CD, Burillo questionou, ou se o container for atacado, modificando as condições originais?
Burillo mencionou que a digitalização de imagens é necessária, mas não suficiente, pois também precisamos de segurança em tempo de execução. As ferramentas tradicionais de segurança do Linux não fornecem visibilidade em tempo de execução do container, então Burillo sugeriu modernizar o conjunto de ferramentas.
O InfoQ conversou com Mateo Burillo, escritor técnico da Sysdig, após a palestra na RebelCon.io 2019.
InfoQ: O que pode ser feito para trazer agilidade ao mundo da segurança?
Mateo Burillo: Acho que o conceito principal a ser adotado não é muito diferente das mudanças experimentadas pela infraestrutura de TI ou QA: implementar a segurança como código.
Segurança como código implica que as regras precisam ser versionadas e mantidas em um repositório. A equipe de operações de segurança vai fazer os pushes para esse repositório e o ambiente deve ser capaz de fazer o pull e impor dinamicamente essas regras.
Deixe-me usar um exemplo para ajudar a esclarecer esse conceito:
Ao implementar a varredura de imagens com o Anchore, por exemplo, as imagens do container sempre serão verificadas para detectar os CVEs. Em seguida, a equipe de segurança decide que não desejamos que nenhum container seja veiculado como raiz ou que vaze as credenciais da AWS.
- A equipe de segurança modifica a política de varredura e envia a nova versão para o repositório interno;
- O Anchore engine é ajustado para detectar, baixar e aplicar a atualização;
- A ferramenta de CI/CD, digamos Jenkins, é responsável pela criação da imagem. Podendo ser facilmente integrado ao Anchore, e uma das etapas no pipeline de construção executa essa verificação de validação de imagem. Apenas as imagens aprovadas pelo Anchore são assinadas pelo Jenkins e enviadas para o registro interno;
- O Kubernetes é configurado, usando um Admission Controller, para recusar a execução de qualquer imagem que não tenha sido assinada pela ferramenta de CI/CD.
No exemplo acima, a equipe de segurança precisa apenas projetar metas de segurança de alto nível, todo o mais é automatizado.
InfoQ: O que pode ser feito para garantir que os aplicativos que estão sendo executados dentro de containers estejam operando de maneira segura?
Burillo: Estando ciente de que não existe segurança 100% garantida em TI, há várias coisas que podemos fazer para chegar o mais perto possível:
- Digitalização de imagens, para detectar vulnerabilidades conhecidas e seguir as melhores práticas de segurança que são mais relevantes para o setor de TI e o tipo de aplicativos que implantamos. Por exemplo:
- Sabemos que a aplicação só precisa montar o /web/html à partir de um volume externo, qualquer outra operação do sistema de arquivos no Dockerfile deve levantar uma bandeira vermelha;
- Temos uma incompatibilidade de licença com o GLPv3, qualquer pacote de software declarando essa licença, precisa ser reportada.
- Verificando os containers em relação aos frameworks de conformidade de segurança específicas do container. Não reinventar a roda é uma das regras de ouro na segurança, é por isso que temos padrões, para citar alguns:
- Guia de segurança de container do aplicativo NIST SP 800-190;
- Centro de Referência para o Kubernetes do Internet Security (CIS);
- Padrão de segurança de dados do setor de cartões de pagamento ou PCI DSS.
- Precisamos de uma ampla visibilidade e rastreabilidade para entender como os containers são construídos e como operam em tempo de execução. Não podemos parar as ameaças de segurança que não vemos;
- Implementando regras de segurança em tempo execução e correção automática. Os containers são máquinas simples, o que é uma grande vantagem durante a execução, pois é possível prever facilmente o comportamento e detectar imediatamente se há algo de suspeito acontecendo. Vamos usar esse recurso para melhorar a segurança de TI.
InfoQ: Quais recursos de segurança o Kubernetes possui e qual é o conselho para aplicarmos?
Burillo: Existem muitos recursos e a melhor ou pior parte é que a lista está crescendo continuamente: RBAC, webhooks de admissão, políticas de segurança de pods, políticas de rede, rotação automática de certificados, cotas de recursos, etc.
O conselho aqui é pensar como um estatístico. Existe o perigo de ultrapassar o limite do que implementamos, e só podemos implementar as regras que podemos imaginar. Colete os dados de ataques passados, da experiência do desenvolvedor, de violações notórias de segurança no ecossistema, de boletins informativos e blogs do Kubernetes voltados à segurança. E então pense: qual é a próxima regra de segurança que maximizará a segurança e minimizará a complexidade que precisamos introduzir?
Há um bom exemplo de um cluster vulnerável do Kubernetes que expusemos à Internet como um honeypot. O cluster é intencionalmente falho, mas o ataque, a detecção de ataques e a perícia são reais. Esses exercícios de violação de segurança ajudarão a identificar e bloquear ataques ativos reais em nosso ecossistema. Tenha em mente que estão sempre mudando e se adaptando, a segurança é uma corrida armamentista.
InfoQ: Como podemos detectar anomalias em softwares que estão sendo executados em containers?
Burillo: Como mencionei anteriormente, a principal vantagem dos containers é que são "simples" por natureza, então podemos facilmente descobrir regras para determinar o que é permitido e o que é proibido durante o tempo de execução. O principal obstáculo, porém, é que a maioria dos softwares de segurança que existiam antes do advento dos containers são completamente cegos para a operação do container em tempo de execução, podemos analisar o que entra e sai, mas fora isso é apenas uma caixa preta.
Sempre recomendamos o Falco para detecção de anomalias em tempo de execução, pois foi projetado pensando nos containers desde o início, garantindo total visibilidade e rastreabilidade, graças à instrumentação no nível do kernel e, por último, mas não menos importante, é totalmente open source e um projeto de sandbox CNCF. Podemos começar a experimentá-lo imediatamente ou até mesmo contribuir com as regras de segurança de containers para a comunidade :).