Introduction
On a daily basis, I work with resources hosted in Microsoft Azure. From time to time, there is a need to move resources between different Azure subscriptions while staying within the same Entra ID tenant.
During one of these moves, I noticed an unexpected behavior related to permissions assigned to managed identities. I decided to write this article to highlight this issue, as it may cause problems if it is not taken into account during resource migrations.
The Problem
Many of the services I build or manage are based on an architecture that uses App Service and/or Azure Function Apps as executable components. These resources typically use system-assigned managed identities.
Managed identities are used to grant access to data resources and other services. For example:
- A managed identity is assigned a role on a Storage Account, such as Storage Blob Data Contributor
- A managed identity is granted permission to read secrets from Azure Key Vault using an access policy
When moving a resource to another subscription within the same tenant, I encountered an issue where not all permissions were transferred.
Continuing with the examples above:
- Role assignments on the Storage Account are not transferred
- Key Vault access policies are transferred correctly
This difference in behavior is quite surprising, especially considering that both permissions are assigned to the same managed identity and the tenant remains unchanged.
What Can Be Done
I was not able to find a way to automatically preserve or reapply the original managed identity role assignments on Storage Accounts during the move.
The solution I currently use is procedural rather than technical:
- I maintain a resource move checklist / instruction
- The instruction explicitly includes steps to manually reassign missing role assignments after the move
While this approach works, it is important to be aware of this limitation to avoid unexpected access issues after migrating resources between subscriptions.