Compartilhar via

Usar entidades de serviço e identidades gerenciadas no Azure DevOps

Serviços do Azure DevOps

Entidades de serviço e identidades gerenciadas fornecem autenticação segura e escalonável para fluxos de trabalho de automação do Azure DevOps. Esses tipos de identidade do Microsoft Entra oferecem segurança aprimorada em pats (tokens de acesso pessoal) tradicionais. Eles usam o gerenciamento automático de credenciais, tempos de vida de token mais curtos e controles de acesso de nível empresarial.

Benefícios de entidades de serviço e identidades gerenciadas

Segurança aprimorada

  • Tokens de curta duração: os tokens do Microsoft Entra expiram a cada hora, o que reduz o risco de exposição em comparação com PATs (que podem durar até um ano).
  • Rotação automática: as identidades gerenciadas lidam com a rotação de credenciais automaticamente.
  • Nenhum segredo armazenado: a necessidade de armazenar credenciais de longa duração no código ou na configuração é eliminada.

Excelência operacional

  • Gerenciamento centralizado: controle o acesso por meio de políticas de ID do Microsoft Entra e permissões do Azure DevOps.
  • Recursos de auditoria: acompanhe os padrões de autenticação e acesso por meio de log abrangente.
  • Dimensionar com eficiência: dar suporte a cenários de automação empresarial sem dependências individuais do usuário.

Autenticação moderna

  • Baseado em padrões: usa os protocolos OAuth 2.0 e OpenID Connect.
  • Suporte à autenticação multifator: herda políticas de segurança organizacional.
  • Acesso condicional: aplica políticas de segurança avançadas com base no contexto.

Entender entidades de serviço e identidades gerenciadas

Entidades de serviço

Princípios de serviço são objetos do Microsoft Entra que representam aplicativos dentro de um tenant. Eles definem o que um aplicativo pode fazer, quais recursos ele pode acessar e quem pode usá-lo. As entidades de serviço são criadas automaticamente quando você registra um aplicativo no Microsoft Entra ID e fornece uma maneira segura para os aplicativos autenticarem e acessarem os recursos.

Principais características

  • São criados por meio do registro de aplicativo na ID do Microsoft Entra.
  • Suporte a cenários multilocatários.
  • Exigir gerenciamento explícito de credenciais (certificados ou segredos do cliente).
  • São ideais para aplicativos que precisam ser autenticados em ambientes diferentes.

Identidades gerenciadas

As identidades gerenciadas são um tipo especial de entidade de serviço que o Azure gerencia automaticamente. Eles eliminam a necessidade de os desenvolvedores gerenciarem credenciais fornecendo uma identidade gerenciada automaticamente na ID do Microsoft Entra para recursos do Azure.

Tipos de identidades gerenciadas

Identidade gerenciada atribuída pelo sistema:

  • Criado e vinculado automaticamente a um recurso específico do Azure.
  • Ciclo de vida gerenciado pelo Azure (excluído quando o recurso é excluído).
  • Relação um-para-um com o recurso do Azure.
  • Melhor para aplicativos implantados em um único recurso do Azure.

Identidade gerenciada atribuída pelo usuário:

  • Criado como um recurso autônomo do Azure.
  • Pode ser atribuído a vários recursos do Azure.
  • Ciclo de vida gerenciado independentemente dos recursos associados.
  • Melhor para aplicativos que são executados em vários recursos ou precisam de identidade compartilhada.

Quando usar cada tipo:

  • Entidades de serviço: implantações entre nuvens, integração contínua e pipelines de CI/CD (entrega contínua), aplicativos fora do Azure.
  • Identidades gerenciadas atribuídas pelo sistema: aplicativos de recursos únicos do Azure (Azure Functions, Serviço de Aplicativo do Azure).
  • Identidades gerenciadas atribuídas pelo usuário: aplicativos de vários recursos, cenários de identidade compartilhada.

Guia de implementação

Siga estas etapas para implementar entidades de serviço ou identidades gerenciadas para autenticação do Azure DevOps. Para obter exemplos de código completos, consulte nossos aplicativos de exemplo.

Etapa 1: Criar sua identidade

