GCP
Secure Software Supply Chain no Google Cloud: Binary Authorization, Cloud KMS e GKE na pratica
Engineering Handbook ? Capitulo 07
Iury Coelho24 min de leitura
GCP
Engineering Handbook ? Capitulo 07
Iury CoelhoGoogle Cloud Master Journey 2026
Engineering Handbook · Capítulo 07
Como construí uma cadeia de confiança para contêineres usando Artifact Registry, Artifact Analysis, Cloud Build, Cloud KMS, Binary Authorization e Google Kubernetes Engine.
Este artigo faz parte da série Google Cloud Master Journey 2026, em que estou transformando laboratórios práticos em capítulos de um Engineering Handbook sobre Cloud Engineering, DevSecOps, arquitetura e segurança.
A proposta não é apenas registrar comandos ou badges. O objetivo é responder perguntas de engenharia:
Neste capítulo, o tema é segurança da cadeia de suprimentos de software com Binary Authorization.
O laboratório usado como base foi Gating Deployments with Binary Authorization (GSP1183).
Durante a prática, construí uma cadeia de confiança com os seguintes componentes:
ALWAYS_ALLOW, ALWAYS_DENY e REQUIRE_ATTESTATION;O laboratório demonstra uma ideia simples, mas poderosa:
Construir uma imagem não é suficiente. Antes do deploy, precisamos provar que ela passou pelos processos exigidos pela organização.
Em pipelines tradicionais, o fluxo costuma ser:
Código → build → push → deployEsse fluxo responde à pergunta:
Onde está a imagem que deve ser executada?
Mas não responde às perguntas mais importantes:
Tags como latest, good ou release são nomes convenientes, mas não constituem prova de integridade. Uma tag pode apontar para outro conteúdo no futuro.
O identificador realmente importante é o digest:
sha256:710fa3e39078d2347deb1999115ce2cfe1ecfbfbf811447cb6a9b410feccec06O digest identifica o conteúdo da imagem. Se o conteúdo mudar, o digest muda.
Por isso, a assinatura e a attestation são associadas ao digest, não apenas à tag.
Uma cadeia de suprimentos de software inclui tudo o que participa da criação e entrega do sistema:
Cada transição é uma oportunidade para introduzir uma alteração não autorizada.
Binary Authorization não protege todos esses pontos sozinho. Sua função principal é atuar como um controle no momento da implantação, verificando se o artefato atende às políticas definidas antes de chegar ao runtime.
Binary Authorization é o mecanismo do Google Cloud para aplicar políticas de confiança a imagens de contêiner no momento do deploy.
Ele possui três ideias centrais:
Policy
Define as condições que uma imagem precisa cumprir.
Attestation
Registra que uma atividade exigida foi concluída para uma imagem específica.
Enforcement
Permite ou bloqueia a implantação conforme a política.
No laboratório, a política final exigia uma attestation emitida por vulnz-attestor.
O fluxo pode ser resumido assim:
Build cria a imagem
→ registry armazena a imagem
→ KMS assina o digest
→ Artifact Analysis armazena a evidência
→ Attestor verifica a assinatura
→ Binary Authorization aplica a política
→ GKE aceita ou bloqueia o deployO primeiro recurso criado foi um repositório Docker:
gcloud artifacts repositories create artifact-scanning-repo \
--repository-format=docker \
--location=us-central1 \
--description="Docker repository"Depois, o Docker foi configurado para autenticar no registry:
gcloud auth configure-docker us-central1-docker.pkg.devA imagem foi construída e enviada pelo Cloud Build:
gcloud builds submit . \
-t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-imageO Artifact Registry resolve armazenamento, distribuição, IAM e integração com outros serviços do Google Cloud.
Mas ele não decide sozinho se uma imagem pode chegar à produção.
Essa decisão pertence à política de implantação.
O laboratório usa o nome histórico Container Analysis API. Atualmente, o produto é apresentado como Artifact Analysis, embora APIs e recursos existentes ainda usem nomes como containeranalysis.googleapis.com.
Artifact Analysis associa metadados a artefatos por meio de duas entidades:
Uma Note descreve um tipo de informação ou declaração.
Exemplos:
No laboratório:
{
"attestation": {
"hint": {
"human_readable_name": "Container Vulnerabilities attestation authority"
}
}
}A Note não representa a aprovação de uma imagem específica. Ela representa o tipo de aprovação.
Uma Occurrence é a aplicação daquela Note a um artefato específico.
Para Binary Authorization, a Occurrence contém a attestation e sua assinatura.
Note = o que significa a aprovação
Occurrence = onde essa aprovação ocorreu
Attestation = a evidência assinada sobre a imagemEsses termos são parecidos e frequentemente confundidos.
É a autoridade que o Binary Authorization considera confiável para verificar attestations.
Pode representar:
gcloud container binauthz attestors create vulnz-attestor \
--attestation-authority-note=vulnz_note \
--attestation-authority-note-project=${PROJECT_ID}O Attestor possui ou referencia a chave pública usada na verificação.
É uma declaração assinada sobre uma imagem específica.
Ela registra, em essência:
A autoridade X afirma que a imagem de digest Y cumpriu o processo Z.
Uma attestation não torna uma imagem segura por mágica. Ela comprova que determinada autoridade assinou uma declaração sobre aquele digest.
A confiança depende da qualidade do processo que antecede a assinatura.
A chave criada no laboratório tinha:
purpose: asymmetric-signing
algorithm: ec-sign-p256-sha256gcloud kms keys create codelab-key \
--keyring=binauthz-keys \
--location=global \
--purpose=asymmetric-signing \
--default-algorithm=ec-sign-p256-sha256Em criptografia assimétrica:
A vantagem de usar Cloud KMS é que a chave privada permanece gerenciada pelo serviço. O pipeline recebe permissão para solicitar operações de assinatura, em vez de copiar uma chave privada para arquivos, variáveis ou runners.
Depois de construir a imagem, o laboratório resolveu a tag para um digest:
CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
--format='get(image_summary.digest)')Em seguida, assinou e registrou a attestation:
gcloud beta container binauthz attestations sign-and-create \
--artifact-url="${CONTAINER_PATH}@${DIGEST}" \
--attestor="${ATTESTOR_ID}" \
--attestor-project="${PROJECT_ID}" \
--keyversion-project="${PROJECT_ID}" \
--keyversion-location="${KEY_LOCATION}" \
--keyversion-keyring="${KEYRING}" \
--keyversion-key="${KEY_NAME}" \
--keyversion="${KEY_VERSION}"A saída do laboratório mostrou:
resourceUri apontando para o digest;noteName associado à Note;publicKeyId apontando para a versão da chave KMS;ATTESTATION.Esse foi o primeiro fechamento completo da cadeia de confiança.
O laboratório explorou três modos.
ALWAYS_ALLOWPermite imagens independentemente de attestations.
defaultAdmissionRule:
evaluationMode: ALWAYS_ALLOW
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOGÉ útil como estado inicial, mas não oferece gating real.
ALWAYS_DENYBloqueia imagens que chegam à regra.
defaultAdmissionRule:
evaluationMode: ALWAYS_DENY
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOGEsse teste demonstrou que o controle estava realmente na admissão do GKE.
REQUIRE_ATTESTATIONExige aprovação por uma autoridade confiável.
defaultAdmissionRule:
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
evaluationMode: REQUIRE_ATTESTATION
requireAttestationsBy:
- projects/PROJECT_ID/attestors/vulnz-attestorEssa é a política central do laboratório.
globalPolicyEvaluationMode: ENABLEO laboratório manteve:
globalPolicyEvaluationMode: ENABLEIsso permite que a política do sistema mantida pelo Google seja avaliada, evitando que imagens essenciais do próprio GKE sejam bloqueadas por uma política personalizada muito restritiva.
Desabilitar essa opção exige administrar cuidadosamente as exceções das imagens de sistema. Em produção, manter ENABLE costuma reduzir risco operacional.
Assinar manualmente é útil para entender o modelo, mas não escala.
O laboratório adicionou uma etapa de attestation ao pipeline:
- id: create-attestation
name: gcr.io/${PROJECT_ID}/binauthz-attestation:latest
args:
- --artifact-url
- us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
- --attestor
- projects/${PROJECT_ID}/attestors/vulnz-attestor
- --keyversion
- projects/${PROJECT_ID}/locations/global/keyRings/binauthz-keys/cryptoKeys/codelab-key/cryptoKeyVersions/1O fluxo passou a ser:
A assinatura só deve ocorrer depois das verificações obrigatórias.
Caso o pipeline assine sempre, independentemente dos resultados, a attestation deixa de representar um controle confiável.
O laboratório produziu duas imagens.
goodbadEsse teste é o ponto mais importante do capítulo.
Ele mostra que possuir acesso ao registry não é suficiente para implantar em produção.
O experimento comprovou cinco capacidades:
Identidade do artefato
A decisão foi tomada usando o digest.
Assinatura criptográfica
A chave privada do KMS assinou a declaração.
Autoridade confiável
O Attestor conhecia a chave pública.
Política explícita
O ambiente exigia a attestation.
Enforcement real
A imagem não assinada foi bloqueada.
Para reduzir tarefas repetitivas, transformei o laboratório em um script Bash com:
Check my progress.Isso não substitui o entendimento. Pelo contrário: depois de compreender o fluxo manual, automatizar tornou visíveis as dependências operacionais entre serviços.
O laboratório é excelente para demonstrar o conceito, mas simplifica decisões que seriam obrigatórias em produção.
Ela prova que uma autoridade assinou uma declaração sobre aquele digest.
Se o pipeline de aprovação estiver mal configurado, uma imagem insegura poderá receber uma attestation perfeitamente válida.
Assinatura válida ≠ processo confiávelA segurança depende de:
No laboratório, praticamente tudo ficou em um único projeto.
Em produção, eu separaria responsabilidades:
Uma possível divisão:
security-project
├── Cloud KMS
├── Attestors
└── Notes
build-project
├── Cloud Build
├── Artifact Registry
└── scanners
production-project
├── GKE
├── Binary Authorization policy
└── workloadsEssa separação reduz a possibilidade de uma única identidade controlar build, assinatura e deploy.
O laboratório concede vários papéis à conta de serviço do Cloud Build.
Em produção, eu criaria uma conta de serviço específica para o pipeline e concederia somente:
Também verificaria qual conta de serviço o Cloud Build realmente usa. Projetos novos podem usar a conta padrão do Compute Engine, enquanto projetos antigos podem usar a conta legada do Cloud Build.
O comando útil é:
gcloud builds get-default-service-accountA etapa de assinatura deve ficar depois de:
No laboratório, as tags facilitaram o build. No manifesto final, foi usado o digest.
Em produção, eu manteria:
image: us-central1-docker.pkg.dev/projeto/repo/app@sha256:...Isso evita que um deploy futuro resolva a mesma tag para outro conteúdo.
Uma organização pode exigir múltiplas evidências.
Exemplo:
built-by-trusted-cloud-build
AND
passed-vulnerability-policy
AND
approved-by-release-managementA política deixa de confiar em um único controle.
Existem cenários em que uma organização precisa ignorar temporariamente uma política para responder a uma emergência.
Esse mecanismo não deve ser uma porta lateral informal.
Um processo de breakglass precisa de:
O laboratório verifica a imagem no momento da implantação.
Mas o risco pode mudar depois:
Por isso, além do admission control, ambientes maduros precisam de:
Artifact Analysis permite separar projetos de Notes e Occurrences para aplicar controle de acesso mais granular.
Uma equipe pode ser proprietária da definição da política, enquanto outra apenas cria occurrences quando um processo autorizado é concluído.
Essa separação reduz o risco de o próprio consumidor da evidência fabricar a aprovação que precisa apresentar.
O laboratório clona e constrói um custom build step da comunidade.
Em produção, eu não consumiria automaticamente a versão mais recente de um repositório sem controles adicionais.
Eu faria:
A ferramenta que produz attestations também pertence à cadeia de suprimentos.
Attestations podem declarar que um processo ocorreu. Proveniência descreve de forma verificável onde, quando e como um artefato foi produzido.
Uma arquitetura madura combina:
SLSA fornece um modelo de maturidade para aumentar gradualmente as garantias de integridade da cadeia de build.
Binary Authorization pode atuar como o enforcement final de evidências produzidas por etapas anteriores.
Quando uma imagem é bloqueada, a equipe precisa entender:
Os eventos de Binary Authorization podem ser investigados no Cloud Audit Logs.
Filtro inicial:
protoPayload.serviceName="binaryauthorization.googleapis.com"A política sem observabilidade tende a gerar bypasses, permissões excessivas e frustração operacional.
Para aplicações web e APIs:
GitHub
→ Cloud Build
→ testes
→ scan
→ Artifact Registry
→ attestation
→ Binary Authorization
→ GKE ou Cloud RunEm uma plataforma institucional, o objetivo seria garantir que somente artefatos provenientes do pipeline autorizado chegassem aos ambientes homologados.
Controles possíveis:
Em sistemas que lidam com dados sensíveis, o valor principal seria reduzir risco de implantação não autorizada e melhorar rastreabilidade:
Binary Authorization não resolve sozinho os requisitos de segurança e privacidade, mas fortalece o controle de integridade do software entregue.
Não existe uma equivalência perfeita de um único serviço para Binary Authorization no EKS.
| Capacidade | Google Cloud | AWS |
|---|---|---|
| Registry | Artifact Registry | Amazon ECR |
| Build gerenciado | Cloud Build | AWS CodeBuild |
| Assinatura | Cloud KMS + Attestation | AWS Signer + ECR |
| Scan de imagens | Artifact Analysis | Amazon Inspector / ECR scanning |
| Enforcement no deploy | Binary Authorization | Gatekeeper + Ratify ou Kyverno |
| Runtime Kubernetes | GKE | Amazon EKS |
| Auditoria | Cloud Audit Logs | CloudTrail / CloudWatch |
No Google Cloud, Binary Authorization oferece uma experiência gerenciada e integrada para política e enforcement.
Na AWS, a validação de assinaturas no EKS normalmente é composta por serviços de assinatura e um admission controller Kubernetes.
Uma implementação real pode envolver custos de:
O maior custo, porém, pode ser operacional:
Segurança eficaz precisa ser forte e utilizável.
Ativar uma API ou conceder um papel não significa que o recurso estará imediatamente disponível em todos os serviços.
No script, usei esperas e tentativas para operações que dependiam de propagação.
A criação do GKE foi a etapa mais lenta. A mensagem de health check não representava falha; o cluster ainda estava sendo provisionado.
O comando alertou que resolveu a tag para SHA-256 e recomendou trabalhar diretamente com digest. Esse aviso reforça a diferença entre conveniência e identidade imutável.
As políticas e os manifests Kubernetes dependem de indentação correta. Um espaço fora do lugar pode alterar a estrutura ou invalidar o arquivo.
O laboratório utiliza uma conta de serviço no formato clássico. Em projetos reais, é necessário verificar qual identidade executa os builds e não assumir que será sempre a mesma.
O deploy da imagem bad deveria falhar.
Nesse caso, falha é sucesso: ela prova que a política está ativa.
O laboratório demonstra o mecanismo, mas não responde completamente:
Essas perguntas pertencem à arquitetura operacional, não apenas ao comando gcloud.
Antes de implementar Binary Authorization, eu responderia:
Qual ameaça queremos reduzir?
Push manual, imagem vulnerável, builder comprometido, deploy fora do pipeline ou alteração de dependência?
Qual evidência será exigida?
Build confiável, scan, QA, SBOM, aprovação humana ou combinação?
Quem pode produzir essa evidência?
Uma conta de serviço dedicada, um scanner ou uma equipe?
Onde as chaves ficam?
Qual projeto, quais papéis e qual processo de rotação?
Onde a política é aplicada?
Todos os clusters, somente produção, GKE, Cloud Run ou ambos?
Como exceções funcionam?
Breakglass, tempo de expiração, aprovação e auditoria.
Como medir o resultado?
Deploys bloqueados, violações, tempo de resolução e redução de bypasses.
A tecnologia deve ser consequência do modelo de confiança.
Principais conceitos utilizados neste artigo.
Serviço para armazenar e distribuir imagens e outros pacotes.
Serviço de análise e armazenamento de metadados sobre artefatos. Anteriormente chamado de Container Analysis.
Definição de um tipo de metadado ou declaração.
Instância de uma Note associada a um artefato específico.
Autoridade confiável usada pelo Binary Authorization para verificar attestations.
Declaração assinada que associa uma evidência a uma imagem por digest.
Hash que identifica o conteúdo da imagem.
Serviço gerenciado para criação e uso controlado de chaves criptográficas.
Validação realizada antes que um objeto seja aceito pelo cluster.
Controle de deploy que aplica políticas de confiança a imagens de contêiner.
Informação verificável sobre onde, quando e como um artefato foi produzido.
Framework para aumentar progressivamente garantias de segurança da cadeia de suprimentos.
Mecanismo emergencial de bypass de política, que deve ser restrito e auditado.
O laboratório reforça conhecimentos importantes para profissionais de Cloud, DevOps, DevSecOps e arquitetura:
Mais importante do que memorizar comandos é entender onde a confiança nasce e como ela é verificada.
O laboratório começou com uma aplicação Python simples e terminou com uma cadeia de confiança completa.
A imagem foi:
Em seguida, uma imagem produzida fora do caminho confiável foi bloqueada.
Esse é o principal valor do Binary Authorization:
transformar requisitos de segurança em uma decisão automática e auditável no momento do deploy.
O objetivo não é confiar em uma tag, em uma pessoa ou em um pipeline por convenção.
É exigir evidências verificáveis antes que o software alcance o runtime.
No próximo capítulo da Google Cloud Master Journey 2026, a jornada continua com Secure Builds with Cloud Build.
O foco será aprofundar a segurança do processo de build:
A segurança do deploy começa muito antes do kubectl apply.
As respostas da comunidade chegam em breve.