How to Secure OpenSearch Managed Database Clusters
Validated on 17 Jun 2024 • Last edited on 18 Dec 2024
OpenSearch is an open-source search and analytics suite which serves as a centralized location to manage logs forwarded from other resources, such as databases and Droplets.
Data in OpenSearch 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.
Use Encrypted Connections
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.