Private endpoint Connectivity | CosmosDB vCore

Question

From VM inside vnet/subnet as the DB, I'm able to use Mongo shell to connect to CosmosDB vCore. I'll assume since private endpoint is configured, traffic flows over that connection.

Strangely, the same applies when I access Azure portal, CosmosDB from outside the vnet/subnet. Should this be disallowed?

I would think that public access needs to be checked off.

Answer 1

@Gonzalez, Ernie

By default, communication across subnets in the same VNET is not restricted. Refer: Azure virtual network traffic routing | Microsoft Learn

 Customers can see MongoDB vCore and modify its configuration in Azure Portal (i.e., control plane access). But there is no way to see data within it from Azure Portal (this would data plane access). Private endpoints apply to data plane only. Control plane is publicly accessible unless this setting is enabled, which would be somewhat rare.

Answer 2

@Gonzalez, Ernie

For the above issue you mentioned regarding adding your colleague IP address to the Cosmos dB firewall.

If you add the IP address of your colleague’s machine (such as his home PC IP address) to the firewall, yes, that will then allow him to access.

But that would not be the desired way of doing it if private endpoints were enabled. That’s most likely not the right way to do it. Customers typically create private endpoint because they want their Cosmos DB for MongoDB vCore server to be inaccessible from public internet (in other words, only accessible from their own private network).

 As with any other Azure service, to gain access (i.e., be able to see data within the server) one needs to satisfy two conditions:

1. be in possession of the right credential – that is the key, AND
2. be on the right network segment – with public access, this condition is always satisfied; with private endpoint it means access from whichever VNET to which the private endpoint is pointing (or another VNET peered to such VNET)

 So, in order for you to share the server with a colleague you would need to provide the other developer with the key and the other developer would need to access from a machine that is located in the same VNET (or one peered to it) as from where the first developer is accessing.

Regards,

Oury

Answer 3

Thank you Oury for your response. That is the expected behavior.

The issue is interesting, I can still connect using MongoDB shell from a VM that is outside the VNET. If fact, I can connect using my laptop/portal.azure.com.

That is not what I expect if I'm using private endpoints, and public access is disabled.

One last thing, I saw this entry in the JSON view - publicNetworkAccess: Enabled. Any concerns?

Thank you

 "publicNetworkAccess": "Enabled",
        "previewFeatures": [
            "GeoReplicas"
        ],
        "replica": {
            "role": "Primary",
            "replicationState": "Active"
        },
        "infrastructureVersion": "2.0"
    },
    "apiVersion": "2023-03-01-preview"
}

Answer 4

Hi Oury,

I've accepted the answer. Thanks again.

For the case below where my colleague gets this error when attempting to connect, do I have to add his IP address to the CosmosDB firewall?