O exame AZ-400 pergunta repetidamente como um pipeline prova sua identidade para os recursos do Azure. A resposta antiga era simples: guardar um client secret no GitHub Secrets ou em uma variável do pipeline e recuperá-lo em tempo de execução. O problema é que qualquer segredo armazenado em um sistema externo pode ser exposto. Esta publicação cobre três abordagens que eliminam esse risco: Managed Identity, Workload Identity Federation (OIDC) e Azure Key Vault.
Crachá de funcionário vs tag de máquina — Service Principal e Managed Identity
Cada novo funcionário recebe um crachá com data de validade; quando vence, solicita renovação. As impressoras do escritório nunca precisam de renovação — a infraestrutura do prédio gerencia suas credenciais automaticamente. Service Principal é o crachá do funcionário. Managed Identity é a tag de máquina emitida e gerenciada pela própria plataforma.
Um Service Principal é uma identidade não interativa no Microsoft Entra ID. Funciona em qualquer ambiente: uma VM do Azure, um servidor on-premises, um runner do GitHub Actions ou uma ferramenta CI/CD externa. A desvantagem é o gerenciamento de credenciais: client secrets expiram em dois anos, e esquecer de renová-los causa falhas silenciosas à meia-noite.
Managed Identity é um Service Principal criado, gerenciado e rotacionado pela plataforma do Azure. Não são necessárias credenciais no código nem na configuração do pipeline. Dois tipos para o exame:
está vinculada a um único recurso do Azure. Seu ciclo de vida é unificado com o do recurso — criada e excluída junto com ele.
é um recurso independente atribuível a múltiplas VMs, instâncias de App Service e pods de AKS simultaneamente. Quando uma VM é substituída durante um escalonamento, a mesma identidade e suas permissões são transferidas automaticamente. Palavra-chave do exame: → user-assigned.
| Cenário | Escolha | |---------|--------| | Ambiente não Azure acessando recursos do Azure | Service Principal | | Recurso único no Azure | System-assigned Managed Identity | | Múltiplos recursos compartilhando a mesma identidade | User-assigned Managed Identity |
!Service Principal vs Managed Identity
Um cofre sem chave — Workload Identity Federation e OIDC
Imagine um cofre que abre não com uma chave física, mas com verificação biométrica em tempo real e aprovação ao vivo da equipe de segurança. A chave não existe — só a verificação de identidade. Essa é a ideia do Workload Identity Federation: em vez de um client secret, o pipeline usa um OIDC token de curta duração, emitido e verificado em tempo real.
Quando o GitHub Actions ou o Azure Pipelines é executado, a plataforma emite automaticamente um OIDC token assinado — um JWT com o repositório, a branch, a organização e o contexto do workflow. O pipeline envia esse token ao Serviço de Token Seguro (STS) do Azure. O Azure verifica se as declarações de emissor e sujeito correspondem à pré-configurada e, se corresponderem, emite um Access Token. Nenhum client secret existe em nenhum ponto desse processo.
Configuração para o GitHub Actions: Criar um App registration no Microsoft Entra ID. Adicionar uma Federated Identity Credential — Issuer: , Subject: . Atribuir a função Azure RBAC ao Service Principal. Armazenar no GitHub Secrets apenas o Client ID, Tenant ID e Subscription ID — sem valores de segredos. Passar esses três valores para a ação .
No Azure Pipelines, o Workload Identity Federation é configurado automaticamente ao criar a Service Connection.
Falha mais comum no OIDC: incompatibilidade do Subject claim — executar de uma branch de feature quando o Subject especifica .
Três compartimentos em um cofre — Secret, Key e Certificate
Um cofre guarda notas, documentos selados e carimbos em seções distintas, pois cada item tem requisitos de segurança diferentes. O Azure Key Vault faz o mesmo, e identificar o compartimento certo é uma pergunta frequente no exame.
armazena strings arbitrárias: strings de conexão, API keys, senhas, tokens OAuth. É o tipo mais usado pelos pipelines.
gerencia material de chave assimétrica RSA ou EC para criptografia, descriptografia, assinatura e verificação. Chaves protegidas por HSM nunca saem do vault. Use quando o requisito envolva criptografia ou assinatura.
gerencia certificados X.509 TLS/SSL com renovação e rotação automáticas. Use para TLS, mTLS ou certificados de assinatura.
Modelos de controle de acesso
é o sistema de permissões próprio do Key Vault: especifica operações individuais (Get, List, Set, Delete) por identidade, de forma independente do Azure RBAC.
é o padrão para novos Key Vaults desde 2023. Integra-se ao Microsoft Entra ID e usa a mesma interface IAM de qualquer outro recurso do Azure. Funções principais: (leitura mínima para pipelines), (leitura + escrita), (gerenciamento completo).
Para referenciar Secrets em templates ARM, o vault deve ter ativado. Novos vaults têm isso desativado por padrão — esquecer causa falha imediata na implantação.
O registro mestre do armazém — integração de segredos em pipelines
Um armazém logístico mantém um único registro mestre de inventário: qualquer gerente consulta a mesma fonte e as atualizações se propagam instantaneamente. Os segredos dos pipelines funcionam da mesma forma. Quando cada pipeline mantém sua própria cópia, as atualizações se perdem e as versões divergem. Um Variable Group vinculado ao Key Vault é esse registro mestre.
Com um Variable Group do Azure Pipelines vinculado ao Key Vault, o YAML contém apenas o nome do grupo — sem valores de segredos. Em tempo de execução, os segredos são buscados dinamicamente. Múltiplos pipelines do mesmo projeto compartilham um único Variable Group; quando um secret é rotacionado no Key Vault, todos os pipelines pegam o novo valor na próxima execução sem alterações de configuração.
No GitHub Actions, isola segredos por ambiente de implantação. Os Environment Secrets só são acessíveis quando esse ambiente está ativo; combinados com regras de proteção — revisores obrigatórios, temporizadores, restrições de IP — criam um portão para produção.
Uma do Azure Pipelines autentica o pipeline em sistemas externos. Hierarquia de permissões: Reader → User → Creator → Administrator. User é suficiente para executar; Administrator é necessário para editar, excluir ou compartilhar.
Resumo do Exame
'Autenticar no Azure sem client secret' -- Workload Identity Federation (OIDC) 'Múltiplos recursos do Azure compartilhando a mesma identidade' -- User-assigned Managed Identity 'Recurso do Azure acessa Key Vault sem armazenar credenciais' -- System-assigned Managed Identity 'GitHub Actions implanta no Azure, secretless' -- Workload Identity Federation 'Causa mais comum de falha na autenticação OIDC' -- Incompatibilidade de Subject claim com a branch real 'Armazenar string de conexão ou API key no Key Vault' -- Secret 'Armazenar material de chave criptográfica no Key Vault' -- Key 'Armazenar certificado TLS/mTLS no Key Vault' -- Certificate 'Implantação ARM falha ao ler Secret do Key Vault' -- Enable for template deployment desativado 'Compartilhar Secrets do Key Vault entre múltiplos pipelines' -- Variable Group vinculado ao Key Vault 'Modelo de permissões padrão do Azure para Key Vault' -- Azure RBAC 'Permissão mínima para uma execução de pipeline usar uma Service Connection' -- User