Registry e Assinatura

Cada build que chega ao registry é assinado, leva o seu SBOM e diz de onde veio. Tudo o resto não é implementado.

Marcar uma chamada →Percorrer a linha

Nas prateleiras

Escolha um passo, ou deixe correr. Cada fala é o que alguém na sala diz de facto.

Passo 1Mapear as prateleiras

Registries, repositórios, quem pode fazer push e quem pode fazer pull.

ATALAIAQuem pode fazer push para o registry hoje?

PLATAFORMACatorze pessoas e o pipeline. E as tags podem ser sobrescritas.

Sai da sala2 registries, 14 pessoas podem fazer push

Passo 2Assinar na origem

O pipeline assina, atesta e anexa o SBOM.

ATALAIASó o pipeline faz push, e assina cada imagem com o seu SBOM.

DEV LEADEntão a rewards-api:1.4.0 diz que commit a construiu?

ATALAIAE que workflow, em que runner.

Sai da salaPipeline assina, SBOM, proveniência

Passo 3Separar as prateleiras

DEV e PROD separados, tags imutáveis, promoção explícita.

PLATAFORMARepositórios DEV e PROD separados. PROD é só de leitura para pessoas.

ATALAIAA promoção copia a mesma imagem assinada. Nada é reconstruído.

Sai da salaDEV e PROD separados, tags imutáveis

Passo 4Verificar no deploy

Clusters e hosts só correm o que conseguem verificar.

ATALAIAO cluster verifica a assinatura antes de correr seja o que for.

PLATAFORMATentei uma imagem não assinada. Rejeitada.

DEV LEADE o auditor recebe proveniência, não capturas de ecrã.

Sai da salaAdmissão: não assinado significa sem deploy

PLATAFORMA
ATALAIA
DEV LEAD

Do build ao cluster

Uma imagem, um digest, todo o caminho. Os passos numerados são as verificações que tornam impossível correr uma imagem não assinada.

Buildsó pelo pipeline
1Assinarassinatura, SBOM, proveniência
Prateleira DEVpush pela CI
2Promovermesmo digest, sem rebuild
3Prateleira PRODsó de leitura, imutável
4Clusterverificar, depois correr

1
O pipeline assina e atesta
Assinatura, SBOM e proveniência anexados ao digest.
2
A promoção copia, nunca reconstrói
O que foi testado é exatamente o que é enviado.
3
As tags de PROD não mudam
Tags imutáveis, sem permissões de push humanas.
4
O controlo de admissão verifica
Sem assinatura válida do seu pipeline, não há pod.

O que corre mal

Se qualquer imagem no registry pode ser implementada, um atacante só precisa de fazer push de uma. Sem proveniência não consegue provar o que enviou, nem a um auditor nem a si próprio.

SINAIS DE QUE ESTÁ AQUI

Quem tem escrita no registry pode sobrescrever uma tag
Ninguém sabe dizer que commit construiu a imagem em produção
Os SBOMs são gerados para auditorias, não para cada build

O que recebe

Builds assinados com proveniência a partir do pipeline
Um SBOM anexado a cada artefacto
Tags imutáveis e repositórios DEV e PROD separados
Uma regra de admissão: não assinado significa sem deploy

Formato típico: duas a quatro semanas, consoante os registries e runtimes.

A seguir na linha

Todas as estações reportam à mesma torre. Estas são as vizinhas.

Estação 10 · Release e testesAprovações de Deploy

Quem desbloqueia prod, e com que papéis

Ver a estação →Estação 06 · ConstruçãoAuditoria de Pipeline CI/CD

Runners, tokens, actions fixadas

Ver a estação →Estação 07 · ConstruçãoSegurança da Cadeia de Fornecimento

Pacotes, extensões, registries

Ver a estação →

Vamos conversar

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.

Marcar uma chamada →Percorra cada estação