Why securing MongoDB and OpenSearch behind Graylog comes first
A self-hosted Graylog concentrates sensitive data in two backends, and each one needs its own controls. MongoDB holds the configuration and metadata that Graylog depends on, including user accounts, roles, input and pipeline definitions, and the secrets Graylog uses to reach other systems. Graylog Data Node or self-managed OpenSearch holds the log storage itself, which is where application records, authentication events, IP addresses and any personal data that reached a log line will sit. Graylog's own login and role model protects the web interface and API, but it does not protect a database that anyone with network access can open directly. The backends therefore need authentication, network restrictions and certificate management of their own, applied independently of the Graylog application layer.
This page covers four controls for those backends: enabling authentication on MongoDB so that only the Graylog service account can read and write its database, restricting network paths so that only Graylog server nodes reach MongoDB and the Data Node or OpenSearch cluster, issuing and rotating certificates for the Data Node cluster, and handling support bundles, which can contain configuration values and secrets that must not leave the team unprotected. Before you start, confirm which search backend your version of Graylog supports, since the compatibility matrix and installation documentation both note that OpenSearch 1.x use is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Confirm the MongoDB and OpenSearch versions for your target release against the compatibility matrix, and record which team owns each backend, because these controls fail quietly when one team changes a firewall rule or a service account without telling the others.
How to enable MongoDB authentication for Graylog
Graylog keeps its configuration and metadata in MongoDB, including users, roles, streams, input definitions, dashboards and event definitions. An unauthenticated MongoDB instance lets anyone who can reach its port read those records, change them or drop them, and the records include the password hashes and secrets Graylog needs to run. Before any other control on this page matters, the database must require credentials. In the Graylog multi-node layout, MongoDB runs as a replica set across three nodes, so every member needs the same authentication settings, not only the one Graylog connects to first.
Start by creating a dedicated database user for Graylog in the database that Graylog uses, and grant it only the roles that its documented connection needs. Do not reuse the MongoDB administrator account for Graylog, and keep the administrator account for maintenance tasks. Then enable authorization on each replica set member and set up internal authentication between members with a keyfile or certificates, so that a host that reaches the replica set port without the key cannot join it. Enable authentication in a controlled window, because Graylog nodes must be updated with the matching connection string before they reconnect. Confirm the exact user roles, the connection string options such as the authentication source, and the keyfile or certificate settings against the Graylog installation documentation and the MongoDB manual for the versions you run, since those details change between releases and no version-specific figures are set out here.
Backend security options and when each fits
This table compares the main choices for the Graylog backends: which search engine to run, how Graylog authenticates to MongoDB, and how network access is restricted. Read each row for the option that fits your team's skills and change process, then check the operational effort column before you commit. The main takeaway is that the cheapest option to set up is rarely the cheapest to run for years.
| Decision | Option | Operational effort and when it fits |
|---|---|---|
| Search backend | Graylog Data Node | Graylog recommends Data Node as the search backend, and it is the path with the least custom security wiring. Fits teams that want Graylog to manage the search cluster's certificates and version pairing. Confirm current Data Node certificate handling in the Graylog docs. |
| Search backend | Self-managed OpenSearch | Your team owns TLS, the security plugin configuration, index state and upgrades. Fits organizations that already run OpenSearch under their own standards. Use only versions listed in the Graylog compatibility matrix, since OpenSearch 1.x is deprecated for Graylog 7.0 and later. |
| MongoDB login | Username and password | Simplest to configure, and every Graylog node must hold the credential in its server configuration. Effort is mainly in rotating the password and keeping it out of shared files and support bundles. |
| MongoDB login | Certificate-based authentication | Removes a shared password from configuration files but adds certificate issuance, renewal and distribution to each node. Confirm the supported MongoDB and Graylog combination in the compatibility matrix before you choose it. |
| Network isolation | Host firewall rules | Restricts ports 27017 and the OpenSearch or Data Node ports to Graylog node addresses. Effort is ongoing: every new node, load balancer or admin host needs a rule change and review. |
| Network isolation | Private subnets | Places MongoDB and the search cluster on a subnet with no route from user networks. Higher upfront network design work, but fewer rules to maintain and easier evidence for reviewers. Fits multi-node deployments with a dedicated data tier. |
| Support bundles | Restricted storage and access | Support bundles can contain configuration values, so treat them as secret-bearing files. Effort is a handling procedure: who may generate, where they are stored and when they are deleted. |
Which network paths to restrict so only Graylog reaches MongoDB and OpenSearch
Graylog depends on a handful of network paths between its server nodes, MongoDB, the Data Node cluster and the people and systems around them. Each path needs an explicit allow rule and a default deny, so that the configuration database and the log store accept connections from Graylog and nothing else. The multi-node layout in the Graylog documentation gives the reference shape to check your own firewall rules against.
Graylog nodes to MongoDB
Allow TCP to the MongoDB port only from the Graylog server nodes, and block it from everything else, including the other Data Node and load balancer hosts. The Graylog multi-node guide recommends three MongoDB nodes running as a replica set, so allow traffic between MongoDB members for replication and keep that rule separate from the Graylog rule. Check that Graylog nodes reach the primary and that no workstation or monitoring host can open a session directly. Confirm the exact port with your MongoDB configuration.
Graylog nodes to Data Node or OpenSearch
Allow the Graylog servers to reach the Data Node REST API and only those ports the Data Node cluster listens on. Block the same ports for any other host, because anyone who can reach the search API can read indexed logs without going through Graylog roles. Graylog recommends Data Node as the search backend, and this rule is where you confirm that OpenSearch 1.x is not still in use, since its use is deprecated. Verify the connection from each Graylog node, not just from one.
Data Node cluster traffic
Allow the three Data Nodes to talk to each other on their cluster and transport ports, and to nothing outside the cluster. Keep this network segment separate from user and client traffic so that a compromised workstation cannot reach the shard transport layer. Graylog documents three Data Nodes on their own cluster for medium to large deployments, so size the segment to hold all three with room for failover. Confirm the transport ports from your Data Node configuration before writing the rule.
Operator access to the backends
Administrators should reach MongoDB and Data Node through a bastion host or jump path with named accounts, session logging and multi-factor authentication, not from their desktops. Block direct operator access to the database ports and the Data Node API in the default rules, then open a time-limited path for maintenance windows. Record who opened each path so that backend changes appear in your change records alongside Graylog audit entries. Agree this model with your security team before the first production cutover.
Load balancer to Graylog
The load balancer should accept browser and log input traffic on the published ports and forward only to the Graylog nodes. Do not let the load balancer or its subnet reach MongoDB or the Data Node ports, because a balancer compromise would then become a backend compromise. Graylog recommends a load balancer in front of the nodes, and follower nodes must have is_leader set to false, so route only to nodes you intend to serve traffic. Check that health probes use an endpoint that does not expose data.
Monitoring agents and exporters
Monitoring tools often need to read metrics from MongoDB, Data Node and Graylog, which can widen the attack surface if left open. Allow each agent only to its specific metrics port from its own monitoring host, and deny all other access to those ports. Confirm whether each exporter needs credentials and whether it exposes configuration details. Review these rules whenever you add a monitoring tool, because they are easy to forget during audits.
Using Data Node managed certificates
Graylog recommends Data Node as the search backend, and Data Node can manage the TLS material that protects its own traffic. Before you rely on that, confirm exactly which connections the managed certificates cover in your Graylog version: the link from Graylog server nodes to Data Node, the traffic between Data Node peers in a cluster, or both. The trust boundary matters most. Graylog server nodes must accept the certificate chain that Data Node presents, so decide whether you will use the certificate authority that Data Node generates, a corporate authority you already operate, or a hybrid. Each choice changes what you must distribute to every Graylog node and every Data Node in the three-node cluster that the multi-node guide describes.
Certificate rotation is where managed certificates either save effort or cause an outage. Rotation touches every node that trusts the chain, so a renewal is a cluster-wide change, not a single-host task. Confirm whether rotation happens automatically, whether it needs a restart of Data Node or Graylog, and whether the old and new certificates can overlap during the change. Also confirm where the private key files live on disk, which system users can read them, and what file permissions the installer sets. Support bundles can carry configuration and environment details, so check that private keys and CA material are excluded from anything you send outside the team, and document that check as part of the procedure.
Before you enable managed certificates, inventory every hostname and address that Graylog and Data Node use to reach each other, because a name mismatch is the most common reason a TLS connection fails. Record the Graylog and Data Node versions and check them against the Graylog compatibility matrix. Take a configuration backup, then test the change on a non-production cluster that mirrors your node count. After the change, confirm that Graylog still searches and indexes, that each peer reports healthy, and that certificate expiry is tracked by a monitor with an alert date set well ahead of expiration. Put the rotation runbook in your change calendar before the first certificate expires.
How to set up a locked-down Graylog backend
This sequence takes the MongoDB and OpenSearch or Data Node backends from default-open to a state where only Graylog nodes can reach them, every connection is authenticated and encrypted, and each link has been checked before Graylog is pointed at it. Work it in order, because each step relies on the one before.
Inventory backends and connections
Before changing anything, list every MongoDB member, every Data Node or OpenSearch node, every Graylog server node, and every client or tool that talks to either backend, such as admin consoles, backup jobs and monitoring agents. Record the ports and direction of each flow. Confirm your Graylog version against the compatibility matrix, since the backend versions it supports depend on the Graylog release you run, and note whether you run Data Node or self-managed OpenSearch, because the TLS and authentication steps differ. Done means you have a written map of flows that you can compare against the firewall rules in a later step.
Enable MongoDB authentication on the replica set
Create an administrative user on the primary, then create a Graylog user with only the roles Graylog needs on its database. Enable access control in the MongoDB configuration with the keyfile or certificate-based internal authentication your MongoDB version supports, so replica members authenticate to each other. Restart members one at a time so the replica set keeps a primary. Check the result by confirming that an unauthenticated shell can no longer list databases, that the Graylog user can authenticate, and that rs.status() still shows one primary and healthy secondaries.
Configure TLS and authentication on Data Node or OpenSearch
Enable TLS for node-to-node and client traffic on the search backend, using certificates issued by your internal CA. For Data Node, follow the Graylog-documented certificate handling and let the managed certificate process generate and rotate node certificates where your setup supports it. For self-managed OpenSearch, use the Security plugin to enforce authentication and TLS, and create a dedicated Graylog service account with the minimum index and cluster permissions it needs. Confirm the result by connecting with the service account over HTTPS with certificate verification enabled, and by confirming that a plain HTTP or unauthenticated request is refused.
Restrict network paths to Graylog only
Apply firewall or security group rules so that MongoDB and the search backend accept connections only from the Graylog server nodes, plus any named administration hosts and backup or monitoring hosts you listed in step one. Deny everything else, including the web interfaces and admin ports on the backends. Keep the rules in version control or your infrastructure code so they are reviewed like any other change. Verify from an excluded host, such as a workstation or a Graylog input node that should not reach the database, that the MongoDB and search ports time out or are refused, and from a Graylog node that the same ports connect.
Point Graylog nodes at the secured endpoints
Update the Graylog server configuration on every node so the MongoDB connection string uses the authentication database, credentials and TLS options you set up, and so the Elasticsearch or OpenSearch hosts use HTTPS and the Graylog service account. Store the credentials in the secret mechanism your platform provides, not in plain configuration files shared with the team. Restart nodes one at a time, keeping the leader and follower roles described in your multi-node design. Confirm that each Graylog node starts, shows the cluster as healthy in the system overview, and can create and search an index without authentication errors in its logs.
Protect support bundles and secrets in exports
Support bundles and diagnostic exports can contain configuration and connection details, so treat them as sensitive. Decide who may generate them, where they are stored and how long they stay there, and restrict the storage location to the administrators who need it. Confirm that the MongoDB and search credentials you configured do not appear in plain text in the bundle you generate, and if they do, rotate the affected credentials and adjust how the bundle is produced. Record this decision in your runbook so the next person who needs a bundle follows the same path.
Verify each connection end to end
Run one test pass across the whole chain: a Graylog node authenticates to MongoDB, writes a message through an input, the message is indexed over TLS by the service account, and a search returns it from the web interface. Repeat the authentication test from an excluded host and confirm it fails. Record the commands, test results and the date you ran them as evidence for your change record. Schedule the same checks after certificate rotation, backend upgrades and firewall changes, since any of these can silently break a connection that was working.
Protecting support bundles that contain secrets
Support bundles are useful when Graylog misbehaves, but they can gather configuration and credentials from across the stack. The cards below cover who can create them, where they are kept, how long they live and what leaves your environment, so the diagnostic data does not become a second copy of your backend secrets.
Why bundles carry secrets
A support bundle collects configuration, logs and environment details that help a vendor or engineer diagnose a fault. Depending on version and setup, that material can include connection settings for MongoDB and the search backend, and anything else written to configuration or logs. Before you rely on any bundle, confirm with Graylog what each bundle contains in your version, and treat the whole file as sensitive.
Restrict who can generate bundles
Creating a bundle should be an administrative action, not something every operator can do from the web interface. Limit the role that can trigger collection to a small named group, and record who did so. Review that group during access reviews, because a single account that can generate and download bundles can pull backend connection details out of the cluster.
Restrict who can download bundles
Generation and download are separate risks. A bundle sitting on a node or in the interface can be copied by anyone who can reach that location. Confirm where each version stores generated bundles, who can read that path on the server, and whether the download link is available to accounts beyond the person who requested it.
Store bundles encrypted
Keep bundles on encrypted storage, and move them only through channels that protect them in transit. Use an encrypted volume or an encrypted archive with a passphrase held by the responsible team, not in the same ticket as the file. Ask your support provider how they store bundles they receive and whether they keep copies.
Limit retention
A bundle is a snapshot, and old snapshots remain useful to an attacker long after the issue is closed. Set a deletion step in the support process, so bundles are removed from Graylog nodes, shared drives and ticket attachments once the case closes. Record the retention rule in your runbook and check it during routine reviews.
Redact before sharing with a vendor
Before a bundle leaves your network, remove or replace connection strings, passwords, tokens and certificate private keys. Redaction should be done by a person who knows the file layout, and the result should be checked for leftover values. Ask your vendor which fields they need, so you share only what the diagnosis requires.
Questions buyers ask about securing Graylog backends
What drives the cost of securing MongoDB and OpenSearch behind Graylog?
The cost follows the size of the cluster and how much of the surrounding environment has to be understood before changes start. The main drivers are the number of Graylog server nodes, MongoDB nodes and Data Nodes, how the existing network is segmented, whether a certificate authority already issues certificates for internal services, and how much compliance evidence the work has to produce. Graylog's multi-node guide recommends three Graylog and MongoDB nodes as a replica set and three Data Nodes on their own cluster for medium to large deployments, so a cluster at that scale has more hosts to restrict and more certificates to manage than a single-node lab. Ask any provider for a fixed-scope quote that lists each node, each network path to be restricted, each certificate to be issued and each evidence artifact to be delivered. DeployOpen does not publish a price list; a quote follows from that written scope.
How long does it take to lock down Graylog's backends?
The duration depends on how many nodes are involved, how many firewall and network changes need approval, and whether certificates can be issued from an existing authority or need new infrastructure first. No duration is set in this section because no researched figure covers it. A practical way to plan is to split the work into phases: inventory of current traffic paths, MongoDB authentication and replica set changes, network restrictions, Data Node certificate rollout and protection of support bundles. Each phase has its own change window, and the slowest one is usually the network approval cycle rather than the configuration itself. Ask for a timeline tied to your change calendar and a list of the dependencies that could move it.
What does our internal team need to provide before the work starts?
Most of the delay in backend hardening comes from missing inputs, so gather these before scoping:
Can our own engineers secure Graylog's MongoDB and OpenSearch backends without a partner?
Yes, a capable platform team can do this internally, provided it has time, access to the Graylog and network configuration, and someone who owns certificate issuance. The work is mostly configuration and verification, not new software development. The areas where teams most often need outside help are the first-time design of network segmentation across a multi-node cluster, consistent certificate lifecycle management and producing evidence that an assessor will accept. A fixed-scope engagement lets you buy only the parts you lack, such as a design review or a verification pass, while your team carries out the changes. Before deciding, check whether your team has run MongoDB replica sets and Data Node clusters in production, since those are the operational skills the hardening depends on.
Why does the number of Graylog nodes change the security work?
Every additional node adds connections that must be allowed and every connection that must be restricted. In the recommended layout, Graylog server nodes, MongoDB replica set members and Data Nodes each need a defined set of allowed paths, and a load balancer sits in front of the Graylog nodes. Follower Graylog nodes are set with is_leader to false, so their configuration must be checked on every host, not only on one. A firewall rule that works for a single node may leave a replica set member reachable from the wrong subnet. Plan a network matrix that lists source, destination and port for each service before any rule is written.
What compliance evidence should we expect from backend hardening?
Expect configuration records, network rule exports, certificate inventories and proof that unauthorized access paths are closed. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Ask which framework your assessor uses, then request a list of the specific evidence items each control needs, including how support bundles are handled because they can contain secrets. Agree on how evidence will be stored and who keeps it current after handover.
Do support bundles really expose secrets, and who should control them?
Graylog support bundles can contain configuration and other material that should be treated as sensitive, so access to them needs the same control as access to the secrets themselves. Confirm with Graylog's documentation which files a bundle includes in your version, then decide who may generate, store and send one. Restrict storage to named administrators, remove copies after support cases close, and record each transfer. Include this process in the written scope so it is designed and tested, not left as a verbal instruction.
Limits to confirm in your environment
The controls on this page depend on version pairings, edition features, certificate workflows and network paths that differ between deployments. Confirm each item below before you write firewall rules or certificate requests, because a mismatch found later usually means rework across the cluster.
MongoDB and Graylog version pairing
Graylog 7.0 to 7.2 need MongoDB 7.x up to 8.2.x, according to the compatibility matrix. Confirm the exact MongoDB minor version against the Graylog release you plan to run, including the release you will upgrade to later. Authentication settings and replica set behavior are the parts most affected when the MongoDB version changes, so test the auth configuration on the target version before you enable it in production.
OpenSearch or Data Node version
Graylog supports OpenSearch from 1.1.x up to 3.7.x, and Graylog Security requires OpenSearch 2.0 or later. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and is scheduled for removal in Graylog 8.0. Confirm whether your search backend is Graylog Data Node or self-managed OpenSearch, because the TLS, certificate and security plugin steps differ between them.
Edition features you depend on
Certificate management, audit logging and some single sign-on options depend on whether you run Graylog Open or an Enterprise or Security license. Graylog Open supports Active Directory, LDAP and trusted header authentication, while Okta, generic OpenID Connect and SAML need Enterprise. Confirm with Graylog which of the controls in this section your license covers before you design around them.
Certificate authority integration
Data Node and MongoDB certificates must chain to a authority your nodes trust, and the renewal process must fit your PKI. Confirm whether your organization uses an internal CA, an external issuer or a managed service, how certificates are issued and rotated, and who approves each request. Also confirm that the chain can be distributed to every Graylog node and load balancer that connects to the backends.
Network path restrictions from your host
Cloud security groups, hypervisor firewalls and managed Kubernetes network policies may block or reroute the ports MongoDB and OpenSearch use between nodes. Confirm which network paths your platform allows, whether nodes can share a private subnet, and whether traffic between Graylog and the backends stays inside one zone or region. Restrictive defaults can hide failed replica set elections until a node restarts.
Secure handling of support bundles
Support bundles can include configuration files and other material that holds credentials, so their handling depends on your own support process. Confirm with your support provider how bundles are generated, what is redacted, where they are stored and who may download them. Then decide whether your incident process needs a separate, access-controlled location for these files before anyone requests one.
How DeployOpen scopes and delivers backend hardening for Graylog
DeployOpen plans, implements, hardens and documents the Graylog backends inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For this work, the backends are the MongoDB replica set that holds Graylog configuration and metadata and the Data Node or self-managed OpenSearch cluster that holds log data. The engagement covers MongoDB authentication, firewall and security group rules so that only Graylog server nodes reach MongoDB and the search cluster, certificate issuance and rotation for Data Node, and handling rules for support bundles that can contain secrets. Most engagements are fixed-scope, so the agreed deliverables, environment assumptions and acceptance checks are written down before any change is made to a production cluster.
A quote follows from that written scope, so the inputs that move the price are the ones you should settle first. They include the number of MongoDB and Data Node members, whether MongoDB is already a replica set, which OpenSearch or Data Node version you run, how many network segments and load balancers sit between Graylog and its backends, your certificate authority arrangement, and whether backup and restore tests are part of the agreement. Ask for the work to be split into one-time items, such as the initial lockdown and documentation, and recurring items, such as certificate renewal support and version updates. Confirm the supported version pairs for your Graylog release in the Graylog compatibility matrix before scoping, since they determine which hardening steps apply.
Ongoing support is available as a retainer for work that continues after handover, such as rotating certificates, reviewing firewall rules after topology changes, applying security patches to MongoDB and the search cluster, and re-checking that support bundles still avoid exposing credentials. Ask any provider to state in writing who performs each task, how access to the backends is granted and recorded during the engagement, and what documentation you receive at the end. DeployOpen does not issue audit reports or certifications for these controls. If you need evidence for an assessment, agree in advance on which artifacts the work will produce so your independent auditor can review them.
