Secure Software Supply Chain no Google Cloud: Binary Authorization, Cloud KMS e GKE na prática

Google 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:

• qual risco essa arquitetura reduz;
• onde a confiança é criada;
• quem pode aprovar um artefato;
• como a aprovação é verificada no deploy;
• o que muda entre laboratório e produção;
• quais limitações permanecem mesmo depois de assinar uma imagem;
• como transformar o experimento em um modelo operacional para uma empresa.

Neste capítulo, o tema é segurança da cadeia de suprimentos de software com Binary Authorization.

O que vamos construir

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:

• um repositório Docker no Artifact Registry;
• uma aplicação Python empacotada como imagem de contêiner;
• um pipeline no Cloud Build;
• uma Note no Artifact Analysis;
• um Attestor no Binary Authorization;
• uma chave assimétrica no Cloud KMS;
• uma Attestation associada ao digest da imagem;
• um cluster GKE com Binary Authorization habilitado;
• políticas ALWAYS_ALLOW, ALWAYS_DENY e REQUIRE_ATTESTATION;
• um pipeline que cria attestations automaticamente;
• um deploy autorizado de imagem assinada;
• um deploy bloqueado de imagem não assinada.

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.

O problema: uma imagem no registry não é automaticamente confiável

Em pipelines tradicionais, o fluxo costuma ser:

Código → build → push → deploy

Esse fluxo responde à pergunta:

Onde está a imagem que deve ser executada?

Mas não responde às perguntas mais importantes:

• Quem a construiu?
• Qual código-fonte originou o artefato?
• Ela passou pelos testes?
• Foi escaneada?
• Alguém substituiu a tag?
• A imagem que chegou à produção é a mesma que passou pelo pipeline?
• Um usuário poderia fazer push direto no registry e ignorar o CI?

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:710fa3e39078d2347deb1999115ce2cfe1ecfbfbf811447cb6a9b410feccec06

O 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.

O que é uma software supply chain

Uma cadeia de suprimentos de software inclui tudo o que participa da criação e entrega do sistema:

• código próprio;
• bibliotecas de terceiros;
• imagens base;
• repositórios;
• pessoas e identidades;
• sistemas de build;
• ferramentas de teste;
• registries;
• processos de aprovação;
• mecanismos de deploy;
• ambientes de execução.

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.

O que é Binary Authorization

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:

1. Policy
   Define as condições que uma imagem precisa cumprir.

2. Attestation
   Registra que uma atividade exigida foi concluída para uma imagem específica.

3. 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.

Arquitetura completa do laboratório

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 deploy

Artifact Registry: onde o artefato é armazenado

O 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.dev

A imagem foi construída e enviada pelo Cloud Build:

gcloud builds submit . \
  -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

O 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.

Artifact Analysis: metadados sobre o artefato

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:

• Note;
• Occurrence.

Note

Uma Note descreve um tipo de informação ou declaração.

Exemplos:

• imagem passou pelo scanner de vulnerabilidades;
• imagem passou pelo QA;
• artefato foi construído por um sistema confiável;
• release foi aprovada por uma equipe.

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.

Occurrence

Uma Occurrence é a aplicação daquela Note a um artefato específico.

Para Binary Authorization, a Occurrence contém a attestation e sua assinatura.

Modelo mental

Note = o que significa a aprovação
Occurrence = onde essa aprovação ocorreu
Attestation = a evidência assinada sobre a imagem

Attestor e Attestation não são a mesma coisa

Esses termos são parecidos e frequentemente confundidos.

Attestor

É a autoridade que o Binary Authorization considera confiável para verificar attestations.

Pode representar:

• um pipeline;
• uma equipe de segurança;
• QA;
• um scanner;
• um aprovador de release;
• um processo de compliance.

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.

Attestation

É 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.

Cloud KMS: protegendo a chave privada

A chave criada no laboratório tinha:

purpose: asymmetric-signing
algorithm: ec-sign-p256-sha256

