Network access

The network settings are on the cluster's Configuration tab, section Networking & Security. Changing them needs postgrescluster/write; choose Save when done.

Choose who can connect from inside

Firewall decides which workloads on the Kubernetes cluster may open a connection to the database:

• Boundary Access — the default. Workloads in any resource group of the cluster's boundary.
• Same Resource Group Only — only workloads in the cluster's own resource group.
• Selected Networks — in addition to the boundary, every workload on the Kubernetes cluster, in any boundary, on the PostgreSQL port 5432.

Important

Selected Networks is the widest choice, not a narrower one: it lets workloads of every other boundary on the same Kubernetes cluster reach the database. The address list that comes with it applies to outside connections only.

Whatever you choose, the platform's own services keep their access — the Data Explorer and the operator among them. How these rules fit with the rest of the boundary's network is described in Databases.

Reaching the database is not the same as getting in: a connection still needs the credentials in the connection string.

Expose the cluster outside the Kubernetes cluster

Turn on Enable Ingress. The platform adds a load balancer in front of the primary, and the Overview then shows:

• External Access — Enabled;
• External IP — the load balancer's address, once it has one;
• External Connection String — the connection string with that address; see Connect to a cluster.

Until the address is assigned, both read External address is being provisioned…. Which addresses a load balancer gets, and from where they can be reached, depends on the installation.

Turning Enable Ingress off removes the load balancer.

Important

Traffic through the load balancer is admitted by a network rule that the platform's network sweep writes, and the sweep also applies the address list below. It runs every five minutes by default, so connections through a new load balancer can be refused, and a list you narrowed can keep admitting the old ranges, for up to that long.

Restrict outside access to address ranges

Without a list, anyone who can reach the load balancer's address can try to connect. To accept outside connections only from given ranges:

1. Set Firewall to Selected Networks — which also opens the database to every boundary on the Kubernetes cluster, see above. Allowed CIDR Blocks appears; it can be edited while Enable Ingress is on.
2. Enter the ranges, separated by commas, such as 203.0.113.0/24, 2001:db8::/32. Every entry needs a prefix length — write /32 (or /128) for a single address. Host bits are cleared for you, so 10.0.0.1/24 is stored as 10.0.0.0/24. A list with an entry that is not a range is refused as a whole.
3. Choose Save.

The list applies to connections from outside the Kubernetes cluster only; workloads inside it are governed by Firewall. It applies whatever Firewall is set to: switching Firewall back after saving the list hides the field in the portal but keeps the list in force. With the CLI or the API, allowedCidrs can be set without changing the firewall. The load balancer keeps the client's own address, so the list matches the addresses clients really connect from. The list is kept only while the load balancer exists: turning Enable Ingress off drops it.

TLS

TLS is not a setting: PostgreSQL refuses every connection without it, from inside or outside. The PgBouncer pooler is not set to require it — see TLS.

With the CLI

stsh pg update orders-db --set networkPolicy=allow-same-namespace
stsh pg update orders-db --set enableLoadBalancer=true --set allowedCidrs="203.0.113.0/24"
stsh pg external-ip orders-db

networkPolicy is default (Boundary Access), allow-same-namespace (Same Resource Group Only) or allow-all (Selected Networks). Through the API, the same fields go in a PATCH of the cluster; the external address alone is GET .../postgresclusters/<name>/external-ip, which needs only postgrescluster/read.