Cloudera Docs

Resources created under the hood

Creating a Cloudera environment on Azure with private endpoints in Cloudera involves creating several Azure resources, all of which are necessary to have a private endpoint setup that works out-of-the-box.

These create a setup where:

  • A private endpoint to the Postgres server can be reached.

  • A network interface with only a private IP address exists in the subnet where the private endpoint has been added.

This ensures that communication between Cloudera and the Azure Postgres server happens via a private IP address. However, cluster services do need to contact the Postgres server via FQDN, so the address needs to be resolvable from the VNet.

Resources created when using a Cloudera-managed private DNS zone

In the scenario where Cloudera creates the private DNS, several resources are created:

  • A private DNS zone: It is a DNS zone, part of an Azure-hosted DNS server. It has a fixed name (“privatelink.postgres.database.azure.com”).

  • A virtual network link between the zone and a VNet where the domain resolution should happen.

  • An “A“ record within the zone: FQDN to IP address resolution. There is no reverse lookup.

  • Since communication can flow over a private IP address, Cloudera sets “Deny public access” on the Azure Postgres server.

When you delete the environment, the DNS zone and the network link that you provided will not be deleted.

Resources created when using your own private DNS zone

In this case the private DNS zone and the network link are provided by you and Cloudera creates the following:

  • Cloudera creates an “A“ record within the zone: FQDN to IP address resolution. There is no reverse lookup.

  • Since communication can flow over a private IP address, Cloudera sets “Deny public access” on the Azure Postgres server.

When you delete the environment, the DNS zone and the network link that you provided will not be deleted.