Escolha o tipo de identidade apropriado com base no cenário de implantação.

Opção A: Criar um principal de serviço (registro de aplicação)

As entidades de serviço funcionam bem para pipelines de CI/CD, cenários entre nuvens e aplicativos que precisam de opções de implantação flexíveis.

  1. Registre um aplicativo no Centro de administração do Microsoft Entra.

  2. Vá para Registros de aplicativo>Novo registro.

  3. Configure o aplicativo:

    • Nome: use um nome descritivo para seu aplicativo.
    • Tipos de conta: selecione o suporte ao locatário apropriado.
    • URI de redirecionamento: deixe em branco para cenários de serviço a serviço.

  4. Criar credenciais de autenticação:

    • Recomendado: carregar um certificado para segurança aprimorada.
    • Alternativa: criar um segredo do cliente (requer rotação regular).

Importante

Quando você registra um aplicativo, o Azure cria um objeto de aplicativo e um objeto de entidade de serviço. Use a ID do objeto da entidade de serviço (encontrada no painel Aplicativos Empresariais ) quando você a adicionar ao Azure DevOps, não à ID do objeto do aplicativo.

Para obter mais informações, consulte os seguintes artigos:

Opção B: criar uma identidade gerenciada

As identidades gerenciadas fornecem a experiência de autenticação mais simples para aplicativos hospedados no Azure.

Para a identidade gerenciada atribuída pelo sistema:

  1. Vá para o recurso do Azure, como o Serviço de Aplicativo ou um aplicativo do Azure Functions.
  2. Vá para Identidade>Sistema atribuído.
  3. Alterne o status para Ativado.
  4. Selecione Salvar para salvar a configuração.

Para a identidade gerenciada atribuída pelo usuário:

  1. Crie a identidade gerenciada no portal do Azure.
  2. Acesse Criar uma Identidade Gerenciada> do Recurso.
  3. Defina as configurações básicas e crie o recurso.
  4. Atribua aos recursos, conforme necessário.

Para obter mais informações, consulte os seguintes artigos:

Etapa 2: Adicionar a identidade ao Azure DevOps

Depois de criar sua identidade na ID do Microsoft Entra, adicione-a à sua organização do Azure DevOps para conceder acesso aos recursos.

Pré-requisitos

  • Função de administrador da coleção de projetos.
  • Função de administrador de projeto ou administrador de equipe quando a política de convite permite que os administradores da equipe adicionem usuários.

Adicionar a identidade

Para adicionar a identidade por meio do portal do Azure DevOps:

  1. Vá paraUsuários de > da Organização.

  2. Selecione Adicionar usuários.

  3. Insira o nome de exibição da entidade de serviço ou da identidade gerenciada.

  4. Selecione o nível de acesso apropriado e o acesso ao projeto.

  5. Envie o convite.

    Captura de tela que mostra entidades de serviço e identidades gerenciadas no Hub de Usuários.

Adicione a identidade programaticamente:

Use a API REST ServicePrincipalEntitlements para automatizar o processo.

Outras considerações:

  • Localize a ID correta: Use a ID do objeto da entidade de serviço no painel Aplicativos Empresariais no Centro de administração do Microsoft Entra, não a ID do objeto do registro do aplicativo.
  • Restrições de locatário: Você pode adicionar identidades somente do mesmo locatário ao qual sua organização do Azure DevOps está conectada. Para cenários entre locatários, consulte a Solução alternativa de perguntas frequentes.

Etapa 3: Configurar permissões

Configure permissões granulares para sua entidade de serviço ou identidade gerenciada no Azure DevOps. Ao contrário de outros serviços do Azure, o Azure DevOps usa seu próprio modelo de permissão em vez de permissões de aplicativo do Microsoft Entra.

Opções de permissão:

  • Atribuição direta: atribua permissões diretamente à identidade.
  • Associação de grupo: adicionar a grupos de segurança do Azure DevOps ou do Microsoft Entra.
  • Níveis de acesso: atribuir o nível de licença apropriado (Basic, Basic + Test Plans ou assinante do Visual Studio).

