Snyk Container e Cloud Native Buildpacks: segurança de aplicações cloud native do jeito certo

Você está executando microsserviços em contêineres? Parabéns! Esse é um passo importante para atender às necessidades do negócio e entregar aplicações aos clientes o mais rápido possível. Mas como reduzir os possíveis riscos associados à implantação mais rápida de software? É simples: com o Snyk.

Snyk Container, combinado com uma ferramenta de build que cria imagens de contêiner compatíveis com OCI, ajuda você a reduzir esse risco e a se concentrar no que realmente importa: oferecer uma experiência de excelência aos clientes. Vamos ver como funciona.

A diferença entre imagens Docker e imagens compatíveis com OCI

Para garantir que todos os runtimes de contêiner executem imagens produzidas por qualquer ferramenta de build, a comunidade de contêineres de código aberto criou a Open Container Initiative (OCI) para definir padrões do setor para formatos e runtimes de imagens de contêiner. Com uma imagem OCI, qualquer runtime de contêiner que implemente aOCI Runtime Specification pode extrair a imagem e executá-la em um ambiente isolado.

É bem provável que você conheça a empresa Docker e talvez esteja se perguntando qual é a diferença entre imagens OCI e imagens Docker. Hoje, a resposta é: “não muita”. Ainda existem algumas imagens Docker antigas, anteriores às especificações OCI. Formalmente, elas são conhecidas como formatos da especificação Docker v1 e não são compatíveis com o esquema Docker v2, doado à OCI e usado como base para as especificações OCI. Mas essas imagens v1 datam de 2017. Hoje, quase todos os registros de contêiner, plataformas Kubernetes e runtimes de contêiner são baseados nas especificações OCI. Isso inclui o mecanismo Docker, o Docker Hub e outras ferramentas e produtos Docker.

Talvez você esteja se perguntando por que isso importa. As especificações abertas permitiram que outros grupos encontrassem maneiras inovadoras de criar contêineres. Como todos acabam criando imagens compatíveis com OCI, você pode executá-las em qualquer lugar, e ferramentas de segurança como o Snyk Container ajudam a mantê-las seguras. No fim das contas, você provavelmente quer que as equipes de desenvolvimento se concentrem no código da aplicação, e não em como deve ser o Dockerfile, em passar horas verificando quais bibliotecas de código aberto devem ou não usar, ou até em vasculhar milhares de tags de imagens no Docker Hub para descobrir qual imagem base usar. Vamos conhecer um método para criar contêineres diretamente do código-fonte: Cloud Native Buildpacks.

Cloud Native Buildpacks: do código-fonte aos contêineres em uma única etapa

Cloud Native Buildpacks (CNBs) transformam o código-fonte da sua aplicação em imagens OCI totalmente compatíveis, que podem ser executadas em qualquer nuvem. Melhor ainda: oferecem suporte a todas as linguagens de programação populares. Problema dos contêineres resolvido, com controle, conformidade e facilidade de manutenção!

Se você já usou o Heroku, o Pivotal PaaS (hoje chamado VMware Tanzu Application Service) ou o Cloud Foundry, projeto de código aberto relacionado, já viu algo parecido com buildpacks. Basta enviar seu código para esses serviços, que eles cuidam de empacotá-lo em um objeto de runtime adequado. Os CNBs levam essa mesma experiência às imagens OCI. O desenvolvedor escreve o código, e os CNBs compilam todas as dependências da aplicação e empacotam em uma imagem de contêiner tudo o que ela precisa.

Como funcionam os Cloud Native Buildpacks (do vmware Tanzu Developer Center)

Exemplo

1$ pack build pasapples/pbs-demo-image:latest --builder paketobuildpacks/builder:base --publish --path ./target/springbootemployee-0.0.1-SNAPSHOT.jar

Então, o que exatamente os Cloud Native Buildpacks criam?

Assim como qualquer ferramenta de criação de imagens, os Cloud Native Buildpacks criam um conjunto de camadas do sistema de arquivos que contém o runtime, sua aplicação e todas as dependências, além dos metadados que o mecanismo de contêiner usa para saber como iniciar a aplicação. Veja as informações das camadas do exemplo acima, obtidas com o comando docker image history:

1$ docker image history pasapples/pbs-demo-image:latest
2IMAGE      CREATED    CREATED BY   SIZE  COMMENT
35d29940d2e52   41 years ago            68kB
4<missing>  41 years ago            46.3MB
5<missing>  41 years ago            10B
6<missing>  41 years ago            7.05MB
7<missing>  41 years ago            451kB
8<missing>  41 years ago            2.09MB
9<missing>  41 years ago            7.23MB
10<missing>  41 years ago            3.04MB
11<missing>  41 years ago            140MB
12<missing>  41 years ago            214B
13<missing>  41 years ago            6.69MB
14<missing>  41 years ago            2.27MB
15<missing>  41 years ago            398kB
16<missing>  41 years ago            6.51MB
17<missing>  41 years ago            7B
18<missing>  41 years ago            745B
19<missing>  41 years ago            987kB
20<missing>  41 years ago            63.2MB

