Deployment of queue, blob and ADLS2 private endpoints via Bicep goes wrong

Tim 156 Reputation points
2022-09-22T16:29:01.363+00:00

I am trying to deploy a number of three azure storage resources under two storage accounts, and I want to implement three private endpoints as to only allow connection to these resources from VMs in the same VNET. Type of resources that need to be connected to in two separate storage accounts are (per storage account):

storageAccountTemp

  1. Azure blob queue
  2. Azure blob storage

storageAccountDatalake

  1. ADLS 2 containers (datalake)

I have the following Azure Bicep code for deploying the permanent and temporary stores:

    param location string  
    param environmentType string  
    param storageAccountSku string  
    param privateEndpointsSubnetId string  
      
    var privateEndpointNameTmpstBlob = 'pe-tmpst-blob-${environmentType}-001'  
    var privateEndpointNameTmpstQueue = 'pe-tmpst-queue-{environmentType}-001'  
    var privateEndpointNamePst = 'pe-pst-${environmentType}-001'  
      
    /// Temp storage ///  
    resource storageAccountTemp 'Microsoft.Storage/storageAccounts@2021-08-01' = {  
      name: 'tmpst${environmentType}'  
      location: location  
      sku: {  
        name: storageAccountSku  
      }  
      kind: 'StorageV2'  
      properties: {  
        allowBlobPublicAccess: false  
        accessTier: 'Hot'  
        minimumTlsVersion: 'TLS1_0'  
        publicNetworkAccess: 'Disabled'  
      }  
    }  
      
    resource blobContainerForQueue 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-08-01' = {  
      name: '${storageAccountTemp.name}/default/claimcheck-storage-${environmentType}'  
      properties: {  
        publicAccess: 'None'  
      }  
    }  
      
    resource storageQueueMain 'Microsoft.Storage/storageAccounts/queueServices/queues@2019-06-01' = {  
      name: '${storageAccountTemp.name}/default/queue-main-${environmentType}'  
    }  
      
    /// Persistant storage datalake ///  
    resource storageAccountDatalake 'Microsoft.Storage/storageAccounts@2021-08-01' = {  
      name: 'pstdatalake${environmentType}'  
      location: location  
      sku: {  
        name: storageAccountSku  
      }  
      kind: 'StorageV2'  
      properties: {  
        allowBlobPublicAccess: false  
        accessTier: 'Hot'  
        minimumTlsVersion: 'TLS1_0'  
        isHnsEnabled: true  
        publicNetworkAccess: 'Disabled'  
      }  
    }  
      
    /// Data///  
    resource ContainerForData 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-08-01' = {  
      name: '${storageAccountDatalake.name}/default/data-${environmentType}'  
      properties: {  
        publicAccess: 'None'  
      }  
    }  
      
    /// Private endpoints configuration for tempblob, queue and datalake ///  
    resource privateEndpointTmpstBlob 'Microsoft.Network/privateEndpoints@2021-05-01' = if (environmentType == 'dev' || environmentType == 'prd') {  
      name: privateEndpointNameTmpstBlob  
      location: location  
      properties: {  
        subnet: {  
          id: privateEndpointsSubnetId  
        }  
        privateLinkServiceConnections: [  
          {  
            name: privateEndpointNameTmpstBlob  
            properties: {  
              privateLinkServiceId: storageAccountTemp.id  
              groupIds: ['blob']  
            }  
          }  
        ]  
      }  
    }  
      
    resource privateEndpointTmpstQueue 'Microsoft.Network/privateEndpoints@2021-05-01' = if (environmentType == 'dev' || environmentType == 'prd') {  
      name: privateEndpointNameTmpstQueue  
      location: location  
      properties: {  
        subnet: {  
          id: privateEndpointsSubnetId  
        }  
        privateLinkServiceConnections: [  
          {  
            name: privateEndpointNameTmpstQueue  
            properties: {  
              privateLinkServiceId: storageAccountTemp.id  
              groupIds: ['queue']  
            }  
          }  
        ]  
      }  
    }  
      
    resource privateEndpointPst 'Microsoft.Network/privateEndpoints@2021-05-01' = if (environmentType == 'dev' || environmentType == 'prd') {  
      name: privateEndpointNamePst  
      location: location  
      properties: {  
        subnet: {  
          id: privateEndpointsSubnetId  
        }  
        privateLinkServiceConnections: [  
          {  
            name: privateEndpointNamePst  
            properties: {  
              privateLinkServiceId: storageAccountDatalake.id  
              groupIds: ['blob']  
            }  
          }  
        ]  
      }  
    }  

