Delen via

Wat zijn beheerde identiteiten voor Azure-resources?

  • Artikel

Een veelvoorkomende uitdaging voor ontwikkelaars is het beheer van geheimen, referenties, certificaten en sleutels om communicatie tussen services te beveiligen. Manual handling of secrets and certificates are a known source of security issues and outages. Dankzij beheerde identiteiten hoeven ontwikkelaars geen referenties meer te beheren. Toepassingen kunnen beheerde identiteiten gebruiken om Microsoft Entra-tokens te verkrijgen zonder referenties te hoeven beheren.

What are managed identities?

Op hoog niveau zijn er twee soorten identiteiten: menselijke en machine-/niet-menselijke identiteiten. Machine / non-human identities consist of device and workload identities. In Microsoft Entra zijn workloadidentiteiten toepassingen, service-principals en beheerde identiteiten. For more information on workload identities, see workload identities.

A managed identity is an identity that can be assigned to an Azure compute resource (Virtual Machine (VM), Virtual Machine Scale Set (VMSS), Service Fabric Cluster, Azure Kubernetes cluster) or any App hosting platform supported by Azure. Once a managed identity is assigned on the compute resource, it can be authorized, directly or indirectly, to access downstream dependency resources, such as a storage account, SQL database, CosmosDB, and so on. Managed identity replaces secrets such as access keys or passwords. In addition, managed identities can replace certificates or other forms of authentication for service-to-service dependencies.

In de volgende video ziet u hoe u beheerde identiteiten kunt gebruiken:

Hier ziet u een paar voordelen van het gebruik van beheerde identiteiten:

  • U hoeft geen referenties te beheren. Credentials aren’t even accessible to you.
  • U kunt beheerde identiteiten gebruiken om te verifiëren bij elke resource die ondersteuning biedt voor Microsoft Entra-verificatie, inclusief uw eigen toepassingen.
  • Beheerde identiteiten kunnen zonder extra kosten worden gebruikt.

Managed identity types

Er zijn twee typen beheerde identiteit:

  • Door het systeem toegewezen. Met sommige Azure-resources, zoals virtuele machines, kunt u een beheerde identiteit rechtstreeks op de resource inschakelen. Wanneer u een door het systeem toegewezen beheerde identiteit inschakelt:

    • A service principal of a special type is created in Microsoft Entra ID for the identity. De service-principal is gekoppeld aan de levenscyclus van die Azure-resource. When the Azure resource is deleted, Azure automatically deletes the service principal for you.
    • Standaard kan alleen die Azure-resource deze identiteit gebruiken voor het aanvragen van tokens van Microsoft Entra ID.
    • U machtigt de beheerde identiteit om toegang te hebben tot een of meer services.
    • De naam van de door het systeem toegewezen service-principal is altijd dezelfde als de naam van de Azure-resource waarvoor deze is gemaakt. For a deployment slot, the name of its system-assigned identity is <app-name>/slots/<slot-name>.

  • Door de gebruiker toegewezen. U kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. U kunt een door de gebruiker toegewezen beheerde identiteit maken en deze toewijzen aan een of meer Azure-resources. Wanneer u een door de gebruiker toegewezen beheerde identiteit inschakelt:

    • A service principal of a special type is created in Microsoft Entra ID for the identity. The service principal is managed separately from the resources that use it.
    • Door de gebruiker toegewezen identiteiten kunnen door meerdere resources worden gebruikt.
    • U machtigt de beheerde identiteit om toegang te hebben tot een of meer services.

    User-assigned identities, which are provisioned independently from compute and can be assigned to multiple compute resources, are the recommended managed identity type for Microsoft services.

Met resources die door het systeem toegewezen beheerde identiteiten ondersteunen, kunt u het volgende doen:

Als u in plaats daarvan een door een gebruiker toegewezen beheerde identiteit kiest:

Bewerkingen op beheerde identiteiten kunnen worden uitgevoerd met behulp van een Azure Resource Manager-sjabloon, in Azure Portal, met Azure CLI, PowerShell en REST API's.

Differences between system-assigned and user-assigned managed identities

