APRENDER. PRATICAR. EVOLUIR.1. Desenhar o percurso de autorização da release
Uma equipa fictícia de produção recebe uma pipeline que compila uma aplicação de processamento batch, publica a imagem e prepara a instalação. O desenho inclui pessoas, repositórios, triggers, contas de execução e identidades de runtime. Desenha cada passagem com uma pergunta: quem pode fazer esta ação provocar a seguinte? Ter leitura restrita na consola não impede necessariamente um utilizador de iniciar uma execução que usa uma conta mais privilegiada. A revisão deve incluir permissões sobre código, configuração, triggers e identidades, além do acesso direto aos recursos. Para um gestor técnico, este desenho permite atribuir tarefas concretas. A equipa de desenvolvimento controla a origem e a revisão; a equipa de plataforma configura identidades; APS confirma o procedimento de entrega e investigação. Regista as relações que foram verificadas e as que dependem de configuração ainda não observada. Evita concluir que uma credencial temporária torna qualquer percurso seguro. A duração limita a janela de utilização, mas a credencial ainda pode representar uma origem demasiado ampla ou uma conta com permissões excessivas. A aceitação deve identificar a capacidade concedida e o motivo de ela ser necessária.
2. Restringir a origem de uma identidade federada
Um issuer GitHub partilhado não distingue sozinho a organização autorizada. A condição do provider deve limitar as claims à origem pretendida. No exemplo desta aula, a organização tem ID 73190, o repositório tem ID 845210 e a branch autorizada é refs/heads/main. Estas três condições são cumulativas. Um token de outro repositório na mesma organização não passa só por vir da branch main. Um token do repositório correto noutra branch também não satisfaz a regra. O mapeamento de atributos e a condição devem corresponder às claims realmente emitidas pelo fornecedor. Usa IDs estáveis para distinguir entidades quando os nomes podem ser reutilizados. A alteração do nome visível de um repositório não deve ser confundida com a criação de uma nova entidade com o nome antigo. Antes de alterar a configuração, compara casos positivos e negativos: origem aprovada, owner incorreto, repositório incorreto e branch incorreta. A validação de assinatura, issuer, audience e validade do token continua necessária. Uma expressão sobre claims não a substitui. Os números usados aqui são fictícios e não representam contas ou repositórios reais.
3. Separar impersonação, acesso e execução
Obter um token através de impersonação demonstra uma relação entre a identidade federada e a service account. Não prova que essa conta consiga ler um bucket ou alterar um serviço. Se a impersonação funciona mas falta uma permissão no recurso, investiga essa camada. Alargar todo o pool não resolve a leitura e pode permitir novas origens. Define a conta de staging e os recursos que ela realmente precisa de utilizar; documenta a diferença para produção. Contas por pipeline ajudam a separar privilégios e a reconstruir ações. O percurso continua na identidade anexada ao recurso. Se uma pipeline pode implantar código arbitrário e anexar runtime-prod, esse código pode operar com as permissões da conta. A ausência de leitura direta pelo autor não elimina esse acesso indireto. A revisão deve combinar controlo do código com iam.serviceAccounts.actAs e os privilégios de runtime. No Cloud Build, um trigger que usa a legacy service account pode executar um passo que acede a um segredo autorizado para essa conta. Registar o iniciador ajuda na auditoria, mas não reduz por si só a capacidade concedida ao build.
4. Distinguir segredo de build e segredo de runtime
Um token usado para descarregar uma dependência durante a construção tem um ciclo de vida diferente da credencial que a aplicação utiliza depois de arrancar. Para BuildKit, usa o mecanismo apropriado de secret mount e evita transportar o valor secreto em argumentos de build. Há uma consequência menos óbvia: rodar o conteúdo do segredo não invalida a cache desse passo. Se o objetivo é repetir um download, controla explicitamente a cache ou utiliza um marcador não secreto adequado. Não coloques o novo valor num argumento apenas para provocar uma nova execução. Em Cloud Run, distingue consumo por variável de ambiente e por volume. O primeiro resolve o valor no arranque da instância. Uma leitura do volume pode falhar durante a execução se o segredo estiver inacessível. Um arranque bem-sucedido não garante disponibilidade futura. Combina a investigação da versão, acesso e estado do segredo com o tratamento do erro pela aplicação. No exercício, não precisas de imprimir valores para diagnosticar estas relações. Regista identificadores de versão e resultados de acesso autorizados, preservando o segredo fora de logs e relatórios operacionais.
5. Planear uma rotação que chegue aos consumidores
Uma notificação SECRET_ROTATE informa um processo de que chegou o momento previsto; não muda por si só a password de um sistema externo. Identifica o consumidor que vai executar a rotação, a autorização necessária e a forma de confirmar o resultado. O processo pode precisar de criar uma nova credencial no sistema de origem, guardar uma nova versão, atualizar consumidores e retirar a versão anterior. A ordem concreta depende do suporte para coexistência de credenciais e das condições de recuperação do sistema. Não imponhas uma sequência universal que o produto não suporta. Numa janela operacional fictícia, a aplicação principal muda de versão mas um processo batch semanal continua a usar a credencial anterior. A equipa só descobre isso quando a retira. Usa este risco para preparar inventário de consumidores e ensaios que cubram tarefas pouco frequentes. Define quem confirma a adoção, quando termina a coexistência e como se responde a uma falha. A notificação recebida, a nova versão criada e o consumidor atualizado são evidências diferentes. O relatório deve indicar qual delas existe, sem declarar rotação completa apenas porque a mensagem chegou ao tópico.
6. Verificar origem e atualidade do artefacto
A proveniência deve ser autenticada e ligada ao artefacto em análise. Depois, compara as expectativas aprovadas: builder, origem canónica e parâmetros relevantes da construção. Uma assinatura válida de um builder confiável pode descrever honestamente uma construção a partir de um fork não autorizado. Nesse caso, a evidência é autêntica mas não satisfaz a política do pacote. Alterar uma tag não corrige a origem. A referência SLSA usada nesta aula é a orientação de verificação v1.2, com o âmbito registado nas fontes. A análise de vulnerabilidades responde a outra pergunta e depende da atualidade dos dados. Uma imagem de recuperação guardada durante semanas pode manter os mesmos bytes e ter novos riscos conhecidos nas dependências. Em Artifact Analysis, a atualização deixa de continuar para imagens sem pulls nos últimos 30 dias. Puxar uma imagem com metadata desatualizada permite reativar a análise, mas a atualização pode demorar até 24 horas. Confirma o resultado antes de o apresentar como atual. Se mudares de artefacto para resolver a origem, recolhe evidência para o digest novo; o relatório anterior não acompanha automaticamente essa substituição.
7. Exercício guiado de leitura da evidência
O registo JSON apresentado é um inventário didático fictício, não uma política IAM, uma atestação ou um ficheiro aplicável a um serviço. Os campos sobre assinatura e digest representam observações assumidas no exercício; escrever true não verifica criptografia. O caso A tem proveniência autêntica mas origem divergente. O caso B satisfaz a origem e tem análise recente, mas a regra de admissão está em dry-run. O caso C tem evidência compatível com as condições listadas. Decide qual o problema específico de cada um antes de consultar as respostas. Para A, pede uma construção que corresponda à origem aprovada e volta a ligar a evidência ao artefacto resultante. Para B, o facto de instalar não demonstra que uma imagem indevida seria bloqueada: dry-run permite observar violações. Para C, podes avançar para a revisão operacional seguinte, mas o inventário não demonstra testes funcionais, capacidade de recuperação ou aprovações externas. Justifica cada conclusão numa frase em inglês. Depois altera apenas um campo e explica que evidência precisa de ser recolhida de novo. O objetivo é localizar uma lacuna concreta, evitando transformar uma coleção de campos positivos numa aprovação universal.
8. Gerir exceções e devolver o serviço a RUN
Durante um incidente, pode existir um procedimento de emergência autorizado que permita uma exceção. Distingue essa decisão da promoção normal. Em GKE, a utilização de breakglass gera um evento de auditoria mesmo que a imagem cumpra a política. Se o procedimento interno exige revisão de exceções, a conformidade da imagem não apaga a utilização desse percurso. Regista o motivo, o responsável, a evidência disponível e a ação para regressar ao funcionamento normal. Não removas a política inteira para esconder ou simplificar o acompanhamento de uma exceção. No caso final, a imagem de recuperação vem de um fork não autorizado e a análise está antiga. A promoção normal requer resolver ambas as lacunas. Se uma emergência impedir esperar, a decisão deve seguir o processo autorizado com os riscos explícitos, sem afirmar que os controlos passaram. No handover, entrega a APS instruções para localizar a proveniência, confirmar a análise, investigar acesso a segredos e reconhecer exceções. Resume a aula por quatro relações: origem da identidade, privilégios de execução, consumo de segredos e evidência do artefacto. Cada relação precisa de um responsável e de uma forma verificável de demonstrar o resultado.
{
"kind": "fictional-evidence-inventory",
"notAProviderConfiguration": true,
"cryptographicVerificationPerformed": false,
"expectedSource": "central/app",
"cases": [
{
"id": "A",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "sandbox/app-fork",
"scanFresh": true,
"enforcement": "ENFORCED_BLOCK_AND_AUDIT_LOG",
"decision": "hold-source-mismatch"
},
{
"id": "B",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "central/app",
"scanFresh": true,
"enforcement": "DRYRUN_AUDIT_LOG_ONLY",
"decision": "blocking-not-demonstrated"
},
{
"id": "C",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "central/app",
"scanFresh": true,
"enforcement": "ENFORCED_BLOCK_AND_AUDIT_LOG",
"decision": "continue-operational-review"
}
]
}Uma imagem de recuperação tem proveniência autêntica, mas origem não autorizada e análise de vulnerabilidades antiga.
Armadilhas comuns
Confiar apenas no issuer, confundir impersonação com acesso a recursos, tratar uma notificação como rotação concluída e uma assinatura como aprovação universal.
Tópicos relacionados: IAM e federação de identidades · Gestão de mudanças e resposta a incidentes · Proveniência, análise e aceitação operacional
A entrega precisa de uma origem autorizada, privilégios delimitados e evidência atual ligada ao artefacto que realmente será instalado.
Referência: Configure Workload Identity Federation with deployment pipelines · Current linked guide; edition date unconfirmed (2026-09-30 inspection)