gcloud kms keys create codelab-key \
  --keyring=binauthz-keys \
  --location=global \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256

Em criptografia assimétrica:

• a chave privada cria a assinatura;
• a chave pública verifica a assinatura.

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.

Criando a attestation manual

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;
• assinatura digital;
• criação de uma Occurrence do tipo ATTESTATION.

Esse foi o primeiro fechamento completo da cadeia de confiança.

Políticas de admissão

O laboratório explorou três modos.

ALWAYS_ALLOW

Permite 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_DENY

Bloqueia imagens que chegam à regra.

defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG

Esse teste demonstrou que o controle estava realmente na admissão do GKE.

REQUIRE_ATTESTATION

Exige aprovação por uma autoridade confiável.

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/vulnz-attestor

Essa é a política central do laboratório.

globalPolicyEvaluationMode: ENABLE

O laboratório manteve:

globalPolicyEvaluationMode: ENABLE

Isso 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.

Automatizando a assinatura no Cloud Build

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/1

O 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 teste decisivo: imagem assinada e imagem não assinada

O laboratório produziu duas imagens.

Imagem good

• construída pelo pipeline;
• enviada ao Artifact Registry;
• assinada;
• associada a uma attestation;
• implantada no GKE.

Imagem bad

• construída e enviada diretamente;
• não recebeu attestation;
• foi rejeitada pelo Binary Authorization.

Esse teste é o ponto mais importante do capítulo.

Ele mostra que possuir acesso ao registry não é suficiente para implantar em produção.

O que o laboratório realmente provou

O experimento comprovou cinco capacidades:

1. Identidade do artefato
   A decisão foi tomada usando o digest.

2. Assinatura criptográfica
   A chave privada do KMS assinou a declaração.

3. Autoridade confiável
   O Attestor conhecia a chave pública.

4. Política explícita
   O ambiente exigia a attestation.

5. Enforcement real
   A imagem não assinada foi bloqueada.

Automatizando o próprio laboratório

Para reduzir tarefas repetitivas, transformei o laboratório em um script Bash com:

• criação de arquivos;
• habilitação de APIs;
• retries para operações assíncronas;
• espera por propagação de IAM;
• provisionamento do cluster;
• geração das políticas;
• builds;
• assinatura;
• deploy da imagem confiável;
• tentativa controlada da imagem não confiável;
• pausas para 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.

Além do laboratório

O laboratório é excelente para demonstrar o conceito, mas simplifica decisões que seriam obrigatórias em produção.

1. Uma attestation não prova que a imagem é segura

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ável

A segurança depende de:

• regras de aprovação;
• qualidade dos scanners;
• proteção do pipeline;
• revisão das exceções;
• controle de acesso às chaves;
• integridade do sistema de build.

2. Separação de projetos e responsabilidades

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
  └── workloads

Essa separação reduz a possibilidade de uma única identidade controlar build, assinatura e deploy.

3. Privilégio mínimo no Cloud Build

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:

• leitura do código necessário;
• push no repositório correto;
• uso da versão de chave correta;
• criação de occurrences/attestations;
• acesso limitado ao ambiente de deploy, quando necessário.

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-account

4. Assinar somente após as verificações

A etapa de assinatura deve ficar depois de:

• testes unitários;
• testes de integração;
• análise estática;
• validação de dependências;
• scan de vulnerabilidades;
• geração e verificação de SBOM;
• políticas de licenciamento;
• aprovação de release.

5. Evitar tags mutáveis no deployment

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.

6. Mais de um Attestor

Uma organização pode exigir múltiplas evidências.

Exemplo:

built-by-trusted-cloud-build
AND
passed-vulnerability-policy
AND
approved-by-release-management

A política deixa de confiar em um único controle.

7. Breakglass precisa de governança

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:

• identidade restrita;
• justificativa;
• aprovação;
• expiração;
• alerta;
• auditoria;
• revisão posterior.