Práticas recomendadas:

  • Aplicar privilégios mínimos: conceda apenas as permissões mínimas necessárias.
  • Usar grupos: gerenciar permissões por meio de grupos para facilitar a manutenção.
  • Revisões regulares: permissões de auditoria periodicamente.

Opções de gerenciamento de permissões:

Importante

Permissões do Azure DevOps versus Microsoft Entra: O Azure DevOps não usa permissões de aplicativo do Microsoft Entra ID. Todo o controle de acesso é gerenciado por meio do sistema de permissões do Azure DevOps, que permite permissões granulares de projeto e de nível de recurso.

Etapa 4: Obter tokens de ID do Microsoft Entra

Obtenha tokens de acesso para autenticar seus aplicativos com APIs e serviços do Azure DevOps.

Para entidades de serviço

Use o fluxo de credenciais do cliente:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

Usar autenticação de certificado (recomendado):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

Para identidades gerenciadas

Dos recursos do Azure:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

Use o Serviço de Metadados de Instância do Azure:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://app.vssps.visualstudio.com/
Metadata: true

CLI do Azure para operações ad hoc

Para operações ou testes únicos, use a CLI do Azure:

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --resource https://app.vssps.visualstudio.com/

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --resource https://app.vssps.visualstudio.com/

Para obter mais informações, consulte Adquirir tokens do Microsoft Entra.

Etapa 5: usar tokens com o Azure DevOps

Use os tokens adquiridos para autenticar chamadas à API REST e outras operações do Azure DevOps.

Faça chamadas de API autenticadas:

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");

Exemplos de vídeo

Cenários comuns de integração

Para obter exemplos de código completos, consulte nossos aplicativos de exemplo.

Considerações de gerenciamento

Entidades de serviço e identidades gerenciadas têm características de gerenciamento diferentes em comparação com contas de usuário.

Licenciamento

  • Cada identidade requer uma licença em cada organização em que ingressar.
  • A cobrança de várias organizações não se aplica às entidades de serviço.
  • As regras de licenciamento baseadas em grupo não se aplicam automaticamente. Você deve atribuir licenças diretamente.

Gerenciamento de identidades

  • Endereços de email não são usados, portanto, não há convites por email.
  • Nomes de exibição ou avatares não são modificados no Azure DevOps.
  • Os nomes de exibição são herdados da ID do Microsoft Entra.

Associação de grupo

  • Pode ser adicionado aos grupos do Microsoft Entra e aos grupos do Azure DevOps.
  • Tem uma limitação técnica que impede a exibição em listas de membros do grupo do Microsoft Entra (somente limitação de interface do usuário).
  • Ainda é possível herdar permissões de grupos do Microsoft Entra aos quais pertencem.

Materialização

  • Deve ser explicitamente adicionado às organizações (sem materialização automática como usuários).
  • Necessário porque as entidades de serviço não podem entrar interativamente.

Principais diferenças das contas de usuário

Entidades de serviço e identidades gerenciadas têm limitações específicas em comparação com usuários regulares.

Capabilities

  • ✅ Gere tokens do Microsoft Entra para acesso à API.
  • ✅ Acesse os recursos do Azure DevOps com permissões adequadas.
  • ✅ Junte-se a grupos de segurança e equipes.
  • ❌ Crie PATs ou chaves do Secure Shell.
  • ❌ Entre interativamente ou acesse por meio de uma interface do usuário da Web.
  • ❌ Criar ou possuir organizações.
  • ❌ Suporte a fluxos OAuth do Azure DevOps .

Faturamento

  • Contada como uma licença separada em cada organização. (Não há desconto para várias organizações.)
  • Deve atribuir o nível de acesso diretamente. (As regras de grupo não se aplicam automaticamente.)

Perguntas frequentes

Q. Por que devo usar uma entidade de serviço ou uma identidade gerenciada em vez de um PAT?

A. Entidades de serviço e identidades gerenciadas oferecem vantagens significativas de segurança sobre PATs.

Benefícios de segurança:

  • Tempo de vida mais curto: os tokens do Microsoft Entra expiram por hora em comparação com pats, que podem durar até um ano.
  • Rotação automática: as identidades gerenciadas giram as credenciais automaticamente.
  • Nenhum segredo compartilhado: o risco de armazenar ou expor acidentalmente tokens de longa duração é eliminado.
  • Controle centralizado: gerenciado por meio da ID do Microsoft Entra com políticas de segurança da empresa.

