Private endpoint for PostgreSQL
By default, CDP uses service endpoints, but during environment registration you can optionally select the “Create Private Endpoint” option instead of using a service endpoint.
Azure Postgres service used in CDP can be reached via the following two methods, both of which are designed to allow you to restrict who connects to the Postgres service:
- Service endpoint (Created by default) - A service endpoint helps with the possibility of creating a firewall filter to allow connections only from the subnet explicitly linked to a given Postgres instance.
- Private endpoint (Created instead of a service endpoint only if explicitly enabled) - A private endpoint makes it possible to connect to a Postgres server instance over a private IP address from your VNet, ensuring that traffic stays within your VNet and hence increasing security. A service endpoint is not configured by Management Console if the private endpoint option is selected.
Prerequisites and limitations when using a private endpoint for PostgreSQL
The following limitations apply when you choose to use a private endpoint for PostgreSQL:
- Only subnets that have Azure private endpoint network policies turned off are eligible for private endpoint creation, because network security groups (NSG) are not supported for private endpoints. It is enough to provide one subnet where network security group policies are turned off. The private endpoint created in that subnet is expected to be used from the other subnets. For more information on disabling private endpoint network policies, refer to Disable network policies for private endpoints.
- A private endpoint can only be created if a single existing resource group is used.
- Only Azure hosted private DNS zones can be used - it is not possible to use custom third party DNS solutions.
- The private DNS zone must be in the single resource group, even if the network is
located elsewhere. This is because:
- The DNS zone must have a fixed name.
- A network cannot have links to two different DNS zones with the same name.
- It is not possible to check if a VNET already has a DNS zone with a given name attached to it.
- Only one resource group can have private endpoints with a given VNet. This is
- Only one DNS zone with a given name can be linked to a virtual network.
- That DNS zone has to be in the single resource group where all the resources are.
- Private DNS zone and virtual network links are shared within the single resource
- The first environment ever created in that resource group will create them.
- They will never be deleted by the Management Console.
- Private DNS zone creation cannot be turned off. There is no option to create a private endpoint without creating a private DNS zone.
Networking resources created under the hood
Enabling a private endpoint in the Management Console involves creation of several resources. All of these resources are necessary for the private endpoint setup that works out-of-the-box:
|A private endpoint through which the Postgres server can be reached.||This ensures that communication to the Postgres server occurs via a private IP address.|
|A network interface with a private IP address in the subnet where the private endpoint is added.|
|A private DNS zone, part of an Azure-hosted DNS server. As described in Azure docs it has a fixed name: privatelink.postgres.database.azure.com.||Since services need to contact the Postgres server via FQDN (for example because of SSL), the IP address needs to be resolvable from the VNet.|
|A virtual network link between the zone and a VNET where the resolution should work.|
|An “A“ record within the zone for FQDN to IP address resolution. There is no reverse lookup.|
|Deny public access is set on the Postgres server.||Since communication can flow over a private IP address, Deny public access is set on the Postgres server.|