8. Admission-time não é o fim da história

O laboratório verifica a imagem no momento da implantação.

Mas o risco pode mudar depois:

• uma vulnerabilidade nova pode ser descoberta;
• uma chave pode ser comprometida;
• uma política pode mudar;
• um artefato anteriormente aceito pode deixar de cumprir os requisitos.

Por isso, além do admission control, ambientes maduros precisam de:

• monitoramento contínuo;
• rescans;
• inventário de workloads;
• alertas;
• resposta a incidentes;
• validação contínua quando aplicável.

9. Notes e Occurrences merecem fronteiras de IAM

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.

10. O builder usado pelo laboratório também é software

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:

• pin de commit;
• revisão do código;
• scan do builder;
• imagem por digest;
• repositório interno;
• atualização controlada;
• assinatura do próprio builder.

A ferramenta que produz attestations também pertence à cadeia de suprimentos.

11. Proveniência e SLSA

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:

• assinatura;
• attestation;
• proveniência;
• identidade do builder;
• inputs do build;
• digest do artefato;
• políticas de verificação.

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.

12. Políticas precisam ser observáveis

Quando uma imagem é bloqueada, a equipe precisa entender:

• qual regra bloqueou;
• qual imagem foi solicitada;
• qual digest estava envolvido;
• qual attestation faltou;
• qual identidade tentou implantar;
• se ocorreu uso de breakglass.

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.

Arquitetura que eu usaria em produção

Como aplicaria em ambientes reais

Sistemas SaaS

Para aplicações web e APIs:

GitHub
→ Cloud Build
→ testes
→ scan
→ Artifact Registry
→ attestation
→ Binary Authorization
→ GKE ou Cloud Run

Plataformas institucionais

Em uma plataforma institucional, o objetivo seria garantir que somente artefatos provenientes do pipeline autorizado chegassem aos ambientes homologados.

Controles possíveis:

• attestation de build;
• attestation de testes;
• aprovação antes de produção;
• separação entre ambiente de build e runtime;
• auditoria de deploy;
• breakglass formal.

Sistemas com dados sensíveis

Em sistemas que lidam com dados sensíveis, o valor principal seria reduzir risco de implantação não autorizada e melhorar rastreabilidade:

• quem produziu o artefato;
• qual versão foi implantada;
• quais verificações foram executadas;
• qual política autorizou o deploy;
• quais eventos foram bloqueados.

Binary Authorization não resolve sozinho os requisitos de segurança e privacidade, mas fortalece o controle de integridade do software entregue.

Comparação Google Cloud e AWS

Não existe uma equivalência perfeita de um único serviço para Binary Authorization no EKS.

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.

Custos e impacto operacional

Uma implementação real pode envolver custos de:

• armazenamento no Artifact Registry;
• minutos de Cloud Build;
• scans do Artifact Analysis;
• operações e versões de chave do Cloud KMS;
• cluster GKE;
• Cloud Logging;
• tráfego e armazenamento de artefatos.

O maior custo, porém, pode ser operacional:

• manter políticas;
• tratar exceções;
• atualizar builders;
• responder a falhas;
• administrar IAM;
• evitar que o processo de segurança bloqueie entregas legítimas sem explicação.

Segurança eficaz precisa ser forte e utilizável.

Erros e pontos de atenção do laboratório

Propagação de APIs e IAM

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.

Criação do cluster

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.

Digest versus tag

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.

YAML sensível à indentação

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.

Conta de serviço do Cloud Build

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.

Falha esperada na última etapa

O deploy da imagem bad deveria falhar.

Nesse caso, falha é sucesso: ela prova que a política está ativa.

O que o laboratório não explicou

O laboratório demonstra o mecanismo, mas não responde completamente:

