Today, I will take you to interpret the role of the private endpoint service in Azure and how to use it. Private endpoint is an indispensable service in the design of Azure architecture and networking. We all know that Microsoft has many PaaS services. PaaS services are actually somewhat different from other clouds. Many PaaS services of other clouds can actually be deployed directly to the virtual network on the customer cloud, but part of Microsoft PaaS services can be deployed in the virtual network, such as HDInsight. Or SQL MI, but there are still some PaaS services that cannot be deployed in a virtual network, such as Storage, Azure SQL, etc.
Therefore, when designing some security architectures in the past, it was more troublesome to encounter this kind of PaaS product, because this generally requires service endpoints to limit traffic to only within a certain virtual network, but once you need to consider In the case of cross-accounts and cross-subscriptions, this solution basically cannot be done
The emergence of private endpoints has largely alleviated this problem, according to the official website
The Azure dedicated endpoint is a network interface that can connect you to services supported by Azure dedicated links in a dedicated and secure way. Private endpoints use private IP addresses in the virtual network to effectively introduce services into the virtual network. The service can be an Azure service such as Azure Storage, Azure Cosmos DB, SQL, etc., or it can be your own dedicated link service.
In other words, using private endpoints, you can access Azure PaaS services in a very private way, and all traffic will remain in the Azure data center, without worrying about being exposed to the Internet. Of course, it can satisfy the needs of large companies. Security compliance requirements, and this method does not need to consider whether it is in the same subscription or within the tenant, the next cross-tenant access scenario is demonstrated below:
First introduce the experimental environment
Two Azure accounts
Storage account belongs to account A region East US
The virtual network belongs to the account B region Korea Central
Now I want to create a private endpoint in account B to privately access the storage account of account A, which belongs to cross-region and cross-tenant at the same time, that is to say, the VM in the virtual network of account B can access the storage account of account A
First create a private endpoint in account B, first find the private link service, select private endpoint, and select add in private endpoint
Here you have to choose the region, this region refers to the region of the virtual network, not the storage account
Because the resource we want to connect to is not in the same directory, we need to connect using resource id
ResourceID can be found directly in the property of the storage account
After entering it, you need to provide subresource, because storage account will also be divided into blob, table, file and other resources, so the private endpoint needs to be accurate to which service to access, here directly enter the blob
Subresource that can be entered needs to be found here
Next, you need to select the virtual network you want to connect to. Note that because there is no way to integrate the private DNS Zone, you must manually configure the DNS records afterwards. Normal DNS records will be automatically configured by the private DNS Zone.
Just create
In essence, the private endpoint will create a network card in the virtual network that needs to be connected to the PaaS service. This network card will be assigned a private network IP. This IP is the IP we will use when we need to access the PaaS service in the future. It can be understood as The PaaS service we want to connect
Because it is cross-tenant, account B does not have permission to operate storage account, so there is no way to automatically approve, you need to manually approve this private endpoint request under account A
Next, we go to a virtual machine in the virtual network of PLTEST, and ping the URL of the storage account, you can see that it is still a public IP
This is because we could not integrate private DNS Zone before, so we can only modify the DNS configuration manually
Next, we try to use storage SAS to access the blob in the virtual network
Wget ‘https://deststoragemxy.blob.core.windows.net/test/bash.txt?sp=r&st=2020-10-29T05:20:48Z&se=2020-10-29T13:22:48Z&spr=https&sv=2019-12-12&sr=b&sig=Szev0Kz7W%2BUlTDnd%2BFabz%2Fs7rfNROH2pW7adisMmeoc%3D’ -O bash.txt
You can see that the connected address is already a private network address, and the Blob can be accessed smoothly