Azure Migrate project keys generation issue due to keyvault soft delete not enabled, enforced by policy

Question

I have an issue when trying to generate project keys to my Azure Migrate Appliances, the problem is that the keyvault which it tries to create in the wizard to store the project keys does not seem to have soft delete enabled and this setting is enforced by policy so the deployment fails. I am wondering if it is a good idea to pre-stage a keyvault with the same name as the automated creation process tries to create but with soft delete enabled to be compliant with policy or if that keyvault will be ignored?

Or should I simply create a keyvault and somehow grant permissions on that for the azure migrate project+

Or is it better to try and override the soft delete policy enforced by the org?

Ultimately I would like to be able to choose to enable soft delete during the creation of the keyvault as part of the key generation process but don't know how to proceed?

Thanks

Answer 1

Hi Cristopher Klint,

Thanks for reaching out to Microsoft Q&A.

Pre-staging a Key Vault with the same name and enabling soft delete is a reasonable approach, and in most cases, Azure Migrate will recognize and use an existing Key Vault if it has the correct configuration, provided the vault meets the necessary permissions and settings required for Azure Migrate.

Here's what you can do:

Pre-stage the Key Vault with soft delete enabled:

• Create the Key Vault manually with the same name that Azure Migrate would attempt to create.
• Enable soft delete on the Key Vault during creation (since this is required by policy).
  • Ensure the appropriate permissions are granted to the Azure Migrate project or the service principal used by Azure Migrate.

1. Grant permissions to Azure Migrate:
   • Manually assign the required permissions (Key Vault Contributor) for the Azure Migrate project to the pre-staged Key Vault, so it can access the vault during key generation.
   Policy override considerations:
   • It’s not typically advisable to try overriding organizational policies, especially when it involves security settings like soft delete. Soft delete is a safeguard against accidental deletion and ensures recoverability, so overriding this may lead to issues later on.
     • Discuss with your policy administrators to explore exceptions only if it’s absolutely necessary and well-justified.
2. Alternative approach – Automation:
   • If pre-staging the Key Vault doesn't work or isn't feasible, another approach would be to create an automated process (through an ARM template or terraform) that deploys the Key Vault with soft delete enabled as part of the key generation process. This ensures compliance with your organization's policies without manual intervention.

would recommend trying the pre-staging approach first as it is straightforward and if done correctly, azure migrate should recognize and use the manually created Key Vault without further complications.

Please 'Upvote'(Thumbs-up) and 'Accept' as an answer if the reply was helpful. This will benefit other community members who face the same issue.