Benefícios operacionais:

  • Trilha de auditoria: logs autenticação e padrões de acesso completamente.
  • Acesso condicional: aplica políticas com base em fatores de localização, dispositivo e risco.
  • Nenhuma conta de serviço: elimina a dependência de contas de usuário individuais para automação.

Para obter exemplos de migração, consulte Substituir PATs por tokens do Microsoft Entra.

Q. Quais são os limites de taxa em entidades de serviço e identidades gerenciadas?

A. Entidades de serviço e identidades gerenciadas têm os mesmos limites de taxa que os usuários .

Q. Usar esse recurso custará mais?

A. Entidades de serviço e identidades gerenciadas têm preços como usuários com base no nível de acesso. As principais diferenças são:

  • Sem desconto de cobrança de várias organizações: cada identidade conta como uma licença separada em cada organização.
  • Atribuição de licença: os níveis de acesso devem ser atribuídos diretamente. (As regras de grupo não se aplicam automaticamente.)
  • Os mesmos tipos de preço: Taxas básicas, básicas + planos de teste e assinantes do Visual Studio se aplicam.

Q. Posso adicionar uma identidade gerenciada de um locatário diferente à minha organização?

A. Você pode adicionar identidades diretamente do locatário conectado da sua organização. Para cenários entre locatários, use essa solução alternativa.

Para configurar uma identidade gerenciada entre locatários:

  1. Crie uma identidade gerenciada atribuída pelo usuário no locatário do recurso.
  2. Atribua-o a um recurso do Azure, como uma máquina virtual ou um aplicativo do Functions).
  3. Crie um cofre de chaves e gere um certificado (formato não PEM).
  4. Conceda acesso de identidade gerenciada ao cofre de chaves com as permissões de segredo Obter e Listar .
  5. Baixe o certificado no formato CER (somente chave pública).
  6. Registre o aplicativo no locatário de destino.
  7. Carregue o certificado no registro do aplicativo.
  8. Adicione a entidade de serviço à organização do Azure DevOps.
  9. Configure a autenticação usando o certificado do cofre de chaves.
// Example: Acquire token using managed identity certificate
public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
    var keyVaultUri = new Uri($"https://{keyVaultName}.vault.azure.net");
    var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
    var keyVaultSecret = await client.GetSecretAsync(secretName);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

Importante

Gire certificados regularmente para melhores práticas de segurança.

Erros e soluções comuns

O repositório Git com nome ou identificador não existe ou você não tem permissões

Solução: Verifique se a entidade de serviço tem pelo menos uma licença Básica. As licenças de stakeholders não fornecem acesso ao repositório.

Falha ao criar a entidade de serviço com a ID do objeto

Solução: Verifique se você está usando a ID de objeto da entidade de serviço do painel aplicativos Enterprise , não a ID do objeto do registro do aplicativo.

Para localizar a ID correta:

  1. Acesse osaplicativos enterprise do > do Microsoft Entra.
  2. Pesquise o nome do aplicativo.
  3. Use a ID do objeto no painel Aplicativos Empresariais .

Acesso negado: precisa de permissões para adicionar usuários

Possíveis causas e soluções:

  • Função insuficiente: deve ser um PCA (administrador de coleção de projetos) ou um administrador de projeto ou equipe com permissões de convite habilitadas.
  • Restrição de política: verifique se a política Permitir que a equipe e os administradores do projeto convidem novos usuários está habilitada.
  • Atribuição de licença: os administradores do projeto não podem atribuir licenças durante o convite. Entre em contato com o PCA para obter alterações de licença.

API de Lista de Gráficos do Azure DevOps retorna uma lista vazia

Solução: Use continuationToken para iterar em todas as páginas. As entidades de serviço podem aparecer em páginas posteriores devido ao comportamento de paginação da API.

Erro de necessidade de login

Solução: Verifique se a entidade de serviço é adicionada corretamente à organização com as permissões necessárias. Esse erro indica que a identidade não é reconhecida na organização.

Conteúdo relacionado

  • Last updated on