Skip to main content

Assinatura de imagens de contêiner: comparação entre Sigstore, Notary e Docker Content Trust

Escrito por
Headshot of Hrittik Roy

Hrittik Roy

feature container isolation

26 de setembro de 2023

0 minutos de leitura

No ecossistema moderno de software, a conteinerização se tornou uma forma popular de empacotar e implantar aplicações. Com o crescimento dessa tendência, garantir a segurança das cadeias de suprimentos de software passou a ser uma preocupação essencial para empresas de todos os portes. Adotar boas práticas, como assinar e verificar imagens para mitigar ataques man-in-the-middle (MITM) e validar sua autenticidade e atualidade, é fundamental para proteger a integridade da cadeia de suprimentos de software.

A assinatura de imagens de contêiner usa técnicas criptográficas para vincular a imagem a uma entidade ou organização específica, criando uma cadeia de confiança. Isso ajuda a garantir a autenticidade e a integridade do código contido nas imagens.

Além disso, assinar imagens de contêiner ajuda a estabelecer propriedade e responsabilização. As assinaturas podem ser úteis para auditorias, permitindo que as organizações rastreiem e verifiquem a origem das imagens e as alterações feitas nelas ao longo do tempo, além de aplicar padrões e normas de conformidade específicos.

Neste artigo, vamos comparar três soluções populares para assinar contêineres: Sigstore Cosign, Notary v2 e Docker Content Trust (DCT), também conhecido como Notary v1. Você vai conhecer os recursos e as funcionalidades de cada uma e descobrir qual é a mais adequada para proteger as cadeias de suprimentos de imagens de contêiner. Para encerrar, incluímos um tutorial que ensina a integrar uma dessas ferramentas ao seu fluxo de trabalho.

Ferramentas para assinar contêineres

Há várias ferramentas disponíveis para assinar suas imagens com segurança. Três das mais conhecidas são Cosign, Notary e DCT — cada uma com especificações e requisitos próprios.

Sigstore Cosign

Cosign é uma ferramenta que permite assinar, verificar e proteger software de forma simples e segura. Ela é distribuída sob a licença Apache 2.0 e foi criada com base no padrão Sigstore, que garante a integridade e a autenticidade de imagens de contêiner. A popularidade do Cosign cresce rapidamente, com cerca de mais de 3.400 estrelas no GitHub.

O Cosign é conhecido por oferecer suporte à assinatura sem chave por meio da autoridade certificadora Sigstore Fulcio e do log de transparência imutável Rekor, com identidade autenticada pelo OpenID Connect (OIDC). Essa abordagem usa uma infraestrutura invisível, dispensando a preocupação de gerenciar ou manter chaves por conta própria. O Cosign simplifica o processo ao gerar chaves efêmeras, facilitando a verificação e a assinatura da autenticidade de imagens e blobs assinados.

Docker Content Trust

O Docker Content Trust (DCT) foi desenvolvido pela Docker em 2015 e, posteriormente, doado à Cloud Native Computing Foundation (CNCF) como o projeto Notary, que atualmente está em incubação.

O DCT permite assinar e verificar imagens de contêiner, garantindo a integridade e a autenticidade de tags específicas de imagem por meio de verificação no cliente ou em tempo de execução.

O Notary v1 funciona adicionando sua chave pública ao registro e assinando a imagem com a chave privada correspondente antes de enviá-la. Em seguida, os usuários podem verificar a imagem comparando a chave pública com os dados obtidos pelo grupo de comandos do registro. Além disso, você pode automatizar as cadeias de suprimentos de software assinando o conteúdo como parte do processo de lançamento.

Notary v2

O sistema de assinatura Notary v2 é uma versão nova e aprimorada, criada para superar as limitações de sua antecessora. Com o Notation e o Notary v2, os usuários podem criar e integrar suas próprias implementações das especificações aos fluxos de trabalho de assinatura e verificação, para assinar vários artefatos (ou seja, imagens de contêiner, listas de materiais de software e resultados de varreduras). Isso foi possível graças a um grupo formado em dezembro de 2019, cujo objetivo é aprimorar a experiência de assinatura de imagens e resolver problemas como o suporte a vários registros e a movimentação de imagens entre registros com a implementação original do v1.

O Notary v2 é relativamente novo e foi lançado em dezembro de 2022. Seu objetivo é funcionar como uma especificação entre setores e registros para assinar e verificar qualquer imagem da Open Container Initiative (OCI) ou artefato de registro. O projeto ainda está em desenvolvimento, e novos recursos serão adicionados no futuro.

