Meu colega Ying Li e eu recentemente falamos sobre Segurança da Cadeia de Suprimentos de Software e desenhamos a analogia entre as cadeias de suprimentos físicas tradicionais e a criação, a construção e a implantação envolvidas em uma cadeia de suprimentos de software. Acreditamos que um pipeline de software que pode ser verificado em todas as etapas é um passo importante para o aumento da barra de segurança para todos os softwares, e não nos limitamos a simplesmente apresentar a ideia.

Confiabilidade de conteúdo integrado e política de assinatura de imagem

Na recente versão do Docker Datacenter, anunciamos um novo recurso que começa a reunir essas capacidades de segurança ao longo da cadeia de suprimentos de software. Construído no Notary, uma infraestrutura de assinatura baseada no The Update Framework (TUF), juntamente com Docker Content Trust (DCT), uma integração da ferramenta Notary ao cliente Docker, o DDC agora permite que os administradores configurem políticas de assinatura que impedem que conteúdo não confiável seja implementado.

Nessa versão do DDC, o Docker Trusted Registry (DTR) agora também vem com serviços Notary integrados. Isso significa que você está pronto para começar a usar o DCT e os novos recursos de Política de Assinatura fora da caixinha! Nenhum servidor separado e banco de dados para instalar, configurar e conectar ao registro.

Juntando tudo isso

Assinatura de imagem é importante para os criadores de imagem fornecerem uma prova de origem e verificação através de uma assinatura digital daquela imagem. Como uma imagem é construída em camadas e passa por vários estágios diferentes e é tocada por diferentes sistemas e equipes, a capacidade de amarrar tudo isso junto com uma política central garante um maior nível de segurança da aplicação.

Na UI da Web, em configurações, o administrador pode ativar Content Trust para reforçar que somente as imagens assinadas possam ser implantadas no cluster gerenciado pelo DDC. Como parte dessa configuração, o administrador também pode selecionar quais assinaturas são necessárias para que essa imagem seja implantada.

A tela de configuração solicita ao administrador selecionar qualquer número de equipes das quais uma assinatura é necessária. Uma equipe no DDC pode ser definida como sistemas automatizados (Build/CI) ou pessoas em sua organização.

O diagrama abaixo mostra um exemplo de workflow onde as Content Trust Settings são necessárias para verificar a CI e o QA.

• Etapa 1: O desenvolvedor verifica o código e os kicks de um teste de integração. O código passa CI e dispara automaticamente uma nova imagem construída, verifica e sobe para o Docker Trusted Registry (DTR).
• Etapa 2: A equipe QA puxa a imagem do DTR, executa testes adicionais e uma vez concluída (e aprovada), assina e sobe a imagem para DTR.
• Etapa 3: A engenharia de versão vai implantar a imagem no cluster de produção. Como a configuração de Content Trust requer uma assinatura do CI e do QA, o DDC verificará a imagem de ambas as assinaturas e como elas existem (no nosso exemplo) e implantará o container.

Estamos entusiasmados em apresentar esse recurso aos nossos usuários corporativos para aumentar a segurança de sua cadeia de suprimento de software e adicionar um nível de aplicação automatizada de políticas que podem ser configuradas de forma centralizada. À medida que a escala de aplicativos e as equipes crescem, esses recursos ajudam a fornecer garantias com prova de origem de conteúdo, transporte seguro e que os portões de aprovação já haviam sido atendidos antes de serem implantados na produção.

Faça o download da avaliação gratuita de 30 dias do Docker Datacenter para começar hoje.

Saiba mais

• Saiba mais visitando a página do Docker Datacenter
• Veja What’s New in Docker Datacenter
• Leia o blog sobre a Cadeia de Suprimento de Software Seguro
• Inscreva-se para uma licença gratuita de teste de 30 dias

***

Este artigo é do Docker Core Engineering. A tradução do artigo foi feita pela Redação iMasters com autorização, e você pode acompanhar o artigo em inglês no link: https://blog.docker.com/2016/11/image-signing-policy-docker-datacenter/#comment-373297.