Using Managed identities for Azure with Service Fabric

  • Article

A common challenge when building cloud applications is how to securely manage the credentials in your code for authenticating to various services without saving them locally on a developer workstation or in source control. Managed identities for Azure solve this problem for all your resources in Microsoft Entra ID by providing them with automatically managed identities within Microsoft Entra ID. You can use a service's identity to authenticate to any service that supports Microsoft Entra authentication, including Key Vault, without any credentials stored in your code.

Managed identities for Azure resources are free with Microsoft Entra ID for Azure subscriptions. There's no extra cost.

Note

Managed identities for Azure is the new name for the service formerly known as Managed Service Identity (MSI).

Concepts

Managed identities for Azure are based upon several key concepts:

  • Client ID - a unique identifier generated by Microsoft Entra ID that is tied to an application and service principal during its initial provisioning (also see application ID.)

  • Principal ID - the object ID of the service principal object for your managed identity that is used to grant role-based access to an Azure resource.

  • Service Principal - an Microsoft Entra ID object, which represents the projection of an Microsoft Entra ID application in a given tenant (also see service principal.)

There are two types of managed identities:

  • A System-assigned managed identity is enabled directly on an Azure service instance. The lifecycle of a system-assigned identity is unique to the Azure service instance that it's enabled on.
  • A user-assigned managed identity is created as a standalone Azure resource. The identity can be assigned to one or more Azure service instances and is managed separately from the lifecycles of those instances.

To further understand the difference between managed identity types, see How do managed identities for Azure resources work?.

Supported scenarios for Service Fabric applications

Managed identities for Service Fabric are only supported in Azure-deployed Service Fabric clusters, and only for applications deployed as Azure resources. An application not deployed as an Azure resource can't be assigned an identity. Conceptually speaking, support for managed identities in an Azure Service Fabric cluster consists of two phases:

  1. Assign one or more managed identities to the application resource; an application may be assigned a single system-assigned identity, and/or up to 32 user-assigned identities, respectively.

  2. Within the application's definition, map one of the identities assigned to the application to any individual service comprising the application.

The system-assigned identity of an application is unique to that application; a user-assigned identity is a standalone resource, which may be assigned to multiple applications. Within an application, a single identity (whether system-assigned or user-assigned) can be assigned to multiple services of the application, but each individual service can only be assigned one identity. Lastly, a service must be assigned an identity explicitly to have access to this feature. In effect, the mapping of an application's identities to its constituent services allows for in-application isolation—a service may only use the identity mapped to it.

The following scenarios are supported for this feature:

  • Deploy a new application with one or more services and one or more assigned identities

  • Assign one or more managed identities to an existing (Azure-deployed) application in order to access Azure resources

The following scenarios are unsupported or not recommended. These actions may not be blocked, but can lead to outages in your applications:

  • Removing or changing the identities assigned to an application. If you need to make changes, submit separate deployments to first add a new identity assignment, and then to remove a previously assigned one. Removal of an identity from an existing application can have undesirable effects, including leaving your application in a non-upgradeable state. It's safe to delete the application altogether if the removal of an identity is necessary. Deleting the application deletes any system-assigned identity associated with the application and removes all associations with any user-assigned identities assigned to the application.

  • Service Fabric support for managed identities is not integrated at this time into the AzureServiceTokenProvider.

Next steps