Recover a soft-deleted key vault instead of failing the re-run - #26
Merged
Conversation
Deleting a key vault only soft-deletes it and its name stays reserved, so re-running a cluster provisioning script after deleting the resource group failed the key vault create with "A vault with the same name already exists in deleted state. You need to either recover or purge existing key vault." That is correct Azure behaviour, and these scripts advertise themselves as idempotent, so they now handle it: before creating, each script checks `az keyvault list-deleted` for its own vault name and recovers it, which restores the vault with its contents. Recovery is used rather than purge because purging throws the contents away; if recovery fails the script prints the exact purge command and exits non-zero rather than guessing. Verified against the emulator: delete the resource group, re-run the script, and the vault is recovered and the run continues to a working cluster, where it previously aborted at that step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR improves the idempotency of the AKS provisioning scripts by handling Azure Key Vault soft-delete: on re-runs, the scripts detect a soft-deleted vault with the target name and attempt to recover it before proceeding with the existing “show/skip-create” logic.
Changes:
- Added a pre-create check for soft-deleted Key Vaults via
az keyvault list-deleted. - Automatically runs
az keyvault recoverwhen the target vault name is found in deleted state. - On recovery failure, exits non-zero and prints a purge command for manual resolution.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| scripts/01-user-assigned-managed-identity.sh | Adds Key Vault soft-delete detection and recovery before the existing Key Vault create flow. |
| scripts/01-system-assigned-managed-identity.sh | Adds the same soft-delete detection and recovery logic for the system-assigned identity script. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
A soft-deleted vault stays in the region it was deleted in, and that region is part of how Azure addresses it (`/providers/Microsoft.KeyVault/locations/<region>/deletedVaults/<name>`), so recovering or purging it with a different one does not resolve. The two regions differ as soon as the `location` at the top of the script is changed between runs, which also made the fallback message print a purge command that could not work. Both scripts now read the vault's own location from `az keyvault list-deleted` and use it for the recovery and for the printed purge command. That value doubles as the presence check, so it is one query rather than two. Verified against the emulator with the regions deliberately mismatched: a vault deleted in WestEurope while the script is configured for ItalyNorth is now recovered into WestEurope and disappears from the deleted list. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Both cluster provisioning scripts describe themselves as idempotent and safe to re-run, but a re-run after
az group deletefails:Deleting a key vault only soft-deletes it, and the name stays reserved for the retention period. That is Azure behaviour, faithfully emulated by LocalStack, so the gap is in the script: it leaves the user to work out that they need
az keyvault recoveroraz keyvault purgefrom a docs link in an error message.Changes
Before creating the vault, each script now looks for its own vault name in
az keyvault list-deletedand recovers it. The existingaz keyvault showcheck then finds the recovered vault and skips creation, so the rest of the run is unchanged.Recovery rather than purge on purpose: recovering restores the vault with its contents, which is what a re-run of a provisioning script wants, while purging would silently destroy them. If recovery fails, the script prints the exact
az keyvault purgecommand and exits non-zero instead of guessing what the user wants.Testing
End to end against the LocalStack Azure emulator, on the sequence that used to fail: provision a cluster,
az aks delete,az group delete, then re-run the same script. It now reportsand carries on to a working cluster, where before it aborted at the key vault step.
az keyvault recoverwas also confirmed to work against the emulator on its own (create, delete, list-deleted, recover, show).