Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este guia fornece opções de configuração para o Microsoft Entra SDK para o AgentID, um serviço de autenticação containerizada que trata da aquisição e gestão de tokens para aplicações em ambientes containerizados. O SDK simplifica a integração de identidade ao gerir a autenticação do Microsoft Entra ID, fluxos de tokens on-behalf-of (OBO) e chamadas de API a jusante sem exigir que as aplicações incorporem diretamente as bibliotecas de autenticação.
Embora este guia se foque nos padrões de implementação do Kubernetes, o SDK pode ser implementado em qualquer ambiente containerizado, incluindo Docker, Azure Container Instances e outras plataformas de orquestração de contentores.
Se está a implementar no Azure Kubernetes Service (AKS), a configurar ambientes de desenvolvimento ou a configurar cargas de trabalho, esta referência abrange padrões de configuração, tipos de credenciais e variáveis de ambiente necessárias para proteger as suas aplicações com o Microsoft Entra ID.
Descrição geral da configuração
O Microsoft Entra SDK para Agent ID é configurado usando fontes de configuração seguindo as convenções ASP.NET Core. Os valores de configuração podem ser fornecidos através de vários métodos, incluindo:
- Variáveis de ambiente (recomendado para Kubernetes)
- Entra ID configuração - ficheiro
appsettings.jsonanexado ao contentor ou incorporado no ficheiro yaml. - Argumentos de linha de comando
- Azure App Configuration ou Key Vault (para cenários avançados)
Definições do Core Entra ID
O Microsoft Entra SDK para implementações de Agent ID requer definições centrais do Entra ID para autenticar tokens recebidos e adquirir tokens para APIs posteriores. Use as credenciais de cliente apropriadas no seguinte formato YAML, normalmente como variáveis de ambiente, para garantir a autenticação segura.
Configuração necessária
Primeiro, configure as definições centrais do Entra ID para o SDK para autenticar tokens recebidos e adquirir tokens para APIs a jusante.
env:
- name: AzureAd__Instance
value: "https://login.microsoftonline.com/"
- name: AzureAd__TenantId
value: "<your-tenant-id>"
- name: AzureAd__ClientId
value: "<your-client-id>"
| Key | Description | Obrigatório | Predefinido |
|---|---|---|---|
AzureAd__Instance |
URL de autoridade Microsoft Entra | Não | https://login.microsoftonline.com/ |
AzureAd__TenantId |
O seu ID de inquilino Microsoft Entra | Yes | - |
AzureAd__ClientId |
ID da aplicação (cliente) | Yes | - |
AzureAd__Audience |
Público esperado em tokens recebidos | Não | api://{ClientId} |
AzureAd__Scopes |
Escopos necessários para tokens de entrada (separados por espaço) | Não | - |
Observação
O valor do público esperado depende do requestedAccessTokenVersion do registro do seu aplicativo:
-
Versão 2: Use o
{ClientId}valor diretamente -
Versão 1 ou nula: use o URI da ID do aplicativo (normalmente
api://{ClientId}, a menos que você o personalize)
Configuração de credenciais do cliente
O Microsoft Entra SDK para Agent ID suporta múltiplos tipos de credenciais de cliente para autenticação com o Microsoft Entra ID ao adquirir tokens para APIs downstream. Escolha o tipo de credencial que melhor se adapta ao seu ambiente de implantação e aos requisitos de segurança e certifique-se de que a configuração escolhida seja apropriada para o seu cenário.
Cada tipo de credencial atende a diferentes cenários:
- Segredo do cliente: Configuração simples para desenvolvimento e testes (não recomendado para produção)
- Key Vault Certificate: Ambientes de produção com gestão centralizada de certificados
- Certificado de arquivo: Quando os certificados são montados como arquivos (por exemplo, via segredos do Kubernetes)
- Certificate Store: Windows ambientes com armazenamento de certificados
- Workload Identity for Containers: Recomendado para AKS, usando ID de carga de trabalho Microsoft Entra com projeção de tokens baseada em ficheiros
- Identidade Gerida para VMs/Serviços de Aplicação: Serviços de Máquinas Virtuais do Azure e Aplicações com identidades geridas atribuídas pelo sistema ou pelo utilizador (não para contentores)
Configure uma ou mais fontes de credenciais no seguinte formato YAML:
Segredo do cliente
Esta configuração configura a autenticação Entra ID usando um cliente secret para autenticação serviço-a-serviço.
- name: AzureAd__ClientCredentials__0__SourceType
value: "ClientSecret"
- name: AzureAd__ClientCredentials__0__ClientSecret
value: "<your-client-secret>"
Certificado da Key Vault
Esta configuração configura a autenticação Entra ID usando um certificado armazenado no Azure Key Vault.
- name: AzureAd__ClientCredentials__0__SourceType
value: "KeyVault"
- name: AzureAd__ClientCredentials__0__KeyVaultUrl
value: "https://<your-keyvault>.vault.azure.net"
- name: AzureAd__ClientCredentials__0__KeyVaultCertificateName
value: "<certificate-name>"
Certidão do ficheiro
Esta configuração configura a autenticação Entra ID usando um certificado armazenado como ficheiro.
- name: AzureAd__ClientCredentials__0__SourceType
value: "Path"
- name: AzureAd__ClientCredentials__0__CertificateDiskPath
value: "/path/to/certificate.pfx"
- name: AzureAd__ClientCredentials__0__CertificatePassword
value: "<certificate-password>"
Certificado da loja
Esta configuração configura a autenticação Entra ID usando um certificado da loja local de certificados.
- name: AzureAd__ClientCredentials__0__SourceType
value: "StoreWithThumbprint"
- name: AzureAd__ClientCredentials__0__CertificateStorePath
value: "CurrentUser/My"
- name: AzureAd__ClientCredentials__0__CertificateThumbprint
value: "<thumbprint>"
Identidade da carga de trabalho para contêineres (recomendado para AKS)
Esta configuração configura a autenticação Entra ID usando o ID de carga de trabalho Microsoft Entra para implementações containerizadas (AKS). Essa é a abordagem recomendada para cenários baseados em contêiner, pois usa projeção de token baseada em arquivo.
- name: AzureAd__ClientCredentials__0__SourceType
value: "SignedAssertionFilePath"
Nota: O caminho do ficheiro de token /var/run/secrets/azure/tokens/azure-identity-token ou uma variável de ambiente é projetado automaticamente pelo webhook Azure Workload Identity quando o seu pod está devidamente configurado com a anotação da conta de serviço e o rótulo do pod. Consulte Usando o Managed Identity para obter instruções de configuração completas.
Identidade gerenciada para VMs e Serviços de Aplicativo
Para cenários clássicos Azure de Identidade Gerida em Máquinas Virtuais ou Serviços de Aplicação (não contentores), use SignedAssertionFromManagedIdentity:
- name: AzureAd__ClientCredentials__0__SourceType
value: "SignedAssertionFromManagedIdentity"
- name: AzureAd__ClientCredentials__0__ManagedIdentityClientId
value: "<managed-identity-client-id>"
Importante: Não use SignedAssertionFromManagedIdentity para ambientes em contêineres (Kubernetes, AKS, Docker). Para AKS, use SignedAssertionFilePath como mostrado acima. Para Kubernetes e Docker, use certificados de cliente. Para mais informações, consultar: https://aka.ms/idweb/client-credentials
Recursos adicionais
Para obter detalhes completos sobre todas as opções de configuração de credenciais e seu uso, consulte a especificação CredentialDescription no repositório microsoft-identity-abstractions-for-dotnet.
Prioridade de credenciais
Configure várias credenciais com seleção baseada em prioridades:
# First priority - Key Vault certificate
- name: AzureAd__ClientCredentials__0__SourceType
value: "KeyVault"
- name: AzureAd__ClientCredentials__0__KeyVaultUrl
value: "https://prod-keyvault.vault.azure.net"
- name: AzureAd__ClientCredentials__0__KeyVaultCertificateName
value: "prod-cert"
# Second priority - Client secret (fallback)
- name: AzureAd__ClientCredentials__1__SourceType
value: "ClientSecret"
- name: AzureAd__ClientCredentials__1__ClientSecret
valueFrom:
secretKeyRef:
name: app-secrets
key: client-secret
O Microsoft Entra SDK para ID de Agente avalia as credenciais por ordem numérica (0, 1, 2, etc.) e utiliza a primeira credencial que autentica com sucesso.
Configuração de APIs downstream
Configure APIs downstream que seu aplicativo precisa chamar usando fluxos de token on-behalf-of (OBO). O Microsoft Entra SDK para Agent ID gere a aquisição de tokens e fornece cabeçalhos de autenticação para estas chamadas API. Cada API downstream requer um nome de configuração exclusivo e parâmetros específicos para aquisição de token e tratamento de solicitações HTTP.
Defina cada API downstream com sua URL base, escopos necessários e parâmetros opcionais. O SDK manipulará automaticamente a aquisição de token usando o token de usuário de entrada e fornecerá os cabeçalhos de autorização apropriados para as chamadas de API do seu aplicativo.
- name: DownstreamApis__Graph__BaseUrl
value: "https://graph.microsoft.com/v1.0"
- name: DownstreamApis__Graph__Scopes
value: "User.Read Mail.Read"
- name: DownstreamApis__Graph__RelativePath
value: "/me"
- name: DownstreamApis__MyApi__BaseUrl
value: "https://api.contoso.com"
- name: DownstreamApis__MyApi__Scopes
value: "api://myapi/.default"
| Padrão de chave | Description | Obrigatório |
|---|---|---|
DownstreamApis__<Name>__BaseUrl |
URL base da API | Yes |
DownstreamApis__<Name>__Scopes |
Escopos separados por espaço para solicitação | Yes |
DownstreamApis__<Name>__HttpMethod |
Método HTTP padrão | Não (GET) |
DownstreamApis__<Name>__RelativePath |
Caminho relativo padrão | Não |
DownstreamApis__<Name>__RequestAppToken |
Usar token de aplicativo em vez de OBO | Não (falso) |
Opções de aquisição de tokens
Ajuste o comportamento de aquisição de tokens:
- name: DownstreamApis__Graph__AcquireTokenOptions__Tenant
value: "<specific-tenant-id>"
- name: DownstreamApis__Graph__AcquireTokenOptions__AuthenticationScheme
value: "Bearer"
- name: DownstreamApis__Graph__AcquireTokenOptions__CorrelationId
value: "<correlation-id>"
Configuração de pedido HTTP assinado (SHR)
Habilite solicitações HTTP assinadas para maior segurança:
- name: DownstreamApis__SecureApi__AcquireTokenOptions__PopPublicKey
value: "<base64-encoded-public-key>"
- name: DownstreamApis__SecureApi__AcquireTokenOptions__PopClaims
value: '{"custom_claim": "value"}'
Configuração de registro em log
Configure os níveis de log:
- name: Logging__LogLevel__Default
value: "Information"
- name: Logging__LogLevel__Microsoft.Identity.Web
value: "Debug"
- name: Logging__LogLevel__Microsoft.AspNetCore
value: "Warning"
Definições ASP.NET Core
- name: ASPNETCORE_ENVIRONMENT
value: "Production"
- name: ASPNETCORE_URLS
value: "http://+:5000"
Per-Request substituições de configuração
Todos os pontos de extremidade de aquisição de token aceitam parâmetros de consulta para substituir a configuração:
# Override scopes
GET /AuthorizationHeader/Graph?optionsOverride.Scopes=User.Read&optionsOverride.Scopes=Mail.Read
# Request app token instead of OBO
GET /AuthorizationHeader/Graph?optionsOverride.RequestAppToken=true
GET /AuthorizationHeaderUnauthenticated/Graph?optionsOverride.RequestAppToken=true
# Override tenant
GET /AuthorizationHeader/Graph?optionsOverride.AcquireTokenOptions.Tenant=<tenant-id>
# Override relative path
GET /DownstreamApi/Graph?optionsOverride.RelativePath=me/messages
# Enable SHR for this request
GET /AuthorizationHeader/Graph?optionsOverride.AcquireTokenOptions.PopPublicKey=<base64-key>
Substituições de identidade de agente
Especifique a identidade do agente no momento da solicitação:
# Autonomous agent
GET /AuthorizationHeader/Graph?AgentIdentity=<agent-client-id>
# Autonomous agent with specific agent user identity (by username)
GET /AuthorizationHeader/Graph?AgentIdentity=<agent-client-id>&AgentUsername=user@contoso.com
# Autonomous agent with specific agent user identity (by object ID)
GET /AuthorizationHeader/Graph?AgentIdentity=<agent-client-id>&AgentUserId=<user-object-id>
Regras importantes:
-
AgentUsernameeAgentUserIdrequererAgentIdentity -
AgentUsernameeAgentUserIdexcluem-se mutuamente
Consulte Identidades de agente para obter semântica detalhada.
Exemplo de configuração completa
A seguir é apresentado um exemplo pronto para produção mostrando como implantar o SDK com separação adequada de configuração e segredos. Este exemplo demonstra a configuração de várias APIs downstream, o uso do Kubernetes ConfigMaps para configurações não confidenciais, o armazenamento seguro de credenciais em Secrets e a aplicação de configurações específicas do ambiente para implantação segura.
Esse padrão segue as práticas recomendadas do Kubernetes, separando dados de configuração de credenciais confidenciais, permitindo o gerenciamento eficaz de diferentes ambientes e mantendo a segurança.
Kubernetes ConfigMap
O ConfigMap armazena definições de configuração não sensíveis para o SDK, incluindo definições do Entra ID, APIs downstream e níveis de registo.
apiVersion: v1
kind: ConfigMap
metadata:
name: sidecar-config
data:
ASPNETCORE_ENVIRONMENT: "Production"
ASPNETCORE_URLS: "http://+:5000"
AzureAd__Instance: "https://login.microsoftonline.com/"
AzureAd__TenantId: "common"
AzureAd__ClientId: "your-app-client-id"
AzureAd__Scopes: "access_as_user"
DownstreamApis__Graph__BaseUrl: "https://graph.microsoft.com/v1.0"
DownstreamApis__Graph__Scopes: "User.Read Mail.Read"
DownstreamApis__MyApi__BaseUrl: "https://api.contoso.com"
DownstreamApis__MyApi__Scopes: "api://myapi/.default"
Logging__LogLevel__Default: "Information"
Logging__LogLevel__Microsoft.Identity.Web: "Debug"
Segredo do Kubernetes
O Secret armazena credenciais confidenciais, como segredos de cliente, separadamente do ConfigMap.
apiVersion: v1
kind: Secret
metadata:
name: sidecar-secrets
type: Opaque
stringData:
AzureAd__ClientCredentials__0__ClientSecret: "your-client-secret"
Implantação com ConfigMap e segredo
A implantação monta o ConfigMap e o Secret no contêiner do SDK, garantindo que a configuração e as credenciais estejam separadas corretamente.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
template:
spec:
containers:
- name: sidecar
image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
envFrom:
- configMapRef:
name: sidecar-config
- secretRef:
name: sidecar-secrets
Configuração específica do ambiente
Configure configurações específicas do ambiente para personalizar a segurança, o registro em log e o isolamento de locatários para seus ambientes de implantação. Cada ambiente requer diferentes abordagens de configuração para equilibrar a eficiência do desenvolvimento, a validação de preparo e os requisitos de segurança da produção.
Desenvolvimento
- name: ASPNETCORE_ENVIRONMENT
value: "Development"
- name: Logging__LogLevel__Default
value: "Debug"
- name: AzureAd__TenantId
value: "<dev-tenant-id>"
Staging
- name: ASPNETCORE_ENVIRONMENT
value: "Staging"
- name: Logging__LogLevel__Default
value: "Information"
- name: AzureAd__TenantId
value: "<staging-tenant-id>"
Produção
- name: ASPNETCORE_ENVIRONMENT
value: "Production"
- name: Logging__LogLevel__Default
value: "Warning"
- name: Logging__LogLevel__Microsoft.Identity.Web
value: "Information"
- name: AzureAd__TenantId
value: "<prod-tenant-id>"
- name: ApplicationInsights__ConnectionString
value: "<app-insights-connection>"
Validation
O Microsoft Entra SDK para ID de Agente valida a configuração no arranque e regista erros para:
- Configurações necessárias ausentes (
TenantId,ClientId) - Configurações de credenciais inválidas
- Definições de API a jusante malformadas
- URLs ou formatos de escopo inválidos
Verifique os logs de contêiner para mensagens de validação:
kubectl logs <pod-name> -c sidecar
Melhores práticas
- Use Secrets for Credentials: Armazena segredos e certificados de clientes no Kubernetes Secrets ou Azure Key Vault. Ver também https://aka.ms/msidweb/client-credentials
- Configuração separada por ambiente: use o ConfigMaps para gerenciar configurações específicas do ambiente
- Habilitar registro em log apropriado: usar o log de depuração no desenvolvimento, informações/avisos na produção
- Configurar verificações de integridade: verifique se os pontos de extremidade de verificação de integridade estão configurados corretamente
-
Use Identidade de Carga de Trabalho para Containers: Para implementações containerizadas (AKS), prefira ID de carga de trabalho Microsoft Entra com
SignedAssertionFilePathem vez de segredos de cliente para maior segurança - Use Identidade Gerida para VMs/Serviços de Aplicação: Para VMs e Serviços de Aplicações Azure, utilize identidades geridas atribuídas pelo sistema ou pelo utilizador
- Validar no momento da implantação: testar a configuração no preparo antes da implantação da produção