Database networking and access
Database networking and access
A database deployed from the Self-Managed PostgreSQL or MySQL/MariaDB Database template has no floating IP. The instance holds a private address on a project subnet, and two kinds of traffic reach it: application connections from inside the project, and administrative sessions from outside it. The two paths have different shapes.
Application access#
An application instance on the same private network connects to the database's private address and the engine's port. Nothing routes through the internet, and no NAT translation happens in between. The connection string carries the private address:
postgresql://[email protected]:5432/appdb
mysql://[email protected]:3306/appdbThe templates create the starting database and role from the db_name, db_user, and db_password variables you set at apply time. Additional users and grants are engine-level work you do after the deployment.
Administrative access#
Administrators reach the same private address through a host that already has a route into the subnet: a bastion with a floating IP, a VPN endpoint, or another instance on the network. The SSH ProxyJump option carries both interactive sessions and file copies through that host:
ssh -i YOUR_PRIVATE_KEY_PATH -J ubuntu@JUMP_HOST ubuntu@DB_PRIVATE_IPSSH bastion access into a private subnet covers the bastion itself: the instance, its floating IP, its security group, and the client configuration that makes ProxyJump the default for the subnet.
Security group scope#
Both templates create a security group that allows the database port from the CIDRs you pass in allowed_cidrs, and nothing else. The variable has no default, so the access decision is explicit at apply time.
| Engine | Default port | Template variable |
|---|---|---|
| PostgreSQL | 5432 | allowed_cidrs |
| MySQL or MariaDB | 3306 | allowed_cidrs |
Scope the range to the narrowest set of sources the topology allows. An application tier on its own subnet gives you a /24 to allow instead of the whole private network. A single application instance gives you a /32. Security group rules are stateful, so an allow rule on the inbound port covers the response traffic; see Security groups for rule evaluation and How to create security group rules for the procedure.
Engine-side binding#
The security group is one of two gates. The engine has its own listener and authentication configuration, and both gates have to agree before a client connects:
- PostgreSQL listens on the addresses named in
listen_addressesand authenticates per the rules inpg_hba.conf. A client that clears the security group still fails if nopg_hba.confline matches its address, user, and database. - MySQL and MariaDB bind per
bind-address, and each account carries a host pattern. Aappuser@localhostgrant rejects a connection from the application subnet even when port3306is open to it.
The MySQL/MariaDB template binds the server to all interfaces and relies on the security group for network scope.
Exposing a database publicly#
Attaching a floating IP to a database instance puts the engine port on the public internet, where it faces continuous credential scanning. When an external client genuinely needs access, prefer a path that keeps the port private: a VPN into the project network, an SSH tunnel through the bastion, or an application-layer API in front of the database. If a public endpoint is unavoidable, restrict allowed_cidrs to the specific source addresses and require TLS at the engine.
Verifying a connection path#
Test the path in the order the packet travels: confirm the private address from the instance list, confirm the security group rule allows the source range, then open a client connection from the source host. How to connect to a database on a private network walks the sequence for both engines, including the psql and mysql commands that confirm a working session.
Further reading#
- Self-managed relational databases: the resources a database deployment composes
- Security groups: stateful rule sets on instance ports
- Networks: project networks, subnets, and routers
- SSH bastion access into a private subnet: the administrative path into a private database
- Site-to-site VPN: connecting an office or another cloud to the project network
Related content
Pages
How-tos
Overviews