Comparação entre Cosign, Notary v2 e Docker Content Trust

Neste artigo, apresentamos quatro características essenciais para ajudar você a determinar qual ferramenta atende melhor às suas necessidades:

  1. O modelo de delegação de confiança é o mecanismo usado para estabelecer e distribuir a confiança entre os artefatos e o registro de artefatos, garantindo sua integridade e autenticidade.

  2. Transparência e auditabilidade são a capacidade de observar e verificar ações e alterações no sistema, garantindo responsabilização e integridade.

  3. Facilidade de uso inclui a simplicidade e a facilidade de uso das ferramentas de assinatura, que favorecem sua adoção e integração.

  4. Suporte da comunidade abrange o nível de participação, colaboração e recursos oferecidos pela comunidade em torno do sistema, contribuindo para seu desenvolvimento contínuo e para a prestação de assistência.

Cada um desses fatores pode afetar significativamente a eficácia de cada ferramenta. Nas próximas seções, analise cada categoria e avalie as ferramentas com base nesses fatores.

Modelo de delegação de confiança

O Cosign usa um modelo descentralizado e federado de delegação de confiança, com uma raiz de confiança composta por certificados e chaves públicas fornecidos pelo projeto Sigstore. O The Update Framework (TUF) é usado para distribuir e obter o material de chaves. A raiz de confiança do Sigstore também é usada para verificar provas de inclusão no Rekor.

Em comparação, o Notary v1 e v2 usam um modelo hierárquico de delegação de confiança, que envolve a distribuição de imagens usando TUF. Nesse modelo, um repositório de confiança armazena as identidades confiáveis.

Para produzir artefatos no v2, usuários ou administradores configuram a política de confiança para definir quais identidades são consideradas confiáveis. A autenticidade dos artefatos assinados é determinada com base na confiança derivada das identidades no repositório e na política de confiança.

No v1, o DCT usa uma chave offline como fonte de confiança para as tags de imagem. A confiança é delegada a chaves de repositório ou de tag, enquanto chaves gerenciadas pelo servidor oferecem segurança adicional. Esse modelo permite diferentes níveis de confiança no sistema para aplicar políticas de segurança e controles de acesso distintos.

Em resumo, como o Cosign prioriza a confiança descentralizada e federada, com uma raiz de confiança fornecida pelo Sigstore, é uma boa opção para a delegação de confiança. Ele implementa um esquema de descoberta baseado em tags e é compatível com a maioria dos registros de produção. Já o Notary v1 é uma boa escolha quando não há necessidade de compatibilidade com vários registros, pois não existe interoperabilidade entre eles. Se você precisa de interoperabilidade, o v2 oferece esse recurso e permite distribuir a confiança entre diferentes registros.

Transparência e auditabilidade

Em termos de transparência e auditabilidade, o Sigstore oferece um sistema seguro e transparente para atualizações de software, armazenando todas as assinaturas em um registro público. Assim, as organizações podem verificar facilmente a autenticidade das atualizações. Além disso, com o Rekor, todos os eventos de assinatura podem ser auditados publicamente, contribuindo para a responsabilização e a confiança na cadeia de suprimentos de software.

Em comparação, o DCT tem algumas desvantagens. Ele aceita apenas uma assinatura por imagem. Isso significa que, se o fornecedor já tiver assinado a imagem no Docker Hub, você não poderá adicionar sua própria assinatura para indicar que ela é adequada à sua organização. Isso pode limitar sua flexibilidade e seu controle sobre a cadeia de suprimentos de software.

Já o Notary v2 adota uma abordagem mais abrangente para manter a confiança em todo o ecossistema. Ele questiona a suposição de que imagens obtidas diretamente do Docker Hub são seguras por natureza. Ao permitir várias assinaturas, o Notary v2 possibilita validar a segurança das imagens e registrar o selo de aprovação da própria organização, aumentando a confiança na cadeia de suprimentos de software.

No momento da publicação deste artigo, o Notary v2 1.0.0 está na fase de release candidate, mas ainda não teve um lançamento geral. Por isso, em ambientes novos e complexos, o Sigstore pode ser uma opção melhor, graças à sua maturidade e às integrações disponíveis.

Facilidade de uso

