Firewall Rules Now Control Public Database, Cache and Queue Access
The inbound rules of the firewall on a managed database, cache or queue now decide who can connect through its public hostname, so you can limit public access to addresses you trust.
What's changed
- An allow rule from specific addresses limits public connections to those addresses, while an allow from 0.0.0.0/0 keeps the endpoint open to everyone
- Write rules for the service's standard port, not the public port in your connection string: 5432 for PostgreSQL, 3306 for MySQL and MariaDB, 6379 for Redis, Valkey and Dragonfly, and 5672 for AMQP
- Other queue protocols each need an allow rule for their own standard port: 1883 for MQTT, 8883 for MQTT over TLS, 5671 for AMQP over TLS, 61613 for STOMP and 61614 for STOMP over TLS
- A deny rule wins over any allow, and a public endpoint that no allow rule covers rejects every connection
- Clients running on DanubeData should use the private hostname: on a restricted endpoint, their connections through the public hostname are refused
- Rule changes apply within about two minutes; open public connections are closed once when a rule changes, and allowed clients can reconnect straight away