How to move an Azure subscription containing a Cosmos DB using customer-managed encryption keys?

Question

I'm preparing to transfer an Azure subscription from one directory to another. This subscription contains a productive application which includes, among other resources, a Cosmos DB instance and a Key Vault. The Cosmos DB has at-rest encryption using customer-managed keys enabled, with said key being stored in the Key Vault.

The documentation for moving a subscription contains this warning twice:

If you are using encryption at rest for a resource, such as a storage account or SQL database, that has a dependency on a key vault that is being transferred, it can lead to an unrecoverable scenario. If you have this situation, you should take steps to use a different key vault or temporarily disable customer-managed keys to avoid this unrecoverable scenario.

This warning is extremely vague.

• What does it mean that it "can" lead to an unrecoverable scenario? In which cases does it, in which cases doesn't it?
• What's the nature of this "unrecoverable scenario"? The Cosmos DB and the Key Vault are part of the same resource group, so if I move the entire subscription, shouldn't both the DB and the Vault with the key be moved? I could understand if the reference to the key is lost and has to be reconfigured, but "unrecoverable" implies that the encryption key itself will be deleted during the transfer, making all data in the Cosmos DB inaccessible. Why would that happen?
• As a preventative measure, the warning says to "temporarily disable customer-managed keys" for the move. However, this doesn't seem to be possible. In the data encryption settings of Cosmos DB, the radio buttons are disabled, so it's not possible to go back to service-managed encryption keys. Which I think makes sense, because it would imply a decryption and re-encryption of the entire database.

This is making me feel very uneasy about the upcoming move, and gives me no indication what I need to do to prevent data loss. Has anyone ever encountered this scenario before and could give me some hints?

Answer 1

Hi @Daniel Saner,

I understand your concerns about the potential risks involved in transferring your Azure subscription, especially with the Cosmos DB and Key Vault setup you have.

What does it mean that it "can" lead to an unrecoverable scenario? In which cases does it, in which cases doesn't it?

Dependency on Key Vault: Your Cosmos DB needs the Key Vault for encryption keys. If the Key Vault becomes inaccessible during or after the transfer, the Cosmos DB can’t decrypt the data, leading to data loss or inaccessibility.

Unrecoverable Scenario: This can happen if the Key Vault isn’t properly transferred or if the access policies and permissions aren’t correctly set up in the new directory. This would make the Cosmos DB unable to access the encryption keys, making the data unrecoverable.

What's the nature of this "unrecoverable scenario"? The Cosmos DB and the Key Vault are part of the same resource group, so if I move the entire subscription, shouldn't both the DB and the Vault with the key be moved? I could understand if the reference to the key is lost and has to be reconfigured, but "unrecoverable" implies that the encryption key itself will be deleted during the transfer, making all data in the Cosmos DB inaccessible. Why would that happen?

• When you move a subscription, the Key Vault’s access policies and permissions might not automatically update to reflect the new directory’s identities and roles. This can lead to a situation where the Cosmos DB cannot access the keys.
• The Key Vault is tied to the tenant ID of the subscription. Moving the subscription to a new directory changes the tenant ID, which can disrupt the connection between the Cosmos DB and the Key Vault.

As a preventative measure, the warning says to "temporarily disable customer-managed keys" for the move. However, this doesn't seem to be possible. In the data encryption settings of Cosmos DB, the radio buttons are disabled, so it's not possible to go back to service-managed encryption keys. Which I think makes sense, because it would imply a decryption and re-encryption of the entire database.

• Before the move, ensure that you have a clear understanding of the access policies and permissions for the Key Vault. After the move, you will need to reconfigure these policies to align with the new directory’s identities.
• Ensure you have a backup of the encryption keys stored in the Key Vault. This can help in re-establishing the connection if something goes wrong during the transfer.
• If possible, test the transfer process in a non-production environment to identify any potential issues and understand the steps needed to resolve them.

Hope this helps. Do let us know if you have any further queries.

---

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.