O Cosign busca oferecer uma experiência simples, facilitando o gerenciamento de chaves e o processo de assinatura. Além disso, os desenvolvedores podem integrá-lo facilmente ao fluxo de trabalho existente durante a criação de imagens. A assinatura sem chave elimina a complexidade do gerenciamento de chaves e, graças ao par de chaves pública e privada gerado pelo cosign, as etapas de implementação são simples.

Em comparação, o Notary se integra perfeitamente ao ecossistema de contêineres Docker e oferece ferramentas de linha de comando e APIs para assinar e verificar contêineres. No entanto, por ser relativamente novo, é compatível com poucos clientes além do Notation. Além disso, nas duas versões do Notary, é preciso gerenciar muitas chaves, o que exige um bom conhecimento prático do TUF.

Já o DCT é estreitamente integrado à Docker, o que facilita habilitar a assinatura e a verificação de imagens com comandos intuitivos. Porém, ele não funciona entre registros, e os dados de assinatura são perdidos quando uma imagem pública é obtida e enviada para um registro privado sem um servidor Notary associado. Além disso, configurar um serviço Notary exige um servidor Notary, um assinador Notary, um cliente Notary e um banco de dados MySQL, além de mTLS (TLS mútuo) entre o servidor e o assinador Notary. Isso costuma exigir esforço adicional, e há previsões de que o serviço desapareça à medida que o v2 se torne mais popular.

Em termos de facilidade de uso, o Cosign parece levar vantagem graças à abordagem simples, ao gerenciamento de chaves simplificado e à integração com os fluxos de trabalho existentes. O Notary v2 também oferece integração e ferramentas de linha de comando, mas exige mais esforço e conhecimento para configurar e gerenciar do que o DCT. Por outro lado, ele vem com o docker trust, que é muito fácil de usar.

Suporte da comunidade

Todos os projetos fazem parte da CNCF, o que significa que contam com bom apoio da comunidade. O Cosign, porém, também recebe apoio de parceiros do setor e tem uma comunidade ativa de contribuidores, que garante desenvolvimento contínuo, suporte e colaboração. O Notary também é um projeto de código aberto com forte apoio da comunidade e é amplamente usado no ecossistema Docker, beneficiando-se das contribuições e do feedback de uma grande base de usuários. Como o projeto v2 é relativamente novo, há menos documentação e tutoriais disponíveis do que para as outras soluções, o que pode dificultar o aprendizado e o uso do v2 por novos usuários com CLIs como o Notation.

O DCT faz parte da plataforma Docker e conta com a ampla comunidade Docker. Ele conquistou bastante espaço e tem um ecossistema robusto de ferramentas e integrações, o que facilita sua adoção. Além disso, há vários tutoriais para ajudar você a começar.

E o vencedor é…

A escolha depende dos requisitos, das prioridades e das limitações específicas da organização ou do sistema com que você trabalha. O Sigstore é uma boa opção para organizações que priorizam atualizações de software seguras e transparentes para diversos artefatos, incluindo gráficos do Helm, além de imagens. Ele conta com forte apoio da comunidade e recursos como a interoperabilidade entre registros, sendo uma ótima opção para a maioria das organizações. Além disso, a maioria dos registros de contêiner é compatível com o formato de assinatura.

Em comparação, o DCT se destaca em cenários nos quais a simplicidade e a integração perfeita com o Docker são essenciais. Sua integração estreita com o Docker e seus comandos intuitivos facilitam a assinatura e a verificação de imagens, sem exigir modelos de confiança complexos nem interoperabilidade entre diferentes registros.

O Notary v2 oferece uma solução mais abrangente para manter a confiança na cadeia de suprimentos de software e trata das limitações do DCT. No entanto, como ainda está em desenvolvimento, sua implementação em uma organização pode exigir planejamento e consideração cuidadosos. O processo de configuração e o gerenciamento de certificados TLS e chaves TUF podem ser complexos, exigindo um aprendizado mais longo e se tornando um ônus operacional se não forem configurados corretamente. Além disso, nem todos os registros oferecem suporte a ele, então talvez seja necessário fazer algumas concessões caso você escolha usá-lo.

Como assinar com o Cosign

Agora que você já sabe um pouco mais sobre Cosign, Notary e DCT, vamos avançar um passo e usar uma dessas ferramentas: Cosign. Neste exemplo, usaremos a imagem de referência Docker simples registry:2 para executar um registro básico. Em um cenário real, você pode usar um registro gerenciado, como Harbor, Amazon ECR, Docker Hub etc.