As you can see, for the storage account, IsHnsEnabled is set to true, as to enable HierarchicalNamespace and thus ADLS2 functionality. The problem is, if I include the privateEndpointPst resource deployment in the Bicep deployment, and then try to view a datalake container in the portal from a VM that is in the same VNET as the private endpoint (which are in the subnet that makes the privateEndpointsSubnetId variable), I get a message saying I cannot make a connection to the endpoint.

I believe this should not be a problem though. The reason for this is that when I deploy all three endpoints together, they all show this same problem when trying to look at blob/queue/datalake in storageAccountTemp and storageAccountDatalake when I deploy all three endpoints.

However, only deploying the two endpoints for the storageAccountTemp resources and not the one for Datalake, I can see the data in the portal when running from the VM in the VNET and code running from this VM can also reach the queue + blob. So not only does the deployment of the privateEndpointPst seem to mess up datalake reachability, it also in some way does the same to the reachability of my other queue and blob in the storageAccountTemp if I deploy them altogether. My mind is boggled as to why this is happening, and why I cannot seem to deploy the datalake endpoint in the right way. Also, sometimes, deploying the endpoints altogether WILL make the datalake endpoint work, and break the other two, which is even more mind-boggling. Clicking do you want to do some checks to detect common connectivity issues gives me the following information, which does not make me much wiser as to what is causing the issue (since I'm pretty sure it's not firewalls; sometimes I can access, sometimes not):

244590-crazymessage.png

Does anyone see what could be wrong with my Bicep code for deploying the endpoint that might be causing this issue? I'm at quite a loss here. Also tried to replace groupIds: ['blob'] with groupIds: ['dfs'], but that does not seem to solve my problem.

Azure Data Lake Storage
Azure Data Lake Storage
An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.
1,313 questions
Azure Blob Storage
Azure Blob Storage
An Azure service that stores unstructured data in the cloud as blobs.
2,368 questions
Azure Private Link
Azure Private Link
An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.
447 questions
{count} votes

Accepted answer
  1. SaiKishor-MSFT 17,156 Reputation points
    2022-09-27T01:32:22.367+00:00

    @TimMolleman-2324 You would use the default names to connect to the private endpoint from the Vnet. Please refer to this doc more details- https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints#connecting-to-a-private-endpoint

    Clients on a VNet using the private endpoint should use the same connection string for the storage account as clients connecting to the public endpoint. We rely upon DNS resolution to automatically route the connections from the VNet to the storage account over a private link.

    Important: Use the same connection string to connect to the storage account using private endpoints as you'd use otherwise. Please don't connect to the storage account using its privatelink subdomain URL.

    By default, We create a private DNS zone attached to the VNet with the necessary updates for the private endpoints. However, if you're using your own DNS server, you may need to make additional changes to your DNS configuration. The section on DNS changes below describes the updates required for private endpoints.

    If connecting from a peer vnet, you may need to link the peer vnet to the private DNS zone that was created above so it can resolve the storage account in a similar way. Hope this helps.

    Please let us know if you have any more questions and we will be glad to assist you further. Thank you!

    Remember:

    Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is [how][1].

    Want a reminder to come back and check responses? Here is [how][2] to subscribe to a notification.

    0 comments No comments

0 additional answers

Sort by: Most helpful