Sua equipe de plataforma deseja remover credenciais de longa duração para CI/CD e acesso a recursos do Azure dentro do cluster. O GitHub Actions deve implantar modelos Bicep no Azure sem um segredo de cliente, e as cargas de trabalho do AKS devem acessar o Key Vault e o Storage sem armazenar segredos de service principal. O que você deve configurar? Cada resposta correta apresenta parte da solução.

A primeira resposta correta descreve a configuração do OpenID Connect (OIDC) para GitHub Actions. Ao criar um registro de aplicativo no Entra ID (anteriormente Azure AD) com uma credencial federada que confia no emissor OIDC do GitHub e conceder Azure RBAC a esse aplicativo, os fluxos de trabalho do GitHub podem autenticar-se no Azure sem credenciais de longa duração, usando o azure/login baseado em OIDC. Isso elimina a necessidade de segredos de cliente. A segunda resposta correta aborda o acesso a recursos do Azure a partir de cargas de trabalho do AKS usando o Azure AD Workload Identity. Habilitar essa funcionalidade no AKS, criar uma conta de serviço Kubernetes anotada e mapeá-la para um aplicativo Entra ID via credencial de identidade federada permite que os pods acessem recursos como Key Vault e Storage sem armazenar segredos de service principal, utilizando o Azure Identity SDK. As opções incorretas são: Gerar um PAT do GitHub e armazená-lo como um segredo de repositório e usar az login --username/--password é uma solução baseada em segredos, que a pergunta busca evitar. Usar o add-on legado AAD Pod Identity não é a abordagem recomendada para novos clusters; o Workload Identity é o sucessor. Criar service principals com certificados e montar o PFX em segredos do Kubernetes ainda envolve o gerenciamento de segredos (certificados), o que a pergunta busca eliminar.