Using Managed identities for Azure with Service Fabric
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 Azure Active Directory (Azure AD) by providing them with automatically managed identities within Azure AD. You can use a service's identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials stored in your code.
Managed identities for Azure resources are free with Azure AD for Azure subscriptions. There's no extra cost.
Managed identities for Azure is the new name for the service formerly known as Managed Service Identity (MSI).
Managed identities for Azure are based upon several key concepts:
Client ID - a unique identifier generated by Azure AD that is tied to an application and service principal during its initial provisioning (also see Application (client) 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 Azure Active Directory object, which represents the projection of an Azure AD 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:
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.
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.
- Deploy a new Azure Service Fabric cluster with managed identity support
- Enable managed identity support in an existing Azure Service Fabric cluster
- Deploy an Azure Service Fabric application with a system-assigned managed identity
- Deploy an Azure Service Fabric application with a user-assigned managed identity
- Use the managed identity of a Service Fabric application from service code
- Grant an Azure Service Fabric application access to other Azure resources
- Declaring and using application secrets as KeyVaultReferences
Submit and view feedback for