Agent-identiteit in Azure SRE Agent

Wanneer u een agent maakt, richt Azure automatisch identiteitsbronnen in. In dit artikel wordt uitgelegd wat er wordt gemaakt, waarom er twee identiteiten bestaan en hoe connectors deze gebruiken.

Zie Agentmachtigingen voor informatie over hoe uw agent machtigingen krijgt voor Azure-resources (RBAC-rollen, machtigingsniveaus, namensstroom).

Wat wordt gemaakt

Er worden samen met uw agent twee beheerde identiteiten gemaakt.

Identiteit Wat het is Wat je ermee doet
Door de gebruiker toegewezen beheerde identiteit (UAMI) Een zelfstandige identiteitsresource in uw resourcegroep Wijs RBAC-rollen toe en selecteer deze bij het instellen van connectors. Dit is de identiteit die u beheert
Door het systeem toegewezen beheerde identiteit Een interne identiteit die wordt gebruikt door de infrastructuur van de agent Niets: deze identiteit wordt automatisch beheerd en alleen gebruikt voor interne bewerkingen

De UAMI is de identiteit waarmee u werkt. Deze wordt weergegeven in uw resourcegroep, u wijst er RBAC-rollen aan toe en selecteert u deze bij het instellen van connectors.

Aanbeveling

Wanneer u een vervolgkeuzelijst voor beheerde identiteit in de portal ziet (voor connectors, opslagplaatsen of andere integraties), selecteert u de UAMI van uw agent. Dit is de identiteit die overeenkomt met uw RBAC-roltoewijzingen.

Waar de UAMI van uw agent wordt gebruikt

De UAMI van uw agent is de primaire identiteit voor de meeste bewerkingen.

Operatie Identiteit Aantekeningen
Azure-resourcebewerkingen (Azure Resource Manager, CLI, diagnostische gegevens) UAMI De RBAC-rollen die u toewijst, bepalen waartoe de agent toegang heeft
Communicatie-verbinders (Outlook, Teams) UAMI + uw OAuth-referenties U meldt zich aan via OAuth; de UAMI handelt de verificatie voor de connector-resource af.
Gegevenskoppelingen (Azure Data Explorer) UAMI De UAMI-machtigingen verlenen voor het Kusto-doelcluster
Broncode-connectors (GitHub, Azure DevOps) UAMI (voor door Azure DevOps beheerde identiteit) Azure DevOps-connector maakt gebruik van UAMI; GitHub maakt gebruik van OAuth
MCP-connectors Varies U geeft eindpunt-URL en referenties op; eventueel een beheerde identiteit toewijzen voor downstream Azure-aanroepen
Interne infrastructuur UAMI Automatisch gebruikt voor de interne bewerkingen van de agent
Key Vault UAMI (bij voorkeur) of toegewezen door het systeem Valt terug op systeem toegewezen als er geen UAMI is opgegeven

Hoe connectors identiteit gebruiken

Verschillende connectortypen gebruiken identiteiten anders. Het belangrijkste onderscheid is of de connector via Azure Resource Manager (ARM) moet gaan om de externe service te bereiken.

Communicatieconnectors (Outlook, Teams)

Wanneer u een communicatieconnector instelt, gebeuren er twee dingen:

  1. U meldt zich aan met uw account via OAuth, waarmee de connector uw gebruikersreferenties krijgt.
  2. U selecteert een UAMI in de vervolgkeuzelijst identiteit, die door de connector wordt gebruikt voor verificatie bij de connectorresource.

De connector slaat uw OAuth-token veilig op in een connectorresource. De connector-dienst fungeert als een beveiligde brug. De resource bevat uw referenties, zodat de agent geen directe toegang tot deze resources nodig heeft. Er wordt gebruikgemaakt van de UAMI om de verificatie te brokeren wanneer de agent namens u een e-mailbericht verzendt of een Teams-bericht plaatst.

Gegevensconnectoren (Azure Data Explorer/Kusto)

Voor Kusto-connectors gebruikt de agent de UAMI rechtstreeks om te verifiëren bij uw Azure Data Explorer-cluster. Er is geen OAuth-aanmelding nodig. Geef de UAMI de vereiste machtigingen, zoals de rol Kijker op het Kusto-cluster.

Broncode-connectors (GitHub, Azure DevOps)

Broncode-connectors gebruiken verschillende authenticatiemethoden, afhankelijk van het platform.

  • Azure DevOps: Maakt gebruik van de UAMI voor verificatie van beheerde identiteiten. Selecteer de UAMI in de vervolgkeuzelijst identiteit en geef deze toegang tot uw Azure DevOps-organisatie.
  • GitHub: Maakt gebruik van OAuth-verificatie. Meld u aan met uw GitHub-account. Er is geen beheerde identiteit nodig voor de GitHub-verbinding zelf.

Aangepaste MCP-connectors

MCP-connectors maken gebruik van verificatie op basis van eindpunten. Geef de URL van de MCP-server op, samen met referenties, zoals een API-sleutel, Bearer-token of OAuth. U kunt eventueel een beheerde identiteit toewijzen voor de MCP-server die moet worden gebruikt bij het maken van downstream Azure API-aanroepen.

UAMI van uw agent zoeken

U kunt de door de gebruiker toegewezen beheerde identiteit van uw agent vinden via de agentportal, De Azure-portal of de Azure CLI.

Vanuit de agentportal:

  1. Ga naar Instellingen>voor Azure-instellingen.
  2. De identiteitsnaam wordt weergegeven in het veld Beheerde identiteit .
  3. Selecteer Ga naar identiteit om deze te openen in Azure Portal.

Vanuit Azure Portal:

  1. Ga naar de resourcegroep van uw agent.
  2. Zoek de id-* beheerde identiteitsresource.
  3. Kopieer de object-id (principal). Gebruik deze waarde voor RBAC-roltoewijzingen.

Vanuit Azure CLI:

# List user-assigned identities on the agent resource
az resource show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <AGENT_NAME> \
  --resource-type Microsoft.App/containerApps \
  --query identity.userAssignedIdentities

Volgende stap

Agentmachtigingen configureren

Verwante inhoud

  • Last updated on