O que é infra assinado na prática
Infra assinado refere-se ao uso de assinatura digital em componentes de infraestrutura — containers, pacotes, imagens de VM, scripts de provisionamento, artefatos de build. A ideia é garantir que o que você está implantando em produção veio de uma fonte confiável e não foi alterado no caminho. No Brasil, esse conceito ganhou força com a migração para repositórios privados, a adoção de Kubernetes e a necessidade de atender requisitos de compliance como LGPD e normas setoriais de bancos e órgãos públicos.
infra assinado ou infra assinado — entenda a diferença de termos
A dúvida mais comum é entre "infra assinado" e "infra assinado". Na verdade são a mesma coisa, só variação de grafia. O termo correto tecnicamente não varia. O que muda é o contexto: alguns times chamam de "código assinado", outros de "artefato assinado". O mecanismo por trás é idêntico — uma chave privada assina o artefato, uma chave pública verifica a assinatura. Deixa eu explicar como isso funciona no dia a dia, porque a teoria é simples mas a implementação costuma doer.
Como assinar infraestrutura na prática
O fluxo básico é: gerar um par de chaves, assinar o artefato com a chave privada, fazer com que o ambiente de destino verifique com a chave pública. O que todo mundo erra é pensar que gerar a chave já resolve. Não resolve. A parte difícil é gerenciar o ciclo de vida das chaves, rotacionar sem quebrar deployments em andamento, e garantir que o pipeline inteiro respeite a verificação. Para containers, o padrão que mais se usa hoje é o Cosign, que faz parte do ecossistema sigstore. Ele suporta assinatura com chaves tradicionais (SKS/OpenPGP) e também com keyless, usando OIDC. O keyless é interessante porque elimina a necessidade de armazenar chaves privadas em algum segredo, mas tem seus próprios pontos de atenção que vou mencionar.
Para pacotes Debian/Ubuntu, existe o APT Signing. Para Red Hat, o RPM gpg check. Para Terraform providers, o provider signature verification pelo Open Policy Agent ou pelo próprio provedor. Cada ecossistema tem sua ferramenta. Você não vai padronizar tudo num Dia U, vai implementar por camada. Aqui vai um exemplo concreto de pipeline com Cosign para um container:
Gere as chaves uma vez: cosign generate-key-pair. Isso cria dois arquivos — o certificado e a chave privada. Guarde eles em algum cofre seguro, não no repositório. Eu vejo gente jogando no git todo dia. Não faça isso. No pipeline de build, depois de fazer push da imagem:
👉 Clique no botão abaixo para saber mais sobre o assunto!
cosign sign --key cosign.key --yes registry.seu-domínio/seu-imagem:tag No cluster de destino, configure o policy controller do Kyverno ou o admission webhook do gatekeeper para exigir assinatura verificada antes de permitir a criação de pods com aquela imagem. Sem isso, a assinatura é só um selo decorativo. Alguém pode rodar qualquer coisa que não foi assinada e seu controle zero.
Pegadinhas que ninguém conta
Uma coisa que eu aprendi na marra: a verificação de assinatura não protege contra imagens construídas a partir de bases comprometidas. Se o Ubuntu base do seu Dockerfile foi construído num builder que já estava comprometido, a assinatura do Cosign vai passar tranquilamente porque ela atesta a integridade da imagem final, não a procedência dos camadas intermediários ou do builder. Isso é um limite importante que poucos entendem. Outro ponto: a rotatividade de chaves. Um colega meu trabalhou numa migração onde a chave de assinatura tinha 3 anos. Quando decidiram rodar a rotação, esqueceram de atualizar a policy no cluster de homologação. O deploy foi para homolog, a política bloqueou tudo, e o time passou 4 horas rastreando o erro achando que era problema de rede. A solução foi ter um procedimento de runbook documentado com checklist de todos os ambientes que precisam ser atualizados simultaneamente — não apenas produção.
Se você está começando do zero e não quer gerenciar chaves, o keyless do sigstore é uma alternativa viável. Ele usa OIDC do GitHub Actions ou do GitLab CI para emitir attestations temporárias. O problema é que depende de um servidor de certificados online (fulcio) e de um transparency log (rekor). Se esses serviços estiverem fora do ar, sua pipeline quebra. Para ambientes air-gapped ou com restrições severas de saída de rede, isso é um risco real.
Quando não usar infra assinado
Não adianta fingir que é bala de prata. Em times pequenos, com pipelines simples e confiança já estabelecida entre quem faz commit e quem sobe pra produção, a sobrecarga de manter assinatura digital pode ser maior que o benefício percebido. Se você é um dev solo rodando coisas num VPS, talvez não valha a pena. O custo real começa a aparecer quando você tem mais de cinco repositórios, múltiplos pipelines, e times diferentes tocando cada um. Aí a governança de chaves vira um trabalho em tempo integral se não for bem estruturado desde o início.
Resumo prático
Infra assinado é sobre criar uma corrente de confiança do commit até o pod rodando. O Cosign para containers e o GPG para pacotes de sistema são as ferramentas mais acessíveis hoje. A parte crítica não é assinar — é fazer o cluster verificar essa assinatura automaticamente, manter as chaves com ciclo de vida controlado, e entender os limites do que a assinatura protege. Quem pula essas etapas acaba com uma falsa sensação de segurança.