• como definir critérios reais para emitir uma attestation;
• como separar build, segurança e produção em projetos diferentes;
• como revogar confiança quando uma chave é comprometida;
• como fazer rotação de chaves sem interromper deploys;
• como tratar múltiplos Attestors;
• como relacionar attestations com SBOM e proveniência;
• como validar builders;
• como testar políticas antes de aplicá-las;
• como projetar breakglass;
• como monitorar workloads já em execução;
• como gerenciar ambientes multi-região e multi-cluster;
• como adaptar o modelo para Cloud Run;
• como impedir pushes manuais não autorizados;
• como recuperar o pipeline quando o serviço de política está indisponível.

Essas perguntas pertencem à arquitetura operacional, não apenas ao comando gcloud.

Como um arquiteto pensa

Antes de implementar Binary Authorization, eu responderia:

1. Qual ameaça queremos reduzir?
   Push manual, imagem vulnerável, builder comprometido, deploy fora do pipeline ou alteração de dependência?

2. Qual evidência será exigida?
   Build confiável, scan, QA, SBOM, aprovação humana ou combinação?

3. Quem pode produzir essa evidência?
   Uma conta de serviço dedicada, um scanner ou uma equipe?

4. Onde as chaves ficam?
   Qual projeto, quais papéis e qual processo de rotação?

5. Onde a política é aplicada?
   Todos os clusters, somente produção, GKE, Cloud Run ou ambos?

6. Como exceções funcionam?
   Breakglass, tempo de expiração, aprovação e auditoria.

7. 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.

Lições aprendidas

1. Armazenar uma imagem no registry não significa que ela é confiável.
2. Tags são referências; digests identificam conteúdo.
3. Uma attestation representa evidência, não segurança automática.
4. A chave privada deve permanecer protegida e com uso restrito.
5. Binary Authorization transforma evidências em enforcement.
6. IAM faz parte da arquitetura de confiança.
7. Assinatura precisa acontecer depois dos controles obrigatórios.
8. Uma imagem não assinada deve falhar antes do runtime.
9. Observabilidade e breakglass são partes da solução.
10. Segurança de supply chain exige processos, pessoas e tecnologia.

Como isso ajuda na formação em Cloud Engineering

O laboratório reforça conhecimentos importantes para profissionais de Cloud, DevOps, DevSecOps e arquitetura:

• Artifact Registry;
• Cloud Build;
• IAM e service accounts;
• Cloud KMS;
• Artifact Analysis;
• GKE;
• manifests Kubernetes;
• políticas de admissão;
• segurança de pipelines;
• confiança por assinatura;
• auditoria;
• automação com Bash.

Mais importante do que memorizar comandos é entender onde a confiança nasce e como ela é verificada.

Conclusão

O laboratório começou com uma aplicação Python simples e terminou com uma cadeia de confiança completa.

A imagem foi:

• construída;
• armazenada;
• identificada por digest;
• assinada por uma chave gerenciada;
• associada a uma attestation;
• verificada por um Attestor;
• avaliada por uma política;
• autorizada no GKE.

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.

Próximo capítulo

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:

• identidades;
• isolamento;
• permissões;
• artefatos;
• análise;
• proveniência;
• pipelines confiáveis.

A segurança do deploy começa muito antes do kubectl apply.

Referências oficiais consultadas

• Google Cloud Documentation — Binary Authorization overview
• Google Cloud Documentation — Create attestations
• Google Cloud Documentation — Create a Binary Authorization attestation in a Cloud Build pipeline
• Google Cloud Documentation — Artifact Analysis metadata management overview
• Google Cloud Documentation — Cloud KMS digital signatures
• Google Cloud Documentation — Binary Authorization policy YAML reference
• Google Cloud Documentation — Binary Authorization audit logs for GKE
• Google Cloud Documentation — Software supply chain security overview and practices
• Google Cloud Documentation — Cloud Build default service account changes
• Google Cloud Documentation — Configure user-specified Cloud Build service accounts
• SLSA Specification v1.2 — Provenance
• AWS Documentation — Amazon ECR image signing
• AWS Documentation — Validate container signatures during deployment on EKS