Pré-requisitos

Antes de começar, instale as seguintes ferramentas:

  • Cosign: a ferramenta que você usará para assinar e verificar imagens de contêiner.

  • Docker: uma ferramenta para criar, executar e gerenciar contêineres Docker.

Depois de instalar as duas ferramentas, é hora de começar!

Configure um registro

Para armazenar suas imagens, crie uma instância de registro usando a imagem de referência Docker registry:2.

docker run -d -p 15000:5000 --name registry registry:2

Observação: aqui, vinculamos a porta local 15000 para evitar conflitos — especialmente em computadores Mac, nos quais versões recentes usam a porta 5000 para os serviços do AirDrop. Se preferir, você pode alterá-la para qualquer porta disponível na sua máquina, mas use a mesma porta nos comandos seguintes.

Envie uma imagem para o registro

Para assinar uma imagem Docker e enviá-la ao registro, siga estas etapas:

Baixe uma imagem de qualquer registro público (neste exemplo, usamos o BusyBox):

docker pull busybox

Este comando busca a imagem BusyBox no registro público do Docker.

Em seguida, marque a imagem com o endereço IP do seu registro local:

docker tag busybox localhost:15000/library/busybox:latest

Depois, para enviar a imagem, faça push da imagem assinada para o seu registro Harbor:

docker push localhost:15000/library/busybox:latest

Este comando envia a imagem marcada para o seu registro Harbor usando o comando docker push. Na resposta, você deverá ver um hash SHA-256 parecido com este:

The push refers to repository [localhost:15000/busybox]
3694737149b1: Pushed
latest: digest: sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11 size: 528

Copie o valor do resumo, começando em sha256: e indo até o final da sequência (não inclua o espaço nem “size” depois dela). Esse é o hash criptográfico da imagem, que usaremos na próxima etapa para garantir que estamos assinando exatamente a imagem que acabamos de enviar.

Depois de seguir estas etapas, você terá enviado uma imagem Docker ao seu registro, deixando-a disponível para implantação e distribuição no seu ambiente. No entanto, ainda será necessário assiná-la.

Assine a imagem enviada

Antes de assinar uma imagem de contêiner enviada usando o Cosign, gere um par de chaves pública e privada. Execute o comando a seguir para gerar as chaves usadas na assinatura:

cosign generate-key-pair

Depois de executar o comando anterior, você deverá definir uma senha para a chave privada e confirmá-la. A chave privada será salva em um arquivo chamado cosign.key, e a chave pública, em cosign.pub. Guarde com segurança a chave privada e a senha definida.

Em seguida, use o comando cosign sign para assinar a imagem:

cosign sign --key cosign.key localhost:15000/library/busybox@[sha256 digest]

Se você mudou de diretório, substitua cosign.key pelo caminho do arquivo da sua chave privada e [sha256 digest] pelo valor completo do hash copiado na etapa anterior. Será solicitada a senha da chave privada; digite-a para continuar.

Ao assinar a imagem com o Cosign, você garante que ela esteja atualizada, seja autêntica e mantenha sua integridade. Isso adiciona uma camada extra de segurança às imagens de contêiner e ajuda a manter a confiança na cadeia de suprimentos de software.

Verifique a imagem assinada

Para verificar a imagem assinada, use o comando integrado cosign verify:

cosign verify --key cosign.pub localhost:15000/library/busybox@[sha256 digest]

Provavelmente, serão exibidas algumas perguntas de sim ou não sobre o uso de um registro privado e a aceitação dos termos de uso do projeto Sigstore. Leia as perguntas e responda conforme apropriado.

WARNING: "localhost:15000/library/busybox" appears to be a private repository, please confirm uploading to the transparency log at "https://rekor.sigstore.dev"
Are you sure you would like to continue? [y/N] y

	The sigstore service, hosted by sigstore a Series of LF Projects, LLC, is provided pursuant to the Hosted Project Tools Terms of Use, available at https://lfprojects.org/policies/hosted-project-tools-terms-of-use/.
…
By typing 'y', you attest that (1) you are not submitting the personal data of any other person; and (2) you understand and agree to the statement and the Agreement terms at the URLs listed above.
Are you sure you would like to continue? [y/N] y

Se a assinatura for validada com sucesso, você verá uma mensagem de confirmação informando que a imagem foi assinada e verificada com segurança. A mensagem será semelhante a esta:

