Skip to content

Matches page titles and page text. Forty pages, indexed at build time.

IP allowlists

Two allowlists with opposite defaults. One decides who may sign in to your organisation; the other decides which addresses may open a connection to a database.

Two allowlists, opposite defaults

There are two allowlists in Balta, and the difference between them is the one thing worth reading twice.

Your organisation's sign-in allowlist decides which addresses may sign in to the dashboard and use the API. An empty list there means no restriction.

A service's IP allowlist decides which addresses may open a connection to that database. An empty list there means no connections.

Each defaults to the safe answer for the thing it protects: defaulting sign-in closed would lock a new organisation out of its own account, and defaulting a database open would expose it.

The service allowlist

The list is on the service's Connect tab, for owners, administrators and developers on the project. Each rule is a CIDR range with a label, and a list holds at most 100 rules.

Where it is applied

Two places, and a rule is applied to both:

  • The host firewall. A packet from an address that is not on the list is dropped before PostgreSQL sees it, so it costs no connection slot and no TLS handshake. From the client's side this looks like a timeout rather than a refusal.
  • pg_hba.conf. PostgreSQL's own authentication file, which is authoritative for anything that reaches the postmaster and survives a firewall somebody has flushed. A connection refused here says no pg_hba.conf entry for host.

Only TLS connections are described in either. A connection without TLS matches nothing and is rejected.

An empty list accepts nothing

Not "everything". Nothing. An empty list is not the absence of a rule, it is a rule that matches no address — your own application included.

A new service is created with an explicit Allow all addresses rule so you can connect straight away. It is in the list, it has a label, and you replace it with your own ranges when you are ready. Nothing is hidden: if the list is open, the list says so.

What happens when you change it

A save is recorded immediately and reaches the host within a few seconds. Connections that are already open are not dropped. A pg_hba.conf change applies to new connections, and the firewall keeps established connections, so narrowing a list does not take down the application still connected from the range you removed. If you need to cut something off now, rotate the credential.

Removing your own address closes your own access to the database. It does not affect the dashboard, which is behind the other allowlist.

What it does not cover

The data browser and the SQL editor reach your database from inside Balta, not from your network, so an address you have not listed can still be used to open one. Who may is decided by roles and capabilities instead, and every statement is in your audit log. Turn the editor off for a service on its Configuration tab if that is not acceptable.

What to put on it

The egress addresses of your application, not your office. If your platform has no stable egress address, an allowlist is not the control you want, and TLS with strong credentials is doing the work.

Your organisation's sign-in allowlist works the other way round

Security → Organisation policy → IP allowlist is an allowlist over where your organisation may be signed in to from, and an empty one there means no restriction. Each entry is an IP address or a CIDR range, and the list holds at most 50. A bare address means that address alone. An entry with bits set to the right of its mask, such as 203.0.113.7/24, is refused rather than widened. Only owners and administrators can change the list, and saving asks for your password again.

Three more things are true of it:

  • A sign-in from an address the list excludes is refused, with the same answer a wrong password gets. Nobody outside the list learns whether a password was right.
  • A person who belongs to several organisations is signed in to one their address can reach. An organisation whose list excludes them stays unreachable, and the organisation switcher says so rather than moving them into it.
  • Saving a list that excludes the address you are using warns you first, and names the address. Nothing else can: the request that would undo the change is inside the organisation the change locks you out of.

The two defaults are opposite on purpose, and each defaults to the safe answer for the thing it protects: defaulting sign-in closed would lock a new organisation out of its own account, and defaulting a database open would expose it. Two allowlists with opposite empty-semantics in one product is worth stating plainly rather than leaving to be discovered.