Flexible Server for MySQL 'Inaccessible' Due to Managed Identity not found

Hi XE2 Support,

You are facing an issue where your Azure Flexible Server (MySQL) has become inaccessible due to the removal of a user-assigned managed identity (UMI) that was used to access a Key Vault for encryption at rest. This has created a deadlock: the server can't access the key, so it's inaccessible, and because it's inaccessible, you can't assign a new identity.

Azure Database for MySQL Flexible Server supports encryption at rest using customer-managed keys (CMKs) stored in Azure Key Vault. When a UMI is used to access the Key Vault:

• The UMI must have permissions: get, wrapKey, unwrapKey, and list on the key.
• If the UMI is deleted or loses access, the server cannot decrypt the data encryption key (DEK), rendering it inaccessible

Once the server is in an inaccessible state:

• You cannot assign a new UMI.
• You cannot stop or restart the server.
• You cannot change encryption settings.

This is by design to protect data integrity and prevent unauthorized access.

Recreate the Original Managed Identity (if possible)

If the original UMI was recently deleted:

• Recreate it with the same name and resource group.
• Reassign the necessary Key Vault permissions.
• Azure may automatically rebind the identity and restore access if done quickly.

If you can recreate the original user-assigned managed identity (with the same name and permissions), Azure may be able to re-establish access and autoheal the server

unfortunately, you cannot get the access please do let us know.

Note:

• Always document and monitor managed identities used for encryption.
• Use Azure Policy to enforce identity and Key Vault configurations.
• Set up alerts for identity or Key Vault permission changes.

I hope this information helps. Please do let us know if you have any further queries.

Hi

Thanks for your response and for confirmation that this is by design.

This is a dev / test environment however the DB does have data in it which would take us time to recreate and therefore the optimum outcome is for the server to recover.

We have done the following - as per your suggestion

• Recreate it with the same name and resource group.
• Reassign the necessary Key Vault permissions.

However the issue is that the Azure control plane is stuck with the old identity and is not allowing any changes due to the server being inaccessible.

We are unable to change the UMID so unless the 'autoheal' situation you describe occurs our options appear limited. What is frustrating is that the key is still in the vault and the vault is intact. It is just access to this that is not currently possible due to the server being in a stuck state.

Any help would be appreciated.

Thanks

Hi XE2 Support,
I kindly request you to provide the details mentioned in the private message so we can identify the root cause and address the issue effectively.

Hi XE2 Support,

I kindly request you to share the details mentioned in the private message, along with the relevant error screenshots.