Skip to content
Latchkey

O Que É um Service Principal? Identidades Não Humanas do Azure

Um service principal é uma identidade no Microsoft Entra ID que uma aplicação ou pipeline usa para autenticar no Azure e agir com as permissões de RBAC atribuídas.

Quando software (não uma pessoa) precisa acessar o Azure, ele autentica como um service principal: a instância local de uma aplicação do Entra ID dentro do seu tenant. Você concede a ele roles de RBAC em recursos, e ele pode fazer sign in com um secret, um certificado ou credenciais federadas. É como os pipelines fazem deploy no Azure.

App registration vs service principal

Uma app registration é a definição global de uma aplicação no Entra ID. Um service principal é sua identidade concreta em um tenant específico, a coisa que de fato recebe atribuições de role e faz sign in. Na prática, criar uma app registration cria um service principal.

Como ele autentica

  • Um client secret (uma senha, a opção menos preferida).
  • Um certificado.
  • Credenciais federadas (OIDC), a opção sem chaves para CI.

Permissões de RBAC

Você atribui ao service principal roles de RBAC do Azure escopadas a subscriptions, resource groups ou recursos individuais. Menor privilégio se aplica: um principal de deploy deve poder atualizar apenas os recursos de que precisa, nada mais.

Managed identities como alternativa

Para workloads rodando dentro do Azure, uma managed identity é um service principal que o Azure gerencia por você, sem credenciais para lidar. Para CI externo, você usa em vez disso um service principal com credenciais federadas.

Papel no CI/CD

Um pipeline autentica como um service principal para fazer deploy. A abordagem moderna e sem chaves a partir do GitHub Actions são as credenciais federadas (OIDC): o workflow apresenta um token do GitHub, o Entra ID confia nele e emite acesso sem um client secret. Escope o federation a repos e branches específicos.

Principais conclusões

  • Um service principal é a identidade do Azure que um app ou pipeline usa para autenticar.
  • Ele pode usar um secret, um certificado ou credenciais federadas sem chaves (OIDC).
  • Pipelines fazem deploy como um service principal de menor privilégio, idealmente via federation.

Guias relacionados