Issue with Azure key vault and Azure storage account deployment

Question

I am trying to deploy a storage account, key vault along with private endpoints using terraform and azure devops, I have deployed this previously for dev environment in which all the resources were in same subscription along with agent so everything got deployed in one go, now i am trying to deploy for preprod environment here private dns zones are in different subscription but my service principal do have contributor access on private dns zones and subscription but still getting below mentioned error in key vault and storage account private dns zones deployment, resources key vault and storage account got deployed succesfully.

2024-02-23T15:42:56.2261892Z Error: retrieving contact for KeyVault: keyvault.BaseClient#GetCertificateContacts: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

2024-02-23T15:42:56.2282150Z Storage Account Name: "************"): accounts.Client#GetServiceProperties: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

Tried checking access for build agent as build agent is in different vnet and resources are getting deployed are in different vnet, Is vnet peering required if build agent , key vault/storage account are in different vnety?

Answer 1

The issue could be caused by the private endpoints. Since the agent might not be able to access the resources linked to the private endpoints from the networks.

To let the agent can access the resources under the private endpoints, you can:

1. Try to create a new VM on the same vNet with the private key vault and storage account, and then set up agent on the VM to run the deployment job in pipeline.

2. Try to create a new vNet under the same subscription of preprod environment and link the vNet to the private endpoints, then create a new VM with the vNet and set up the agent on the VM to run the deployment job in pipeline.

3. Try to link the existing vNet of the agent to the private endpoints.

4. If the vNets (subnets) are within the Same vNet, you might not need vNet peering. If the vNets are across different vNets, or different subscriptions, you generally need vNet peering.

For more details, you can reference the following documentations:

• Virtual network links
• DNS resolution in virtual networks
• Virtual network peering

---

Answer 2

To answer your final question; yes, if your agent doing the deployment is in another vNet, that vNet has to be peered to finish the deployment. (Or the agent needs to be able to connect to that network.)

You are probably running into the following scenario:

1. Terraform creates the resources
2. Terraform creates the Private Endpoints and they register in the DNS zones
3. All future requests to those resources fail/timeout because they are now getting a private DNS name for the resources and the agent can no longer communicate, even though it initially got a successful web response for the API call to create them.

A couple other points to note:

• The Private Endpoints do not need to be created in the same subscription as the resources. (They must be in the same region.)
• You can have multiple private endpoints for resources

If you didn't want to peer the vNets, you could deploy two private endpoints for each, one in your agent subscription/vNet and the second in the prod sub/vNet. You would need to specify dependencies though using depends_on to verify that the PEs in the agent vNet are created first.

Otherwise your only other option is to connect your agent to the target vNet somehow.