MongoDB security hardening (authorization, TLS, roles, audit)

Scenario-based runbook for hardening a running MongoDB (standalone, replica set or sharded cluster) without downtime: read-only security audit, rolling authorization with keyFile + transitionToAuth, least-privilege custom roles and users, SCRAM-SHA-256, bindIp and firewall, the allowTLS → preferTLS → requireTLS transition, x.509 membership authentication, audit log (Enterprise/Percona) and encryption at rest; at the end the audit is repeated to show the risks are closed. On systems built with this site's installation guides, authorization and the keyfile are already enabled: start with the audit and apply only the scenarios that report RISK. Day-to-day operations and backup are covered in separate MongoDB guides.

Topology: Standalone, replica set with 3+ members, or sharded cluster

Scenarios

• Security status audit (read-only) — Changes nothing. Unauthenticated access, listening addresses, TLS, authentication mechanisms, highly privileged users, audit and encryption at rest are reported as OK / WARN / RISK. Choose this if you do not know where to start.
• Full hardening (everything in order) — Audit → internal auth + authorization (no downtime with transitionToAuth) → least-privilege users → SCRAM-SHA-256 → bindIp/firewall → TLS (allowTLS → preferTLS → requireTLS) → audit (Enterprise/Percona) → final audit. Rolling in a replica set; every risky step asks for confirmation.
• Authorization disabled: enable authorization (keyFile, no downtime) — Anyone can connect without a user name and password. In a replica set and sharded cluster it is enabled rolling and without downtime with keyFile + transitionToAuth; a standalone server needs one short restart.
• Least-privilege users and custom roles (application, backup, monitoring) — Applications connect with root or a shared admin account. A custom role that grants the application only the operations it needs in its own database is created, along with separate users for backup and monitoring; secure password storage on the cron/application side is shown.
• Disable SCRAM-SHA-1, SCRAM-SHA-256 only — Credentials of older users are stored with SHA-1, or the audit found SCRAM-SHA-1 enabled. Users are migrated to SHA-256, then authenticationMechanisms is narrowed with a rolling restart.
• Restrict network access (bindIp 0.0.0.0, firewall) — mongod listens on all interfaces (0.0.0.0, bindIpAll) or the port is open to everyone. bindIp is reduced to localhost + the server's internal IP, and the firewall allows only the members and the application network. Rolling, no downtime.
• Encrypt connections: TLS (allowTLS → preferTLS → requireTLS) — Traffic between the application and the members, and between members, is unencrypted. Certificates are distributed, the members are first switched to allowTLS with a rolling restart, then to preferTLS at runtime, and to requireTLS once the applications are ready. Optional: x.509 authentication between members.
• Enable the audit log (Enterprise / Percona) — Who logged in and when, user/role changes and drop operations must be recorded. In MongoDB Enterprise and Percona Server for MongoDB it is enabled with auditLog; Community does not have this feature (an alternative is shown).
• Encryption at rest (encrypt data on disk) — If a disk or a backup is stolen, the data must be unreadable. On Enterprise/Percona, WiredTiger encryption is enabled by rebuilding the members one by one with an initial sync; on Community the data disk is encrypted with LUKS.

Before you start

• Root/sudo access on all mongod… and mongos… servers; SSH from the first server to the others (to copy the keyfile and certificates).
• …The replica set is healthy: all members PRIMARY/SECONDARY, low lag. No rolling operation is done on an unhealthy cluster.…mongod is running.…
• List of applications and their owners: each application's connection string will be updated before authorization/TLS become mandatory. The connection string must include all members and replicaSet= (so it does not drop during rolling restarts).
• Maintenance window: rolling operations cause no downtime, but each primary change makes writes wait a few seconds. On a standalone server enabling authorization/TLS needs a short outage.
• If authorization is already enabled in a sharded cluster: the primary of each shard must have a shard-local user (root) with the same name and password as … on mongos. Member-level steps (rs.stepDown in the rolling restart, setParameter, audit) connect directly to shard members; mongos users are not valid there. Check: on a shard member, mongosh --port <shard port> and db.getSiblingDB("admin").auth("…", passwordPrompt()).
• A current full backup whose restore has been tested.
• A MongoDB Enterprise license or Percona Server for MongoDB for audit and encryption at rest. Community does not have these features.
• Member names resolve on every server (DNS or /etc/hosts); with TLS, connections use these names.

Phases of the guide

• Preparation: safety net and helper tools — Configuration and state backup · Install PyYAML · Write the YAML editing tool (dbatlas-yaml) · Write the rolling restart tool (dbatlas-mongod-restart) · Write the admin password to a temporary file
• Status audit (read-only) — Network, process and file permissions: … · Network and process: … · Authorization, TLS and parameters: … · Authorization, TLS and parameters: … · Users, roles and authentication mechanisms · Map findings to scenarios
• Authorization: diagnosis and keyfile — Diagnosis: is authorization really disabled? · Inventory the application connections · Create the keyfile · Copy the keyfile to the other servers · Keyfile permissions: … · Keyfile permissions: …
• Authorization: admin user — Create the admin user (…) · Shard-local admin: …
• Least-privilege users and custom roles — Create a custom role for the application (…@…) · Create the application user (…) · Backup and monitoring users · Verify least privilege (…) · Store passwords securely on the application and cron side
• Authorization: verify that no unauthenticated connections remain — Unauthenticated client connections: …
• Enforce authorization (standalone) — authorization: enabled · Restart the service safely (…)
• Authorization: verification — Is unauthenticated access rejected? · Verify least privilege (…) · Rollback path (if needed)
• SCRAM-SHA-256: migrate users — Users with SHA-1 credentials · Reduce users to SCRAM-SHA-256 only
• SCRAM-SHA-256: verification — Is login with SHA-1 rejected?
• Network access: firewall — Firewall rules
• Network access: verification — Listening addresses: …
• TLS: certificates — Current TLS status · Generate the internal CA and server certificates · Distribute the certificates · Certificate permissions and verification: … · Certificate permissions: …
• TLS: move the applications — Move the applications to TLS and count TLS connections
• TLS: verification — Are non-TLS connections rejected: …
• Audit log: pre-check — Does this mongod support auditing: …
• Audit log: verification and rotation — Are audit records being written: … · Community alternative: monitor the authentication logs
• Encryption at rest: pre-check and backup — Encryption support and disk space: … · Has a full backup been taken?
• Encryption at rest: test marker — Write a plaintext marker
• Encryption at rest (Community): data disk with LUKS — Prepare the LUKS disk: … · Move the data to the encrypted disk: …
• Final audit (after hardening) — Network, process and file permissions: … (final state) · Network and process: … (final state) · Authorization, TLS and parameters: … (final state) · Authorization, TLS and parameters: … (final state) · Users, roles and authentication mechanisms (final state)
• Cleanup and next steps — Delete the temporary password file · Next steps: monitoring and periodic tasks