Managed Identities Explained

Managed Service Identity

In this blog, we will be introducing Managed Identities. We all developers have faced the issue with secure storage of credentials, secure access of credentials, deletion of credentials when the purpose is fulfilled, and rotating passwords for service accounts at some point in time. The answer to all problems is Managed Identities for Azure Resource.

Managed Identities for Azure Resources was previously called Managed Service Identity (MSI). Azure resources that support Azure Active Directory Authentication can use Managed Identities. APIs and any SaaS Platform that supports Azure AD can also use Managed Identities. Please check out this blog to learn about Azure AD Architecture.

Managed Identities and Service Accounts

Managed Identities are very similar to service accounts. We need to address the lifecycle (creation, storage, access and deletion) of service accounts; on the other hand, the lifecycle of Managed Identities is managed automatically for us. The lifecycle of the managed identities is tied to the Azure Resource itself (we will discuss the lifecycle later in this blog).

Some Important Points

• Credential-Free Authentication: MSI enables Azure resources such as VMs, App Services, and Functions to authenticate Azure services without having credential information within the application code, making it more secure and manageable.
• Seamless Integration with Azure Services: Some of them are the compatibility of MSI with Azure Key Vault, Storage, and SQL Database in such a way that it can access them using Azure AD tokens instead of secrets.
• Automatic Token Management: Azure will automatically handle the token issuance and renewal of its resources through MSI hence the handling of the tokens will not be an issue.
• Role-Based Access Control (RBAC): Administrative roles can be assigned to the managed identity through the Azure AD role-based access control to control the resources and actions the identity has to perform.

There are two types of Managed Identities:

• System-Assigned managed Identities
• User-Assigned Managed Identities.

System Assigned managed Identities.

System Assigned Managed Identities are the identities directly associated with the Azure Service Instance

Lifecycle

• It is created when you enable the Managed Identity option on the Resource.
• It is only associated with the one Azure Resource.
• Appropriate Azure RBAC permissions can be granted on other Azure resources to establish secure communication.
• It will be destroyed when Azure Resource is deleted.

Real-world Analogy

A System-Assigned MSI is like a temporary employee ID badge:

• Auto-Assigned: Similarly, when you begin temporary employment, you are awarded a badge on the spot.
• Exclusive Use: That badge is unique to you can only be awarded to you and cannot be used again in any other course..
• Auto-Removed: After the completion of the job the badge ceases to function and the employee is no longer a member of the group.
• Limited Scope: Compared to the traditional card system the badge only allows access to certain rooms that are related to your working position.
• No Hassle: There is no need to fret about the badge, everything about it is controlled on the backend.

User-Assigned Managed Identities

The user-assigned managed identity is a standalone resource deployed within Azure. Other Azure resources can also use it. Because of the shared nature, it provides more flexibility.

Lifecycle

• It is created when you create new Managed Identities via Azure Portal or CLI.
• It can be associated with any Azure Resources (one or more).
• Appropriate Azure RBAC permissions can be granted on other Azure resources to establish secure communication.
• It is destroyed when the Managed Identity Resource is deleted.

Real-world Analogy

A User-Assigned MSI is like a reusable keycard:

• Reusable Access: They are normally designed to be used once you have been through security and sometimes a single keycard can be used in different buildings or offices.
• Independent of Job: That is even if you change jobs or areas, the keycard still opens the door even if it is in another project.
• Manually Managed: Security locks the doors, and they dictate which ones are open to you, and they can change it at any time.
• Stays Active: Actually, the keycard does not deactivate after the completion of the project, rather it is yours to continue using.
• Flexible Use: You can carry it with you to whichever area of the locations you require necessitating its use.

Usage

There are three parties involved in accessing resources via Managed identities:

• Source
• Manage Identity
• Destination

The Source can access the destination with proper Authorization and Authentication via a Managed Service Identity. After creating/ enabling a managed identity, we assign the appropriate Azure RBAC permissions to access the destination.

Please reach out; if anyone wants some blogs on any specific topic of Azure, I would be happy to write them.

Please let me know if there are any issues with the blog. Comments and feedback are most welcome.

Follow me on Linkedin, Github, and Medium to keep yourself updated.

Thanks for reading. Happy Learning 😊