5 min Security Management Identity Azure

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 assignedUser 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

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-status

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

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-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

Scroll to Top