Eigendom Door het systeem toegewezen beheerde identiteit Door de gebruiker toegewezen beheerde identiteit
Creation Gemaakt als onderdeel van een Azure-resource (bijvoorbeeld Microsoft Azure Virtual Machines of Azure App Service). Gemaakt als een zelfstandige Azure-resource.
Life cycle Shared life cycle with the Azure resource that the managed identity is created with.
Wanneer de hoofdresource wordt verwijderd, wordt ook de beheerde identiteit verwijderd.		 Onafhankelijke levenscyclus.
Moet expliciet worden verwijderd.
Delen tussen Azure-resources Kan niet worden gedeeld.
Deze kan alleen worden gekoppeld aan één Azure-resource.		 Kan worden gedeeld.
Dezelfde door de gebruiker toegewezen beheerde identiteit kan worden gekoppeld aan meer dan één Azure-resource.
Veelvoorkomende toepassingen Workloads contained within a single Azure resource.
Workloads needing independent identities.
Bijvoorbeeld een toepassing die op één virtuele machine wordt uitgevoerd.		 Workloads that run on multiple resources and can share a single identity.
Workloads die vooraf moeten worden geautoriseerd voor een beveiligde resource, als onderdeel van een voorzieningsproces.
Workloads where resources are recycled frequently, but permissions should stay consistent.
Bijvoorbeeld een werkbelasting waarbij meerdere virtuele machines toegang moeten hebben tot dezelfde resource.

Hoe gebruik ik beheerde identiteiten voor Azure-resources?

U kunt beheerde identiteiten gebruiken door de onderstaande stappen te volgen:

  1. Maak een beheerde identiteit in Azure. U kunt kiezen tussen een door het systeem toegewezen beheerde identiteit of een door de gebruiker toegewezen beheerde identiteit.
    1. Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, wijst u de beheerde identiteit toe aan de 'bron'-Azure-resource, zoals een virtuele machine, een logische Azure-app of een Azure-web-app.
  2. Autoriseer de beheerde identiteit zodat deze toegang heeft tot de 'doelservice'.
  3. Gebruik de beheerde identiteit om toegang te krijgen tot een resource. In deze stap kunt u de Azure SDK gebruiken met de Azure.Identity-bibliotheek. Sommige 'bronresources' bieden connectors die weten hoe beheerde identiteiten voor de verbindingen moeten worden gebruikt. In dat geval gebruikt u de identiteit als een functie van die 'bronresource'.

Welke Azure-services ondersteunen de functie?

Beheerde identiteiten voor Azure-resources kunnen worden gebruikt voor verificatie bij services die ondersteuning bieden voor Microsoft Entra-verificatie. Zie Services die ondersteuning bieden voor beheerde identiteiten voor Azure-resources voor een lijst met ondersteunde Azure-services.

Work with managed identities

Managed identities can be used directly or as a Federated Identity Credential for Microsoft Entra ID applications.

The steps involved in using managed identities are as follows:

  1. Maak een beheerde identiteit in Azure. U kunt kiezen tussen een door het systeem toegewezen beheerde identiteit of een door de gebruiker toegewezen beheerde identiteit. When using a user-assigned managed identity, you assign the managed identity to the source Azure Resource, such as a Virtual Machine, Azure Logic App or an Azure Web App.
  2. Authorize the managed identity to have access to the target service.
  3. Gebruik de beheerde identiteit om toegang te krijgen tot een resource. In this step, you can use any of the client libraries. Some source resources offer connectors that know how to use Managed identities for the connections. In that case, you use the identity as a feature of that source resource.

Use managed identity directly

Service code running on your Azure compute resource uses either the Microsoft Authentication Library (MSAL) or Azure.Identity SDK to retrieve a managed identity token from Entra ID backed by the managed identity. This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs. As long as the managed identity is authorized, the service code can access downstream dependencies that support Entra ID authentication.

For example, you can use an Azure Virtual Machine (VM) as Azure Compute. You can then create a user-assigned managed identity and assign it to the VM. The workload running on the VM interfaces with both Azure.Identity (or MSAL) and Azure Storage client SDKs to access a storage account. The user-assigned managed identity is authorized to access the storage account.

Use managed identity as a Federated Identity Credential (FIC) on an Entra ID app

Workload Identity Federation enables using a managed identity as a credential, just like certificate or password, on Entra ID Applications. Whenever an Entra ID app is required, this is the recommended way to be credential-free. There's a limit of 20 FICs when using managed identities as FIC on an Entra ID App.

A workload acting in the capacity of Entra ID application can be hosted on any Azure compute which has a managed identity. The workload uses the managed identity to acquire a token to be exchanged for an Entra ID Application token, via workload identity federation. This feature is also referred to as managed identity as FIC (Federated Identity Credentials). For more information, see configure an application to trust a managed identity.

Volgende stappen