Conceito e mecanismo
Uma pipeline precisa de autenticação e autorização com âmbito definido. Workload identity federation permite usar app registration ou managed identity compatível sem gerir um client secret permanente. Isso não dispensa RBAC nem autorização para cada pipeline usar a service connection. Evita conceder acesso a todas quando apenas duas precisam da ligação. A documentação atual descreve uma transição de issuer para Microsoft Entra em novas ligações Azure public cloud com aplicações single-tenant ou managed identities. O issuer anterior Azure DevOps tem retirada anunciada para 1 de julho de 2027 nesse âmbito; outras clouds e aplicações multitenant estão excluídas. Não generalizes a data a todo o parque.
Aplicação guiada
Inventaria ligações, tasks e extensões antes de migrar autenticação, usando piloto e critérios de recuperação. Para segredos que ainda existam, o masking de logs é limitado: não oculta substrings de um segredo JSON completo. Não imprimas credenciais, e mapeia explicitamente variáveis secretas para env apenas nas tasks necessárias. No GitHub Actions, configura GITHUB_TOKEN com as permissões mínimas do job; ler código e criar issues não exige write-all. Uma action de terceiros executa código no contexto do workflow. Fixa o SHA completo revisto para estabilizar a revisão consumida e conserva processo de atualização. O SHA não prova que o código é seguro: combina revisão de origem, permissões reduzidas e análise das dependências.
Uma ligação WIF funciona, mas está autorizada para todas as pipelines. Autenticação sem segredo não resolve esse excesso de âmbito.
Armadilhas comuns
WIF como ausência de RBAC; mudança de issuer ignorada; JSON como máscara total; badge como código imutável.
Tópicos relacionados: Instrumentação e KQL · Fluxo, rastreabilidade e handover
Controla identidade, consumidor e revisão do código em cada acesso.
Referência: Azure service connections · AZ-400 objectives 2026-07-27