Se o registro de data e hora de 41 anos atrás parece estranho, isso tem a ver com a possibilidade de reproduzir builds. Você encontra mais informações sobre os detalhes aqui: Time Travel with Pack

Com a ferramenta dive, podemos explorar o conteúdo das camadas em mais detalhes. Na janela superior esquerda da captura de tela abaixo, selecionamos a penúltima camada da imagem (no dive, as camadas aparecem de baixo para cima, enquanto na saída do build acima elas aparecem na ordem inversa). À direita, inspecionamos o conteúdo dessa camada, que consiste em arquivos JAR de uma aplicação Spring Boot dentro da nossa imagem OCI. O CNB organizou tudo isso para nós com base no código-fonte.

Segurança de imagens de contêiner OCI com Snyk Container

O Snyk Container encontra vulnerabilidades em contêineres e workloads Kubernetes ao longo de todo o ciclo de vida do desenvolvimento de software (SDLC), analisando qualquer imagem compatível com OCI, inclusive as criadas com Cloud Native Buildpacks ou outras ferramentas de build que geram imagens OCI. Mas o Snyk faz mais do que apenas listar todas as vulnerabilidades presentes no seu contêiner: o Snyk Container oferece recomendações para ajudar você a criar rapidamente contêineres melhores e menos vulneráveis. E, com nossos recursos aprimorados de detecção de imagens base, oferecemos o mesmo nível de recomendações que antes só estava disponível para quem incluía um Dockerfile.

Correção automatizada de imagens base com o Snyk Container

Amplie seus recursos de segurança e ajude os desenvolvedores a eliminar rapidamente várias vulnerabilidades: basta atualizar para uma imagem base mais segura ou refazer o build quando a imagem base estiver desatualizada.

Ao analisar essas imagens OCI, o Snyk identifica a imagem base usada para criá-las e sugere opções com poucas vulnerabilidades, como mostrado abaixo.

Qual imagem base podemos usar para nosso contêiner OCI ou atualizamos recentemente?

Essas recomendações de imagens base aparecem independentemente de como ou onde você analisa suas imagens ao longo do ciclo de vida. O exemplo acima mostra uma imagem armazenada no Docker Hub; abaixo, analisamos uma imagem com a CLI do Snyk, que também pode ser usada para análises nos pipelines de CI. O Snyk pode sugerir imagens base com poucas vulnerabilidades, como mostrado abaixo:

1$ snyk container test pasapples/pbs-demo-image
2
3Testing pasapples/pbs-demo-image...
4
5✗ High severity vulnerability found in openssl
6  Description: NULL Pointer Dereference
7  Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073
8  Introduced through: openssl@1.1.1-1ubuntu2.1~18.04.5, ca-certificates@20180409, openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
9  From: openssl@1.1.1-1ubuntu2.1~18.04.5
10  From: ca-certificates@20180409 > openssl@1.1.1-1ubuntu2.1~18.04.5
11  From: openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
12  and 1 more...
13  Fixed in: 1.1.1-1ubuntu2.1~18.04.9
14
15...
16
17Organization:  pas.apicella-41p
18Package manager:   deb
19Project name:  docker-image|pasapples/pbs-demo-image
20Docker image:  pasapples/pbs-demo-image
21Platform:      linux/amd64
22Base image:    ubuntu:bionic-20200403
23Licenses:      enabled
24
25Tested 93 dependencies for known issues, found 57 issues.
26
27Base Image          Vulnerabilities  Severity
28ubuntu:bionic-20200403  49           0 critical, 0 high, 16 medium, 33 low
29
30Recommendations for base image upgrade:
31
32Minor upgrades
33Base Image Vulnerabilities  Severity
34ubuntu:bionic  25           0 critical, 0 high, 3 medium, 22 low
35
36Major upgrades
37Base Image  Vulnerabilities  Severity
38ubuntu:rolling  17           0 critical, 0 high, 2 medium, 15 low

Vulnerabilidades da aplicação e do contêiner em conjunto

Nem sempre você terá acesso ao código-fonte original executado nos seus contêineres, mas as vulnerabilidades nas dependências do código continuam sendo importantes. Como parte da análise de contêineres, o Snyk pode detectar e monitorar dependências de código aberto para as linguagens de programação mais populares.

A camada base versus as dependências de código aberto, exibidas com clareza para uma imagem OCI do CNB.

Ajude os desenvolvedores a se concentrarem nas vulnerabilidades de maior risco

O Snyk ajuda você a priorizar facilmente os problemas mais importantes, em vez de analisar centenas deles um por um. Ignore ou exclua vulnerabilidades das imagens base e use sinais de risco, como o nível de maturidade dos exploits e configurações inseguras de workloads, para ajudar as equipes a filtrar o ruído comum nos relatórios de vulnerabilidades de contêineres.

Snyk Container é apenas uma parte da plataforma Snyk Cloud Native Application Security, criada para ajudar desenvolvedores a encontrar e corrigir vulnerabilidades em aplicações cloud native. Experimente hoje mesmo.