The Azure docs define managed identities as
An identity in Azure Active Directory (more specifically, a special type of service principal) that is automatically managed by Azure. You typically use managed identities when developing cloud applications to manage the credentials for authenticating to Azure services.
but still not sure what they are.
Managed identities for Azure resources is the new name for the service formerly known as Managed Service Identity (MSI).
Thank you @WillHuang!
A managed identity (MSI1) is a special kind of service principal that is assigned to an Azure resource that supports wielding managed identities to access other Azure services / resources without credentials.
Going to use the following terms (some arbitrarily chosen) here:
MSI resource: an Azure resource that support having (or endowed with) managed identities
target resource: an Azure resource that the MSI resource is trying to access
identity: Azure Active Directory identities); a quick overview:
security
principal
│
├─► user
│
├─► group
│ managed
└─► service ────► identity
principal (MSI)
(See also [this answer] (https://mcmap.net/q/226246/-what-is-the-difference-between-roles-and-scopes-in-azure-39-s-role-based-access-control-rbac).)
service principal:
A security identity used by applications or services to access specific Azure resources. You can think of it as a user identity (username and password or certificate) for an application.
(from Steps to assign an Azure role)
or
"An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organization is using Azure Active Directory"
In essence, by using a Service Principal, you avoid creating “fake users” (we would call them service account in on-premises Active Directory…) in Azure AD to manage authentication when you need to access Azure Resources.
(from Demystifying Service Principals – Managed Identities)
TL;DR
| user-assigned MSI | system-assigned MSI | |
|---|---|---|
| What if MSI resource is deleted? | unassigned and remains intact | deleted |
| How many can be assigned to an MSI resource? |
any number | only 1 |
| How many can be authorized on a target resource? |
any number | any number |
| Can it be authorized on multiple target resources at the same time? |
yes | yes |
(MSI resource =/= managed identity)
The relationship between MSI resources and managed identities is similar to boxes with labels or people having names & nicknames / aliases:
An MSI resource
can have ONE system-assigned managed identity
(such as a person is only allowed to have one legal name)
can be assigned MANY user-assigned managed identities
(such as a person can be known by different nicknames by their associates)
Not sure what the intention was with this design choice, but this allows one to create multiple identities for an MSI resource (or, put another way, an MSI resource can assume multiple identities), each of which could be authorized to perform different operations on target resources. (A target resource can also authorize multiple MSIs; see "Examples" section below.)
When an MSI resource is deleted,
the system-assigned MSI is deleted with it
the user-assigned managed identities will remain (these will only get unassigned)
Because access tokens are used instead. The general workflow summed up:
See "Example A (with commands)" section below for the specifics.
NOTE
In the examples below, the type of the target resources is an Azure Key Vault, that supports access control (IAM) and access policies to authorize MSIs; this is a tricky topic, but this Stackoverflow thread has a great explanation.
AZVM) with system-assigned MSI (AZVM-id).AZKV).AZVM.AZKV that AZVM (through its AZVM-id) is permitted to do (in Step 2.).For the specifics, see "Example A (with commands)" section below.
(e.g., REST API)
┌── ── ── ── ── ── ─── ─── ─── ─── ──┐
│ │
┌─AZVM─── │ ─┐ ┌─AZKV────────┐ │
│ │ │ │ │
│ │ │ │ │
▼ │ │ │ │
┌─ ── ───(service) │ │ + secrets │ │
│ │ │ + keys │
│ │ + key1 │
│ └────────────┘ ┌── ── ─► + key2 ── ───┘
│ identities= │
└── ─── ───►[ AZVM-id ]─── ───┘ │ │
│ │
└─────────────┘
AZVM-<n>) with system-assigned managed identities (AZVM-id-<n>).AZVM-user-id-<n>; docs: create & assign)AZKV-<n>). ┌─────────────────────────────┐
│ │
│ ┌──AZKV-1────────┐ │
┌──AZVM-1─────┐ │ │ │ │
│ │ │ │ │ │
│ │ │ │ + keys │ │
┌──── (service) ◄───────┘ │ + key-1 │ │
│ │ │ ┌──────► + key-2 ───────┘
│ │ │ │ │ │
│ │ │ │ │ │
│ └─────────────┘ │ │ + secrets │
│ identities= │ │ + secret-1 │
│ [ AZVM-id-1 │ ┌──── + password ◄─────┐
│ , AZVM-user-id-1 │ │ │ │ │
│ , AZVM-user-id-2 │ │ │ │ │
└──────► , AZVM-user-id-3 ───┘ │ └────────────────┘ │
] │ │
│ │
│ ┌──AZKV-2────────┐ │
│ │ │ │
┌─────AZVM-2─────┐ │ │ + secrets │ │
│ │ │ │ + secret-2 │ │
│ │ │ │ + password │ │
USER ────┐◄───────────────────────────┘ │ │ │
│ │ │ │ + keys │ │
│ │ │ ┌───────────── + key-3 ◄──────┐ │
│ │ ┌──(service) ◄────┘ │ + key-4 │ │ │
│ │ │ │ │ │ │ │
└──│─│───────────┘ └────────────────┘ │ │
│ │ identities= │ │
│ └──►[ AZVM-id-2 ───────────────────────────────┘ │
└────►, AZVM-user-id-3 ─────────────────────────────┘
]
Endow a virtual machine (the MSI resource) with system-assigned managed identity
When using the Portal, this can be done by going to the "Identity" menu item in a virtual machine's page on the Portal (see Demystifying Service Principals – Managed Identities or Configure managed identities for Azure resources on a VM using the Azure portal in the docs).
Grant access to the system-assigned managed identity on the key vault (the target resource).
When using the Portal, this can be done by clicking on "Access policies" menu item, and then on the "+ Create" button. The 1st page will ask to choose what privileges one wants to assign to the policy, the 2nd page will ask which identity to be used so choose the system-assigned MSI in Step 1. See more at Azure Key Vault security in the docs.
SSH into the VM in Step 1.
ssh -l <username> -i <private_key> 1.2.3.4
Request a token.
Using the Azure REST API via curl.
(The jq command is not necessary; it just makes the output easier to read.)
$ curl "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net" \
-H Metadata:true | jq
{
"access_token": "...",
"client_id": "12345678-9abc-def1-2345-6789abcdef12",
"expires_in": "84162",
"expires_on": "1680292962",
"ext_expires_in": "86399",
"not_before": "1680206262",
"resource": "https://vault.azure.net",
"token_type": "Bearer"
}
Use the token.
For example, to list the keys in the key vault (again, using the Azure REST API via curl):
$ curl https://my-project.vault.azure.net/keys?api-version=7.3 \
-H "Authorization: Bearer <ACCESS_TOKEN-FROM-STEP-4>" | jq
{
"value": [
{
"kid": "https://my-project.vault.azure.net/keys/keyname",
"attributes": {
"enabled": true,
"created": 1679939404,
"updated": 1679939404,
"recoveryLevel": "Recoverable+Purgeable",
"recoverableDays": 90,
"exportable": false
},
"tags": {}
}
],
"nextLink": null
}
To avoid copying access_token manually:
$ access_token=$(curl "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net" -H Metadata:true | jq '.access_token' -r)
$
$ curl https://my-project.vault.azure.net/keys?api-version=7.3 \
-H "Authorization: Bearer ${access_token}" | jq
[1]: From note in the docs: "Managed identities for Azure resources is the new name for the service formerly known as Managed Service Identity (MSI)." Decided to keep using this because every single Azure API implementation and 3rd party application that I used thus far referred to managed identity as MSI.
[2]: Loosely based on the one in Demystifying Service Principals – Managed Identities.
Figures were created with asciiflow.
Finding MSIs on the Portal
User-assigned MSIs have a their own sub-category "Managed Identities", but this won't show system-assigned ones. The latter need to be searched individually.
Resource groups and MSIs
This is only based on my experiences on the Portal, but it seems that system-assigned MSIs don't belong to a resource group (or they are hidden). That is, user-assigned ones show it clearly when called up, but couldn't find this info for system-assigned MSIs, and it doesn't make sense. The latter are tied tightly to the MSI resource so I went to the particular resource's resource group, listed all members, but they also don't show up there. Weird.
© 2022 - 2024 — McMap. All rights reserved.