Tutorials Logic, IN info@tutorialslogic.com

MongoDB Security Authentication RBAC

MongoDB Security Authentication RBAC

MongoDB in MongoDB is best learned by connecting the rule to a product catalog or user activity store. Start with the smallest collection query, observe the output, and then add one realistic constraint so the concept becomes practical.

The key habit for this lesson is to watch document shape and index as it changes. That makes the topic easier to debug, easier to explain in interviews, and easier to use in real code without memorizing isolated syntax.

Why MongoDB Security Matters

By default, MongoDB does not enable authentication, which means any client that can connect to the server has full access. Securing your MongoDB deployment is critical before exposing it to any network. MongoDB provides a layered security model covering authentication, authorization, encryption, and auditing.

Enabling Authentication

Start mongod with the --auth flag to require all clients to authenticate. You should first create an admin user before enabling auth, otherwise you will be locked out.

Creating Admin User and Enabling Auth

Creating Admin User and Enabling Auth
// Step 1: Connect without auth (first time only)
mongosh

// Step 2: Switch to admin database
use admin

// Step 3: Create the root admin user
db.createUser({
  user: "adminUser",
  pwd: "StrongP@ssw0rd!",
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase"]
})

// Step 4: Exit and restart mongod with --auth
// mongod --auth --port 27017 --dbpath /data/db

// Step 5: Reconnect with credentials
mongosh --username adminUser --password StrongP@ssw0rd! --authenticationDatabase admin

Creating Database Users

Create dedicated users for each application with only the permissions they need. Never use the admin account for application connections.

Creating Application Database Users

Creating Application Database Users
use myapp

// Create a read-write user for the application
db.createUser({
  user: "appUser",
  pwd: "AppP@ss123!",
  roles: [{ role: "readWrite", db: "myapp" }]
})

// Create a read-only user for reporting
db.createUser({
  user: "reportUser",
  pwd: "ReportP@ss456!",
  roles: [{ role: "read", db: "myapp" }]
})

// List all users in the current database
db.getUsers()

// Update a user's password
db.changeUserPassword("appUser", "NewP@ss789!")

// Delete a user
db.dropUser("reportUser")

Role-Based Access Control (RBAC)

MongoDB uses RBAC to control what actions users can perform. Built-in roles cover most use cases:

Role Scope Permissions
read Database Read all non-system collections
readWrite Database Read and write all non-system collections
dbAdmin Database Schema, indexing, and statistics tasks
userAdmin Database Create and modify users and roles
dbOwner Database All admin, userAdmin, and readWrite combined
readAnyDatabase Global Read access to all databases
readWriteAnyDatabase Global Read/write access to all databases
userAdminAnyDatabase Global Manage users on all databases
clusterAdmin Global Full cluster management (sharding, replication)
root Global Superuser - all privileges

Custom Roles and Role Management

Custom Roles and Role Management
use myapp

// Create a custom role with specific collection access
db.createRole({
  role: "ordersReadOnly",
  privileges: [
    {
      resource: { db: "myapp", collection: "orders" },
      actions: ["find"]
    }
  ],
  roles: []
})

// Assign the custom role to a user
db.createUser({
  user: "ordersViewer",
  pwd: "ViewerP@ss!",
  roles: [{ role: "ordersReadOnly", db: "myapp" }]
})

// Grant additional role to existing user
db.grantRolesToUser("appUser", [{ role: "dbAdmin", db: "myapp" }])

// Revoke a role from a user
db.revokeRolesFromUser("appUser", [{ role: "dbAdmin", db: "myapp" }])

Network Security - IP Binding and TLS/SSL

Restrict which network interfaces MongoDB listens on using bindIp, and encrypt data in transit using TLS/SSL. Never expose MongoDB directly to the public internet.

mongod.conf - Network and TLS Configuration

mongod.conf - Network and TLS Configuration
// mongod.conf (YAML format)
net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5   // only listen on localhost and internal IP
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

security:
  authorization: enabled

// Connect with TLS from mongosh
mongosh --tls \
  --tlsCertificateKeyFile /etc/ssl/client.pem \
  --tlsCAFile /etc/ssl/ca.pem \
  --host myserver.example.com \
  --username appUser \
  --authenticationDatabase myapp

Security Best Practices

  • Always enable --auth in production.
  • Use bindIp to restrict network access to trusted IPs only.
  • Enable TLS/SSL to encrypt data in transit.
  • Use strong, unique passwords for all database users.
  • Apply the principle of least privilege - grant only necessary roles.
  • Enable MongoDB auditing to track access and changes.
  • Use MongoDB's Client-Side Field Level Encryption (CSFLE) for sensitive fields.
  • Regularly rotate credentials and review user access.
  • Keep MongoDB updated to the latest stable version.
  • Use a firewall to block port 27017 from public access.

Applied guide for MongoDB

Use MongoDB when the program needs a clear answer to a specific problem, not because the keyword looks familiar. In a real MongoDB task, first name the input, then name the transformation, then name the output. This small discipline shows whether the topic is being used correctly or only copied from an example.

A reliable practice flow is: create the smallest working collection query, add one normal case, add one edge case such as missing, repeated, empty, or boundary input, and then confirm the result with explain plan and sample documents. If the result surprises you, reduce the code until the behavior is visible again.

The most common trap here is copying the syntax before understanding the behavior. Avoid it by writing one sentence before the code that explains why MongoDB is the right choice. After the code runs, verify the lesson by doing this: change one input and explain the changed output.

  • Identify the exact problem solved by MongoDB.
  • Trace document shape and index before and after the main operation.
  • Keep one intentionally broken version and explain the fix.
  • Connect the example to a product catalog or user activity store so the idea feels concrete.
Key Takeaways
  • I can explain where MongoDB fits inside a product catalog or user activity store.
  • I can point to the exact document shape and index affected by this topic.
  • I tested a normal case and an edge case involving missing, repeated, empty, or boundary input.
  • I verified the result with explain plan and sample documents instead of assuming it worked.
  • I can describe the main mistake: copying the syntax before understanding the behavior.
Common Mistakes to Avoid
WRONG Copying the syntax before understanding the behavior.
RIGHT Write the expected behavior first, then make the example prove it.
A one-line expectation turns the code from copied syntax into a testable idea.
WRONG Practicing only the perfect input.
RIGHT Also test missing, repeated, empty, or boundary input before considering the lesson complete.
The edge case is where most interview follow-up questions begin.
WRONG Looking only at the final output.
RIGHT Trace document shape and index through each important step.
Tracing makes debugging faster because you can see the first incorrect state.

Practice Tasks

  • Build one small collection query that demonstrates MongoDB in a product catalog or user activity store.
  • Change the example to include missing, repeated, empty, or boundary input and record the difference.
  • Break the example by deliberately copying the syntax before understanding the behavior, then write the corrected version.
  • Explain the finished example in five bullet points: input, operation, output, failure case, and verification.

Frequently Asked Questions

Use it when the problem matches the behavior shown in the example and when the result can be verified through explain plan and sample documents.

Start with a tiny case, then test missing, repeated, empty, or boundary input. The main warning sign is copying the syntax before understanding the behavior.

Trace document shape and index, predict the result, run the example, and compare your prediction with the actual output.

Ready to Level Up Your Skills?

Explore 500+ free tutorials across 20+ languages and frameworks.