Como usar conteúdo de terceiros com segurança

Esta é a parte final de uma série de quatro partes sobre como criar sua estratégia de AppSec para Kubernetes.

Confira as partes anteriores:

• Segurança de contêineres em todo o SDLC

• Adotar a segurança desde o início é uma questão de cultura, não apenas de ferramentas

• Da segurança de imagens à segurança de workloads

Um tema que ainda não abordamos em nossa discussão sobre segurança de aplicações no Kubernetes são as diferenças entre aplicações próprias e de terceiros.

Do ponto de vista dos seus sistemas de produção, não há muita diferença entre as duas. Não importa se você escreveu a aplicação ou se outra pessoa fez isso: há muitas semelhanças. De qualquer forma, o app tem algum acesso aos dados de produção, e vulnerabilidades na aplicação podem resultar em algum nível de comprometimento desses dados ou dos sistemas associados. Do ponto de vista tradicional de operações, é fácil tratar aplicações próprias e de terceiros da mesma maneira. Mas o que acontece quando transferimos parte das responsabilidades de operações para as equipes de desenvolvimento?

Empacotamento de aplicações

No Kubernetes, é comum instalar aplicações de terceiros usando uma ferramenta como o Helm. O repositório Helm Charts contém configurações para centenas de aplicações, de aerospike a zetcd, o que economiza muito tempo. Os fornecedores de software para consumidores também estão cada vez mais empacotando suas aplicações com o Helm. Um chart do Helm contém as configurações necessárias para instalar a aplicação e, por sua vez, geralmente faz referência a um conjunto de imagens de terceiros. Mais recentemente, temos visto o desenvolvimento de Cloud Native Application Bundles (CNAB) seguindo um padrão semelhante.

Vamos dar uma olhada rápida em um exemplo de chart do Helm, neste caso, do Linkerd.

$ tree
.
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config.yaml
│ ├── daemonset.yaml
│ ├── ingress.yaml
│ └── service.yaml
└── values.yaml

1 directory, 9 files.

Que elementos do chart podem afetar a segurança? No arquivo Values.yaml, encontramos detalhes de algumas imagens de contêiner, que podem conter vulnerabilidades:

image: buoyantio/linkerd:1.1.2
image: buoyantio/kubectl:v1.6.2

O arquivo de valores também define limites de recursos adequados

resources:
limits:
cpu: 500m
memory: 512M

Os templates, especialmente o daemonset, contêm uma especificação de contêiner que permite configurar várias propriedades de segurança, como definir se os contêineres são executados como root, se o sistema de arquivos é somente leitura, se solicitam apenas as permissões necessárias, se definem uma política de segurança de pods, entre outras.

Aplicações de terceiros em todo o SDLC

Como essas considerações sobre empacotamento se relacionam com nosso SDLC e com a maneira como aplicamos a segurança ao longo de todo o ciclo de vida?

• Desenvolvimento local — se você usa charts de terceiros, talvez nenhuma das suas equipes de desenvolvimento trabalhe neles localmente.

• CI/CD — dependendo de como você instala os charts, pode haver uma referência a eles em algum arquivo de configuração (como um Helmfile ou Terraform, por exemplo), mas provavelmente não há testes nesse ponto, exceto, talvez, alguns testes básicos.

• Registros — os charts do Helm normalmente fazem referência a imagens em repositórios públicos. Em geral, é possível substituí-las por imagens internas, mas você precisará de um processo para manter essas cópias internas atualizadas.

Em uma aplicação independente, é bem possível que a primeira oportunidade de verificar se há vulnerabilidades seja somente quando ela for implantada em produção. Isso cria uma desconexão entre a realidade de transferir para os desenvolvedores as decisões sobre conteúdo de terceiros e a capacidade das nossas ferramentas de dar um retorno rápido sobre a segurança dessas aplicações.

Tipos de aplicações de terceiros

Em termos gerais, podemos classificar as aplicações de terceiros em dois grupos:

• Aplicações independentes que oferecem um valor específico e bem definido, como o WordPress ou o Jenkins.

• Dependências diretas de alguma aplicação própria, como Redis ou PostgreSQL.

Ao observar como as aplicações de terceiros são introduzidas nos nossos ambientes, fica claro por que essa distinção é útil. Aplicações independentes costumam ser mais uma preocupação das equipes de operações ou de plataforma. Elas são instaladas e gerenciadas por uma equipe central, que oferece a aplicação como serviço para outras equipes de desenvolvimento. Já as dependências diretas ficam mais frequentemente sob responsabilidade de cada equipe de desenvolvimento. Ao pensar em como proteger a cadeia de suprimentos de software de terceiros, precisamos considerar as duas perspectivas.

Conclusões

O que podemos fazer para resolver esse problema? A resposta é investir em mais automação e criar pipelines que facilitem a validação e os testes de conteúdo de terceiros nas etapas iniciais do processo. Esse pipeline deve atender tanto a aplicações independentes (que talvez não tenham um pipeline) quanto aos testes de dependências de aplicações existentes.

Para resolver esse problema, precisamos pensar em toda a cadeia de suprimentos de software. Precisamos de ferramentas locais que nos ajudem a verificar rapidamente um Helm Chart, Operator ou pacote semelhante de configurações e referências a imagens. Precisamos de pipelines de CI/CD que possamos configurar rapidamente sob demanda, para entender como as mudanças no conteúdo de terceiros afetam o risco de usá-lo. Também precisamos de pipelines mais eficientes para trazer imagens externas para nosso ambiente de confiança. Seria ótimo ver o surgimento de padrões para compartilhar dados confiáveis sobre vulnerabilidades.

É possível usar aplicações de terceiros com segurança em um ambiente que transfere rapidamente responsabilidades para os desenvolvedores. Mas, para isso, é preciso considerar o processo necessário e incorporar o máximo possível dele ao SDLC seguro.