Verification for localhost:15000/library/busybox@sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"localhost:15000/library/busybox"},"image":{"docker-manifest-digest":"sha256:1fa89c01cd0473cedbd1a470abb8c139eeb80920edf1bc55de87851bfb63ea11"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEUCIQC9yxeo0hGggaWFwBKe4ERHz62emuyqIKNqa1kbPMvNqgIgVea7Fu1zFMqXGYWbacV+gJrVLDUTbchiDdKqcUpEgRk=","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEi
…

Essa mensagem de confirmação é essencial para manter uma postura de segurança robusta na sua organização.

Assine outros artefatos

Embora as imagens de contêiner sejam uma parte essencial das cadeias de suprimentos de software, assinar outros artefatos também é importante para garantir a segurança de ponta a ponta. Além das imagens de contêiner, vários tipos de artefatos de software — como executáveis, arquivos Java Archive (JAR), pacotes e listas de materiais de software (SBOMs) — podem se beneficiar do processo de assinatura. Por exemplo, veja este tutorial sobre como o Cosign oferece suporte à assinatura de SBOMs.

A assinatura de outros artefatos oferece os mesmos benefícios que você já conhece, incluindo integridade, atualidade e proveniência, ajudando a atender a requisitos de conformidade e auditoria ou a servir como referência. No entanto, é importante observar que o processo pode não ser tão simples quanto a assinatura de contêineres. No caso de SBOMs, por exemplo, a assinatura é feita com o Cosign depois que elas são anexadas à imagem de contêiner hospedada em um registro.

Para artefatos como arquivos JAR, é possível usar ferramentas como o Jarsigner. O processo é um pouco mais complexo do que a assinatura tradicional de imagens, pois envolve etapas adicionais para gerar, armazenar, transferir e usar chaves e assinaturas com segurança.

Conclusão

Embora a assinatura de diferentes artefatos possa trazer complexidades adicionais, é importante entender que essas etapas existem para aumentar a segurança, a integridade e a conformidade dos artefatos de software. Ao incorporar assinaturas digitais e seguir as práticas recomendadas de gerenciamento de chaves, as organizações podem estabelecer confiança, atender aos requisitos de conformidade e facilitar auditorias e consultas, protegendo-se contra grandes riscos de segurança.

Para começar a reduzir os riscos de segurança das suas imagens e protegê-las contra adulterações, assinar contêineres é um bom primeiro passo. As diferentes ferramentas abordadas neste artigo atendem a vários grupos de usuários, e sua escolha deve levar em conta o nível de eficácia e flexibilidade exigido pelos seus padrões de segurança e conformidade. Depois de implementar a assinatura de imagens, você pode usar soluções para verificar e auditar a segurança das camadas das imagens.

Por exemplo, a Snyk é uma plataforma de segurança para desenvolvedores que prioriza uma experiência fluida para quem desenvolve. Ela oferece recursos de análise de imagens de contêiner, permitindo identificar vulnerabilidades conhecidas nos pacotes incluídos na imagem Docker. Assim, você pode detectar e corrigir vulnerabilidades de forma proativa antes de enviar a imagem para o Docker Hub ou qualquer outro registro, fortalecendo sua postura geral de segurança.

Segurança de contêineres que prioriza os desenvolvedores

O Snyk encontra e corrige automaticamente vulnerabilidades em imagens de contêiner e workloads do Kubernetes.

Leia mais

feature customer snowflake
Article

Segurança desde o início: conheça a integração do Snyk Studio com o Snowflake Cortex Code

O Snyk Studio se integra ao Snowflake Cortex Code para detectar vulnerabilidades em código gerado por IA, dependências e contêineres durante o desenvolvimento.

blog feature pypi spoof
Article

A Snyk AI Security Platform completa, grátis para mantenedores de projetos open source

Mantenedores de projetos open source estão sobrecarregados com relatórios reais de vulnerabilidades e precisam de ajuda para priorizar, corrigir e lançar correções mais rápido. O Secure Developer Program da Snyk dá aos projetos qualificados acesso gratuito à Snyk AI Security Platform.

feature insights announcement
Blog

Comprometimento da cadeia de suprimentos do node-gyp: um worm npm que se autopropaga e se esconde em binding.gyp

Um novo worm do npm está explorando binding.gyp para acionar o node-gyp durante a instalação, permitindo que pacotes maliciosos executem código sem scripts de ciclo de vida. Ele rouba credenciais, mantém persistência no GitHub e se propaga entre contas de mantenedores.