How to Secure PostgreSQL Managed Database Clusters
Validated on 8 Aug 2019 • Last edited on 18 Dec 2024
PostgreSQL is an open source, object-relational database built for extensibility, data integrity, and speed. Its concurrency support makes it fully ACID-compliant, and it supports dynamic loading and catalog-driven operations to let users customize its data types, functions, and more.
Data in PostgreSQL database clusters is encrypted at rest with LUKS (Linux Unified Key Setup) and in transit with SSL. However, there are additional steps you can take to ensure that your data is safe.
Restrict Incoming Connections
You can greatly decrease the likelihood of a security breach by restricting which DigitalOcean resources or external IP addresses are allowed to access the nodes in a cluster. This prevents brute force password and denial-of-service attacks from any server not explicitly permitted to connect.
Typically, only the application servers are allowed to connect to the database cluster. Users access the public-facing site, and the public-facing server authenticates and manages database connections in turn.
Add a Trusted Source Using the CLI
How to Add a Trusted Source Using the DigitalOcean CLI
The following example appends a firewall rule to a database cluster with the ID ca9f591d-f38h-5555-a0ef-1c02d1d1e35 that allows any resources with the example-tag to access the database:
To restrict access to a database cluster, click the name of the cluster in the control panel to go to its Overview page, then click the Settings tab.
In the section titled Trusted Sources, click Edit to open the Add trusted sources text box.
You can enter Droplets, Kubernetes clusters, tags, apps, or specific IP addresses. Entering a tag provides access to the database for any Droplets or Kubernetes nodes containing that tag. At this time, DigitalOcean Cloud Firewalls are not supported.
Warning
You currently cannot add IPv6 rules to a database cluster’s trusted sources.
Increase the SSL Mode Verification Level
By default, you must use SSL to transmit data because it prevents eavesdropping on administrative usernames and passwords as well as the data itself as it is transmitted. However, SSL doesn’t protect against man-in-the-middle (MITM) attacks or impersonation.
You can enable the verify-ca and verify-full SSL modes for PostgreSQL to check for these attacks. They’re disabled by default because they can affect performance.
To enable verify-ca or verify-full, update the value for sslmode in the --set flag when connecting. For example, to connect using the verify-full option, your connection string would look like this: