O que é esse tal de DistroLess?

Imagem menor é sempre melhor e vou te mostrar o porquê!

Você provavelmente já cruzou com esse conceito em algum lugar e ficou pensando o que seria isso? Chegou a hora de, em bom português, deixar claro o que é “DistroLess”!

A ideia de distroless containers vem do objetivo de criar containers cada vez menores, com menos pacotes desnecessários (visto que o container precisa apenas dos pacotes necessários para executar a aplicação) e por consequência uma menor superfície de possível ataque.

Uma das grandes preocupações com sistemas distribuídos em containers é a imagem base ou a imagem desses containers. Isso se deve ao fato dela possuir os pacotes necessários para executar a sua aplicação, pelo menos assim deveria ser!

Como o tempo ensinou, esta é uma boa prática estabelecida e seguida pelo próprio Google e outros grandes players de containers e Kubernetes também. Nesse link, você pode conhecer o projeto do Google sobre isso.

Containers se espalham e multiplicam muito rapidamente dentro de uma empresa, o que normalmente leva a problemas que vão desde escalabilidade a vulnerabilidades.

Mas reduzir o tamanho é tão importante assim? Sim, por três motivos principais: segurança, performance e grana.

Segurança — Quanto maior a quantidade de pacotes para gerenciar, maior a complexidade do ambiente e mais difícil se torna o controle para garantir a imutabilidade e a procedência de cada parte de sua imagem; além de que o trabalho de atualização fica cada vez mais exaustivo e difícil de gerenciar, gerando um esforço extra, muitas vezes desnecessário. Claro que, o contrário, ter uma imagem base limpa, pequena e exclusiva para suas necessidades gera um trabalho árduo também.

Em resumo, não há uma saída simples para nenhum dos casos, porém o resultado aparece em diversas frentes, não apenas de segurança, mas também em performance.

Performance — O desempenho é diretamente afetado, não apenas de seu container menor e sendo transportando mais rápido e estando disponível em outros nodes com mais velocidade, mas também de todo seu sistema, uma vez que terá uma abundância de containers, portanto, uma abundância de imagens “circulando” pelo seu cluster, sendo atualizadas, escaladas e transferidas de um nó para outro, pois nossos sistemas hoje não são mais estáticos e sim vivos e estão em constante atualização e essa essência do “Cloud Native” traz esses desafios de redes/transporte principalmente que afetam o cerne de um ambiente distribuído, a distribuição.

Grana — Claro que o custo é afetado por todos esses fatores, pois sua cloud favorita é boa em vários produtos, mas o melhor deles é em cobrar! A transferência de dados, por exemplo, e o armazenamento são diretamente impactados pelo tamanho de suas imagens e, consequentemente, de seu sistema, aumentando seus custos. Ter essa questão bem resolvida é de extrema importância para manter uma operação saudável.

Então, o que realmente são distroless containers?

Na prática, distroless, assim como serverless, te induz a um erro de tradução literal. Linux é Linux, mas um container não é uma VM que precisa de milhões de pacotes e aplicações para podermos trabalhar, principalmente, porque containers não têm esse propósito. Como já dito antes, idealmente, um container deve ter um propósito único e esse normalmente é processar sua aplicação.

Em um exemplo de scan de vulnerabilidades de uma imagem base JAVA, temos mais de 600 vulnerabilidades em sua versão “latest”, perto de 50 em sua versão “slim” e ZERO em sua versão “distroless”, então só aqui já temos um ótimo indicativo de “superfície de ataque” e de quantidade de pacotes que teríamos que atualizar ou remover.

Dada essa introdução, seus containers não deveriam ter, por exemplo, Bash, Grep e nem mesmo Find para poder rodar suas aplicações GoLang, Node e até mesmo JAVA. Se você está acostumado a conectar num container para debug isso é altamente não recomendado e seguindo o modelo distroless isso será impossível. Claro, o processo de debug ainda será possível e necessário, mas não é por isso que as ferramentas devem estar ali junto de sua aplicação 100% do tempo para uma “eventualidade” de problemas num ambiente de produção. Em nosso cenário de Kubernetes temos um poderoso aliado que se chama “debug containers” funcionando de forma nativa, tirando da frente aquela desculpa: “na hora da investigação o que vou fazer sem a ferramenta xyz”, por exemplo.

Claro que, remover pacotes, mas ter uma aplicação que precisa rodar como privilegiada em seu cluster não adiantará nada, ok! Como sempre, segurança é feita em camadas e deve-se ter atenção em cada estágio dela. Isso dá um trabalho danado, mas com certeza é melhor que contar com a “sorte”.

Conclusão

Como bom SRE sênior terminarei dizendo que tudo aqui “depende”! Depende do seu cenário, das suas aplicações, da sua disponibilidade de tempo e expertise para administrar tudo isso, mas minha recomendação é que deixe essa questão em seu radar e comece a colocá-la em prática em algum projeto. Dê a importância necessária para segurança, antes que seja tarde demais! Comece em um projeto pequeno, se possível, para ganhar as manhas, bater um pouco a cabeça e então ir crescendo. Afinal, ninguém, além de Tony Stark, começa a voar antes de andar!