Managed Identities

Managed identities eliminate the need to manually manage secrets, credentials, certificates and keys.

Most secrets can be managed effectively with Key Vault - but there is still the problem of how we authenticate to Key Vault itself. Managed identities provide a way for applications to connect to resources that support Entra authentication (such as Key Vault) .

Applications can use a managed identity to obtain Entra tokens without having to managed any credentials.

Types

• System-assigned
  Enabled on an Azure service directly. Lifecycle of the managed credential is tied to the service itself. If the service is deleted then the credentials are cleaned up for you.
• User-assigned
  Is a standalone resource which can be assigned to one or more Azure services. Lifecycle is managed separately from the services that use the managed credential. Must be explicitly deleted.

Internally, managed identities are special service principals which are locked to only be used with Azure resources.

System assigned

Usecases

• Workloads contained within a single Azure resource.
• Workloads needing independent identities.
• For example, an application that runs on a single virtual machine.

How it works

1. Resource manager receives a request to enable a system-assigned identity for a VM
2. Resource manager creates a trusted service principal on the tenant
3. Resource manager updates the Instance Metadata Service identity endpoint with the client ID and certificate
4. You can now grant this identity access to Azure resources
5. Your app running on the VM is now able to request tokens from an endpoint which is accessible only from within the VM itself:
   http://169.254.169.254/metadata/identity/oauth2/token
6. You code sends this access token to Azure services which support Entra authentication

Configuration

You can configure an Azure VM with a managed identity during or after its creation. In order to configure a VM with a system-assigned managed identity, your account needs the Virtual Machine Contributer role assignment.

During creation

az vm create \
	--resource-group {resource-group} \
	--name {vm-name} \
	--image {image} \
	--assign-identity \      <-- important bit (note, no argument)
	--role {role} \
	--scope {subscription} \
	--admin-username {username} \
	--admin-password {password} 

After creation

az vm identity assign -g {resource-group} -n {vm-name}

User-assigned

Usecases

• Workloads that run on multiple resources and can share a single identity.
• Workloads needing preauthorization to a secure resource, as part of a provisioning flow.
• Workloads where resources are recycled frequently, but permissions should stay consistent.
• For example, a workload where multiple virtual machines need to access the same resource.

How it works

1. Resource manager receives a request to create a user-assigned managed identity
2. Resource manager creates a trusted service principal on the tenant
3. You can now grant this identity access to Azure resources
4. Resource manager receives a request to apply this managed identity to a VM
5. Resource manager updates the Instance Metadata Service identity endpoint with the client ID and certificate
6. Your app running on the VM is now able to request tokens from an endpoint which is accessible only from within the VM itself:
   http://169.254.169.254/metadata/identity/oauth2/token
7. You code sends this access token to Azure services which support Entra authentication

Configuration

Since a user-assigned identity is a standalone resource, you need to create it first.

az identity create -g {resource-group} -n {identity-name}

During creation

az vm create \
	--resource-group {resource-group} \
	--name {vm-name} \
	--image {image} \
	--assign-identity {identity-name} \      <-- important bit (note argument)
	--role {role} \
	--scope {subscription} \
	--admin-username {username} \
	--admin-password {password} 

After creation

az vm identity assign \
    -g {resource-group} \
    -n {vm-name} \
    --identities {identity-name}        <-- note argument