Cosign e External Secrets Operator: uma base de supply chain Kubernetes para MSPs

Este guia reúne dois controles open source que os MSPs podem aplicar em uma frota Kubernetes gerenciada: assinar e verificar imagens de contêiner com o Sigstore Cosign, e manter credenciais fora do Git com o External Secrets Operator. Juntos, eles fecham duas das lacunas mais comuns em uma supply chain Kubernetes — imagens não verificadas e segredos fixados nos manifests — sem exigir uma nova plataforma ou dependência de fornecedor.

Assinar no build, verificar no deploy

O Cosign, parte do projeto open source Sigstore, assina e verifica imagens de contêiner para que um cluster Kubernetes possa confirmar que uma imagem realmente veio de um pipeline de build aprovado antes de ser executada. O padrão que importa para os MSPs é simples: assine cada imagem no momento do build, verifique essa assinatura na admissão ou no deploy, e rejeite tudo o que não for validado.

A assinatura pode usar chaves de longa duração controladas pela equipe de segurança, ou o fluxo keyless do Sigstore, em que o Fulcio emite um certificado de curta duração que vincula uma chave efêmera a uma identidade OpenID Connect verificada — um sistema de CI ou uma pessoa — enquanto o registro de transparência Rekor carimba o evento com data e hora. A verificação acontece no ponto em que a imagem está prestes a ser executada: um admission controller ou um gate de deploy checa a assinatura contra uma identidade ou chave aprovada, e bloqueia o que não estiver assinado ou confiável antes que alcance um cluster gerenciado.

O que a assinatura não substitui

Uma assinatura prova a procedência — que um digest específico veio de um pipeline ou identidade específica — mas não diz nada sobre se esse digest contém vulnerabilidades conhecidas. O Cosign deve atuar ao lado de um scanner de imagens como Trivy ou Grype, não em seu lugar: o scanner avalia o que há dentro da imagem, a assinatura prova de onde ela veio. Tratar "assinado" como sinônimo de "seguro" deixa metade do controle descoberta.

Mantendo segredos fora do Git com o External Secrets Operator

O External Secrets Operator é um controller Kubernetes que conecta gerenciadores externos de segredos — entre eles AWS Secrets Manager, HashiCorp Vault e Azure Key Vault — a Secrets nativos do Kubernetes, de forma que as credenciais não precisem mais ficar em um repositório Git ou em um chart Helm. Ele observa um recurso SecretStore ou ClusterSecretStore e sincroniza valores para os Secrets do Kubernetes conforme uma programação, sem que o próprio operador precise registrar o texto em claro.

Limitar cada ExternalSecret ao namespace e à carga de trabalho que realmente precisa dele reduz o raio de impacto caso um pod seja comprometido. O operador ainda depende dos controles de acesso e da política de rotação do próprio gerenciador de segredos: ele tira as credenciais do controle de versão, mas não substitui a segurança desse gerenciador.

Por que essa combinação importa para os MSPs

Frotas Kubernetes gerenciadas costumam acumular os dois problemas ao mesmo tempo: segredos fixados por conveniência e imagens baixadas de um registry sem verificação de assinatura. Integrar o External Secrets ao caminho de deploy elimina a desculpa de guardar credenciais em manifests, enquanto uma política de admissão do Cosign dá ao MSP um único gate auditável para saber se uma imagem veio do seu próprio pipeline.

Nenhuma das duas ferramentas é, sozinha, um programa de segurança completo. A verificação do Cosign vale o que valem o gerenciamento de chaves e a confiança nos emissores por trás dela, e privilégio mínimo, segmentação de rede e resposta a incidentes continuam sendo trabalhos separados. Combinados, porém, os dois controles formam uma base repetível aplicável por tenant, com um processo de exceção documentado para o que ainda não está em conformidade.

MSPs que precisam demonstrar que esses controles resistem a uma auditoria podem recorrer aos serviços de cibersegurança da Altovar, que cobrem testes de penetração, avaliação de vulnerabilidades, resposta a incidentes e conformidade com NIS2/DORA/GDPR.

O que fazer

• Assine cada imagem no momento do build e verifique-a novamente na admissão ou no deploy; nunca confie apenas na assinatura da etapa de build.
• Teste primeiro o caminho de falha: confirme que uma imagem não assinada ou adulterada é realmente rejeitada antes de confiar no gate em produção.
• Combine o Cosign com um scanner de vulnerabilidades como Trivy ou Grype, porque uma assinatura válida não equivale a uma varredura limpa.
• Tire cada credencial dos manifests e dos charts Helm e leve-a para um SecretStore gerenciado pelo External Secrets Operator.
• Limite cada ExternalSecret ao namespace e à carga de trabalho que precisa dele, e rotacione chaves ou credenciais conforme uma programação definida.
• Documente o processo de exceção para o que ainda não está em conformidade, e valide mudanças de política em um cluster fora de produção antes de aplicá-las a toda a frota.

Fontes: GitHub — sigstore/cosign, documentação do Sigstore, External Secrets Operator no GitHub.