A Docker publicou em 16 de junho um guia de migração informando que Docker Content Trust e o serviço Notary v1 em notary.docker.io serão totalmente aposentados. A mudança não afeta o docker pull comum de quem nunca ativou DCT, mas atinge pipelines que dependem de DOCKER_CONTENT_TRUST=1, comandos docker trust, políticas de admissão baseadas em assinaturas DCT ou publicação de imagens assinadas por esse mecanismo.
Segundo a Docker, o DCT foi uma das primeiras formas amplas de verificar integridade e publicador de imagens de container, apoiado em The Update Framework e Notary v1. A empresa já vinha tratando a retirada desde 2025. O problema é que o Notary v1 upstream não é mais mantido e o ecossistema passou a usar ferramentas OCI-native, como Sigstore Cosign e Notation, que armazenam assinaturas junto da imagem no registro compatível.
O cronograma anunciado tem brownouts de escrita em 14 e 15 de julho de 2026, brownouts de leitura em 10 e 12 de agosto de 2026 e desligamento completo em 8 de dezembro de 2026. As janelas duram cerca de quatro horas e começam às 8h do Pacífico. A Docker reforça que essas janelas atingem operações de confiança, não pulls e pushes comuns.
Quem precisa agir
O primeiro grupo é quem publica imagens no Docker Hub com assinatura DCT. Esses times precisam escolher outra forma de assinatura, porque a Docker afirma que não fornecerá assinaturas substitutas em nome dos publicadores. O segundo grupo é quem consome imagens de terceiros e exige assinatura DCT antes de promover uma versão para ambiente real. Nesse caso, a conversa precisa chegar ao fornecedor da imagem.
O terceiro grupo está nos pipelines internos. Variáveis em shell profile, CI, Dockerfile, Compose, scripts antigos e controladores Kubernetes podem continuar carregando DCT sem que o time lembre. Brownout existe justamente para revelar esse acoplamento antes do desligamento definitivo.
Assinatura mudou de lugar
O caminho recomendado pela Docker separa três objetivos. Se a meta imediata é só impedir falha de pull, desativar DCT remove o bloqueio, mas também remove a verificação de publicador. Se a meta é repetibilidade, usar digest impede que uma tag móvel entregue outro conteúdo. Se a meta é provar identidade do publicador, a migração precisa chegar a Cosign ou Notation.
Essa distinção evita uma falsa equivalência. Digest diz qual conteúdo foi baixado; assinatura diz quem assumiu a autoria daquele conteúdo; política de admissão decide se o cluster aceita executar. Um pipeline maduro usa as três camadas em lugares diferentes, sem esperar que uma variável antiga resolva tudo.
Impacto em CI e Kubernetes
Em CI, o risco é simples: uma etapa que assinava ou verificava com Docker Content Trust pode começar a falhar nas datas de brownout e parar de vez no desligamento. Em Kubernetes, o problema pode aparecer como imagem recusada por admission controller ou como bypass silencioso se alguém remover a verificação sem colocar substituto.
O texto sobre Kubernetes, Docker e observabilidade ajuda a colocar essa mudança dentro da operação diária. Já o post sobre Pod Certificates no Kubernetes mostra a mesma direção em outro ponto da cadeia: identidade e confiança precisam acompanhar o workload, não ficar só no procedimento manual.
Plano de migração
O inventário deve começar por repositórios, pipelines e clusters que citam DCT, docker trust ou DOCKER_CONTENT_TRUST. Depois vem a escolha entre Cosign e Notation, a definição de quem assina, onde as chaves ou identidades OIDC vivem, como a assinatura é anexada ao artefato e qual política bloqueia imagem não assinada em produção.
Também vale separar a migração em leitura e escrita. Publicar imagens assinadas exige mudança no pipeline de build; exigir assinatura antes de executar exige mudança na política de consumo. Misturar as duas etapas pode atrasar tudo, especialmente quando a organização consome imagens de terceiros que ainda não escolheram uma alternativa.
A aposentadoria do Docker Content Trust não diz que verificação de imagem perdeu importância. Ela diz que a infraestrutura antiga deixou de ser o lugar certo para isso. Times que usam containers em produção devem tratar junho como início de migração, julho e agosto como ensaio controlado e dezembro como prazo final para remover dependência do Notary v1.
