Azure Dev Boxes and Azure Key Vault: Private Connectivity for Managed Identity Secret Access After Restart

Answer to the Core Questions

1. Does the system‑assigned managed identity keep Key Vault access over the private endpoint after an auto‑shutdown/start cycle without manual intervention?

Yes. The identity is tied to the Dev Box resource, not to the underlying VM. When the box is deallocated and later started, Azure re‑attaches the same identity to the new VM instance. Once the VM boots, the identity’s token endpoint (https://.privatelink.vaultcore.azure.net) is reachable via the existing private endpoint, so the identity can request a token and access the vault.

2. Is private DNS resolution for the vault guaranteed to persist across VM deallocation and reallocation?

Only if the DNS zone for privatelink.vaultcore.azure.net is linked to the VNet that hosts the Dev Box. Azure does not automatically create or link a private DNS zone when you provision a Dev Box. If the link is missing, the VM will fail to resolve the vault hostname after a restart, even though the private endpoint exists.

3. How does Key Vault firewall configuration interact with initial Dev Box provisioning when public access is denied?

If the vault’s firewall is set to “Deny all public network access”, the Dev Box must reach the vault exclusively via the private endpoint. Provisioning will fail or the VM will be unable to retrieve secrets if the vault’s subnet rule does not include the subnet that the Dev Box’s NIC belongs to. In practice, you either temporarily allow the Dev Box subnet during provisioning or ensure the private endpoint is created before the box is fully provisioned.

Practical Verification Steps

1. Confirm the identity is present before and after a restart:

   az devbox list \
     --query "[?name=='<devbox-name>'].identity.principalId"
   

2. Check that the private endpoint remains attached to the correct subnet:

   az network private-endpoint show \
     --name <pe-name> \
     --resource-group <rg> \
     --query "subnet.id"
   

3. Verify the DNS zone link exists:

   az network private-dns zone show \
     --name privatelink.vaultcore.azure.net \
     --query "virtualNetworkLinks[].virtualNetwork.id"
   

4. Test secret retrieval after a restart from inside the Dev Box:

   az keyvault secret show \
     --name <secret-name> \
     --vault-name <vault-name>
   

5. Inspect Key Vault firewall logs to confirm the request originates from the Dev Box subnet:

   az monitor metrics list \
     --resource <vault-id> \
     --metric "SuccessfulRequests" \
     --interval PT1M \
     --aggregation Total \
     --filter "clientSubnet eq '<devbox-subnet>'"
   

What to Check If Things Don’t Work

• The private DNS zone is linked to the Dev Box VNet.
• The vault’s firewall includes the Dev Box subnet.
• The Dev Box’s NIC still has the same network security group rules that allow outbound HTTPS to the private endpoint.

Ask yourself: Did you create a private DNS zone link for privatelink.vaultcore.azure.net to the Dev Box VNet? If not, link it and retry.

Assumptions & Uncertainties

• These findings assume the Dev Box SKU supports custom VNets and private endpoints in the region of deployment.
• Azure may change the behavior of private endpoint provisioning for Dev Boxes in future updates; always check the latest documentation or release notes.
• Firewall rules that block all public traffic can interfere with the initial provisioning of the Dev Box if the private endpoint is not yet created.