0

I was able to access a private link in a test from both the public side and internally in the vnet. However, I did see they resolve to different IPs. This seems reasonable in that the internal resolution actually will resolve to the actual endpoint and I'm presuming the external one will not.

The part I'm confused on is why the public endpoint is exposed at all. Is it mainly to make SSL/SNI third-party trust easier? If yes, this implies no one can access the resource from the public side which is what I'm hoping for. Can anyone help affirm or correct my understanding?

The below resource almost makes complete sense to me and is what led me to the above understanding. https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#2-how-dns-resolution-works-before-and-after-private-endpoints

The below image shows the public access configuration as off. The above statements appear to be my experience even with public access turned off. enter image description here

Joshua Enfield
  • 17,642
  • 10
  • 51
  • 98
  • Which resource type? Did you close public access on resource settings? Did you test actual public access or just DNS and/or ping? – jikuja Jun 06 '23 at 22:29
  • @jikuja This was for a storage account. I just tested a curl/wget call and got a response indicating I did not supply enough parameters from Azure. I noted a random non-existant endpoint did not resolve. This is with public access turned off. My intuition would suggest a conservative posture would not expose a public endpoint, but the main part I am expecting is affirmation that even though there is a public exposure, that with public access off while using private link it is still actually private; along with an affirmation why the public access is there at all. – Joshua Enfield Jun 07 '23 at 15:11

1 Answers1

0

Just because you enable Private Endpoints for a resource does not necessarily mean that you do not want to also expose it on its public endpoint. In most cases you will configure publicNetworkAccess: 'Disabled' which will prohibit any external access. But you might not want that for valid reasons. With the DNS names still resolving externally, you have this flexibility.

silent
  • 14,494
  • 4
  • 46
  • 86
  • I added a clarification. I am presuming you might have both in order to facilitate keeping private communication private, but still allowing external access? However, my experience gives me coherent curl responses even with public access turned off (but not from the underlying service - it's just a generic bad request error). This is in contrast to hitting a nonexistant sibling private link domain that does not even DNS resolve. I did not go as far as setting up a formal external auth client and testing that far, I presume the underlying service cannot be accessed. – Joshua Enfield Jun 07 '23 at 15:17
  • I was just surprised to see any kind of "exposure" with Public Access turned off. As it suggests the domain for the service is still publicly exposed. But it seems like it probably isn't capable of resolving to the actual service as it resolves to a different IP as indicated in the documentation I linked. I'm trying to understand why the domain is still publicly exposed when public access is off, it seemed that it might exposed as a convenience for SSL...but I wasn't sure. – Joshua Enfield Jun 07 '23 at 15:18