Enable MongoDB authorization

The fix/etc/mongod.conf

security:
  authorization: enabled

sudo systemctl restart mongod

Do not do this yet. Read the safety section first — the order matters, and doing this on a running system breaks every client at once.

Why it matters

Every other database on this site ships with some authentication. MongoDB ships with none. A default mongod is not protected by a weak password; there is no password. Connect, and you are effectively an administrator: read every collection, drop every database, create users.

The only thing standing between a default MongoDB and the internet is bindIp, which has defaulted to loopback since 3.6. That default is the reason the situation improved after 2017 — but it is one line in one file, and a container image, a cloud template or a colleague debugging a connection can undo it in a second. When it goes, there is nothing behind it.

That combination — no authentication, and one setting away from public — is what produced the ransomware wave.

The localhost exception

MongoDB has a bootstrap mechanism that looks like a hole and isn’t:

When authorization is enabled and no users exist yet, MongoDB permits unauthenticated connections from localhost — but only to create the first user in the admin database. As soon as one user exists, the exception closes permanently and automatically.

This is what lets you enable auth and then create your admin account, rather than needing a credential that doesn’t exist yet. It’s a well-designed bootstrap, and it is not something to disable.

Two things to know about it:

• It is localhost only. It never applies over the network, so it is not a remote hole.
• It closes on the first user in admin, not the first user anywhere. Create your admin user first, then everything else.

Creating the first user

use admin
db.createUser({
  user: "admin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

Use passwordPrompt(), not a string literal. A password typed into mongosh as a literal lands in ~/.mongosh/mongosh_repl_history and in your shell history if you passed --eval. passwordPrompt() reads it interactively and keeps it out of both.

Note this first account is deliberately an admin account, not your application account — see least privilege roles for the accounts your apps should get.

Verify it worked

Confirm authorization is actually on, against the running server:

db.adminCommand({ getParameter: 1, authenticationMechanisms: 1 })
db.adminCommand({ getCmdLineOpts: 1 }).parsed.security

Expect { authorization: 'enabled' }.

Then prove it — the only test that counts. Connect with no credentials and try to read something:

mongosh --quiet --eval 'db.adminCommand({listDatabases: 1})'

Expect:

MongoServerError: command listDatabases requires authentication

If that returns a list of databases, authorization is off, regardless of what the config file says. That is the whole check.

Confirm your users exist and the localhost exception has closed:

use admin
db.getUsers()

Any user here means the exception is already closed.

Before you apply this

Enabling authorization instantly breaks every client, because right now none of them send credentials. There is no gradual path and no per-client rollout — it’s a single switch for the whole server.

The order that works:

1. Inventory who connects, while auth is still off:

   db.adminCommand({ currentOp: 1, $all: true }).inprog
     .filter(o => o.client).map(o => o.client)

   This shows only what’s connected right now. Check your connection strings too — a nightly job won’t appear.

2. Create the users first, with auth still disabled. Users can be created before authorization: enabled; they simply aren’t enforced yet. This means you can stage everything and test the credentials work before the switch.

3. Update every client’s connection string to send credentials. They will be ignored until step 4, so this is safe to deploy in advance.

4. Then enable authorization and restart. If you staged correctly, nothing notices.

Doing it in the reverse order — flip the switch, then scramble to create users via the localhost exception while production is down — is the version most people end up living through.

On a replica set, add keyfile or x.509 internal authentication at the same time. Enabling authorization without configuring internal auth between members breaks replication, because the members must authenticate to each other too. That is a much worse day than a client outage.

Keep a mongosh session open on the server while you work.

Related

• Bind to a private interface — the only thing protecting you before this.
• Grant least privilege roles — the accounts to create next.