Last updated on July 8, 2022
Scenario:
Before: VM1 code, config, user cred/connection to SQL1
New: Azure keyvault for storing, but VM1 needs access to key vault, hm…better way? No keys?
Kan we have zero secrets in the code?
Azure Managed Identity
- System assigned management identity
- User assigned management identity
System assigned management identity (1 to 1)
- VM1(source)->Identity->System assigned->enable
- SQL1 (target)-> IAM->Add role assignment-> grant permission (i.e contributor)->Assign access to->VM1
- Each identity is tightly coupled to the Azure resource
This is a special type of service principal witch provide the following extra features:
- Automatic credential rotation,
- Better identity lifecycle management, when done with VM1 and rm it all associated identitys is also rm’ed.
- And we dont need to store any keys in the code autentication automatically.
User assigned management identity (many to 1)
- VM1,2, 3, 4, 5-> SQL1
- User assigned management identity are created independent of the source.
- Managed Identites->Add->MyUserIdentity
- VM1->Identity->User assigned->Add->MyUserIdentity
- SQL1->IAM-> add role assigment-> Contributor-> assign access to-> User assigned management identity->MyUserIdentity
| System assigned | User assigned |
| Create with Azure resource Automatic identity lifecycle management Cannot be shared with multiple resources | Create independently Manual identity lifecycle management Can be shared with multiple resources |
For and with Azure AD
Azure services that can use managed identities to access other services:
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-status
But with if onprem?
- on-prem, keyvault and Azure AD to secure keys, config and so on
Azure services that can use managed identities to access other services
Azure Managed Identities – explained in plain English in 5 mins with a step by step demo – YouTube
How to use managed identities for Azure resources on an Azure VM to acquire an access token
What is Bearer token and How it works?
A client application can request a managed identity app-only access token to access a given resource. The token is based on the managed identities for Azure resources service principal. As such, there’s no need for the client to obtain an access token under its own service principal. The token is suitable for use as a bearer token in service-to-service calls requiring client credentials.
Bearer tokens are a much simpler way of making API requests, since they don’t require cryptographic signing of each request. The tradeoff is that all API requests must be made over an HTTPS connection, since the request contains a plaintext token that could be used by anyone if it were intercepted.
What is Bearer Authentication?
Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer