none
Deny public access to Azure PostgreSQL Service

    Question

  • Hello,

    We are currently trying out the Azure Database for PostgreSQL service but are somewhat confused about the networking setup. The virtual network services endpoint documentation (https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview) mentions that when a virtual network has service endpoints and that (in this specific case) a vnet rule for the PostgreSQL service is added, it would fully restrict public internet access. https://social.msdn.microsoft.com/Forums/en-US/36e59a3a-020e-48bf-bea8-2c8cae8c3ec9/restrict-public-access-to-azure-postgres-service?forum=AzureDatabaseforPostgreSQL is a similar question but mentions that when getting the `psql: FATAL:  no pg_hba.conf entry for host "xx.xxx.xx.xx.xx", user "userx", database "randomDB", SSL on` message that is just coming from a PostgreSQL service that manages the region. However, if I add the public IP when trying to access the service as a firewall rule, I can access the server. Doing a traceroute like the other thread mentioned did not give any noticeable information set up one way or another.

    Does adding a firewall rule open up the service to public access regardless of the vnet service endpoints being defined?

    Friday, January 18, 2019 4:40 PM

Answers

  • Hi Dustin,

    A VNet only adds private address space functionality, which is an additional layer of security only in the context of private address routing. There is a gateway service that sits outside your VNet that handles all PostgreSQL traffic for a given region, so yes, it listens for traffic (as mentioned by the referenced thread you included). 

    By adding firewall rule exception, you are bypassing the VNet and allowing public access to a private resource. If you keep it all private, then a VNet requires the client to be within the bounds of your defined LAN to access the PostgreSQL instance. Adding a whitelist of a specific public IP or public IP range will poke a hole in that VNet.

    I hope that helps.

    Regards,

    Mike

    Friday, January 25, 2019 12:03 AM
    Moderator

All replies

  • Virtual network rules are one firewall security feature that controls whether your Azure Database for PostgreSQL server accepts communications that are sent from particular subnets in virtual networks. This article explains why the virtual network rule feature is sometimes your best option for securely allowing communication to your Azure Database for PostgreSQL server.

    If your Microsoft.Sql server was a node on a subnet in your virtual network, all nodes within the virtual network could communicate with your Azure Database for PostgreSQL server. In this case, your VMs could communicate with Azure Database for PostgreSQL without needing any virtual network rules or IP rules.

    However as of August 2018, the Azure Database for PostgreSQL service is not yet among the services that can be assigned directly to a subnet.

    For more details, refer “Benefits of a virtual network rule” section.

    Server-level firewall rules apply to all databases on the same Azure Database for PostgreSQL server. If the IP address of the request is within one of the ranges specified in the server-level firewall rules, the connection is granted. If the IP address of the request is not within the ranges specified in any of the server-level firewall rules, the connection request fails. For example, if your application connects with JDBC driver for PostgreSQL, you may encounter this error attempting to connect when the firewall is blocking the connection.

    java.util.concurrent.ExecutionException: java.lang.RuntimeException: org.postgresql.util.PSQLException: FATAL: no pg_hba.conf entry for host "123.45.67.890", user "adminuser", database "postgresql", SSL

    There may be as much as a five-minute delay for changes to the Azure Database for PostgreSQL Server firewall configuration to take effect.

    For more details, refer “Azure Database for PostgreSQL Server firewall rules”.

    Hope this helps.

    Monday, January 21, 2019 6:30 AM
    Moderator
  • The proposed answer did not address the question I was asking.

    I understand how to set up rules to allow connections to the server. My question is in regards to disallowing public access.


    https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview

    The above link has the following:

    "Once service endpoints are enabled in your virtual network, you can secure Azure service resources to your virtual network by adding a virtual network rule to the resources. This provides improved security by fully removing public Internet access to resources, and allowing traffic only from your virtual network."

    However, when there is a virtual network rule for the server but I try to access it from the public internet I get the hba configuration error that has been mentioned:

    "psql: FATAL:  no pg_hba.conf entry for host "x.x.x.x", user "psqladminun", database "postgres", SSL on
    FATAL:  SSL connection is required. Please specify SSL options and retry."

    which is fine if that means that the request never even gets to the server, but normally it does. If it didn't, I would expect something more like the following error:

    "psql: could not connect to server: Connection refused
    Is the server running on host "myserver.postgres.database.azure.com" (x.x.x.x) and accepting
    TCP/IP connections on port 5432?"

    What makes me believe that public access is not actually disallowed like the link had mentioned is because I can add a public IP in a firewall rule for the server and am able to connect to it from the public internet. So my first question to figuring out if public access gets disallowed: Does adding a firewall rule open up the service to public access regardless of the vnet service endpoints being defined?

    Tuesday, January 22, 2019 3:21 PM
  • Hi Dustin,

    A VNet only adds private address space functionality, which is an additional layer of security only in the context of private address routing. There is a gateway service that sits outside your VNet that handles all PostgreSQL traffic for a given region, so yes, it listens for traffic (as mentioned by the referenced thread you included). 

    By adding firewall rule exception, you are bypassing the VNet and allowing public access to a private resource. If you keep it all private, then a VNet requires the client to be within the bounds of your defined LAN to access the PostgreSQL instance. Adding a whitelist of a specific public IP or public IP range will poke a hole in that VNet.

    I hope that helps.

    Regards,

    Mike

    Friday, January 25, 2019 12:03 AM
    Moderator
  • Virtual Network Service Endpoints creates a private path between your VNET and Azure Resource, in this case your PostgreSQL server. It creates a hidden route in your subnet routing, but other then that it changes no access to your VNET. The only change it will make to your PostgreSQL server is that it will allow traffic directly from the VNET, in additional to any rules that are on your PostgreSQL Firewall Rules. 

    Once you have enabled VNET Service Endpoints, you will still need to deny public access to your PostgreSQL using Firewall Rules. for more information, you can review This Document. When traffic can only flow from your VNET, you have a lot more control about what traffic is allowed .

    Friday, January 25, 2019 1:10 AM
  • I ended up getting help from a support request in Azure, but this is close to what was said as well.

    For anyone else confused by this, it is indeed the gateway that is returning the hba connection error. Disallowing public access simply means removing any ip configuration from firewall rules and is not seemingly related to the VNET service endpoints at all which is not at all how the documentation tells it:

    "Once service endpoints are enabled in your virtual network, you can secure Azure service resources to your virtual network by adding a virtual network rule to the resources. This provides improved security by fully removing public Internet access to resources, and allowing traffic only from your virtual network."

    This is not true because you can still add firewall rules to allow traffic from the public internet.

    Friday, January 25, 2019 3:00 PM