Table of Contents
Understanding how to properly configure users and permissions is a crucial skill for anyone administering a MongoDB database. As application and data volumes grow, crafting thoughtful access control policies will have an enormous impact on data security, compliance, and operational overhead.
In this comprehensive guide, we will tackle this complex but critical topic together.
The Permissions Landscape
Before jumping into specifics in MongoDB, it helps to step back and examine the security terrain:
- 70% of breaches originate from application or database permissions misconfigurations according to research by Gartner
- Databases run an average of 170 overly privileged accounts per instance based on scans by Imperva
These statistics indicate that our user provisioning and access control hygiene often fails to meet security best practices. Excess permissions open the door to exploits and data theft.
So what principles should guide the security journey?
Navigating the Permission Schemas
MongoDB implements flexible role-based access control policies (RBAC) with both predefined and customizable roles. This model is widely used and maps well to real-world access needs like:
- Application front-end systems
- Batch processing jobs
- Analyst data queries
- Administrator console access
Each of these access paradigms likely requires different permission levels to data – ranging from read-only to modification rights on specific databases or collections.
Crafting this access matrix between users and resources is where we‘ll focus.
Creating MongoDB Users
The foundation of access control is establishing unique identities complete with credentials. MongoDB leans on the db.createUser() method for this user provisioning:
db.createUser(
{
user: "myappbackend",
pwd: "SecurePw1@",
roles: [...]
}
)Walking through the parameters:
- user – Unique username
- pwd – Strong password following corporate standards
- roles – Permission levels assigned to this Identity
Embedded within that simple createUser() call are some best practices like:
✅ No shared or generic logins – Unique access for all human and non-human entities
✅ Complex generated passwords – Over 12 characters with symbols, rotated twice annually
✅ Audit who has access – Map accounts in an access matrix to applications, jobs, etc
Following guidelines like these plus keeping usernames isolated provides good access hygiene.
Now we can explore the world of permissions through MongoDB roles. Roles become access groups that we layer onto these authenticated identities.
Understanding MongoDB Roles
Roles within MongoDB serve a simple purpose: they contain a bundle of privileges that we attach to users.
Some common examples are:
- dbOwner – Administrator access on a database
- read – Read-only lookup rights
- readWrite – CRUD operations for an app
- dbAdmin – Management of a database
- clusterAdmin – Superuser across entire cluster
We could grant readWrite to an application server to enable it to modify records. Or assign read to a reporting dashboard to limit it to queries.
These preset roles handle many simple cases but custom roles take flexibility further.
Creating Custom MongoDB Roles
We define bespoke roles in MongoDB using db.createRole():
db.createRole({
role: "internAccess",
privileges: [
{ resource: { db: "", collection: "" }, actions: ["find"] }
],
roles: []
})Now internAccess only permits find operations on all collections giving read-only organization-wide access – perfect for an inbound intern to explore datasets.
Between builtin and custom roles we craft the permission guardrails. We group these guardrails into roles and ultimately attach them to users.
This enables simple access modeling like:
Application Servers = readWrite
Public Dashboard = read
Administrator = dbAdmin
Assigning Roles to Lockdown Access
We marry identities gathered together with permission bundles using MongoDB‘s grantRolesToUser() built-in script:
db.runCommand({
grantRolesToUser: "reportsUser",
roles: [
{ role: "readWrite", db: "appdb" }
]
})Now the reportsUser identity gains the bundled readWrite permissions on the appdb database thanks to the joined role.
Mapping the intersection of users x roles provides the concrete access policy enforced at runtime.
From here best practices should always apply when binding roles like:
🔐 Use least privilege – don‘t assign clusterAdmin lightly!
🤏 Start with minimum access possible then monitor and adjust
These tips will steer initial role creation in safer direction. But constant vigilence is key…
Care, Feeding and Security of Permissions
User and permission lifecycle management is no small tasks for rapidly evolving applications.
Consider growth from 3 developers to 300 engineers across 20 microservices accessing 50 distributed databases.
Complexity explodes rapidly! Here are pro tips for managing scale while limiting blast radius:
🙅♀️ Avoid or limit admin/root logins
🔁 Assign access via groups not manually
💥 Have a plan to reduce permissions fast in an incident
📉 Analyze access patterns quarterly and prune
🚨 Detect anomalies like role escalations
These steps will pay dividends lowering risk even in high change environments by promoting Zero Trust security concepts.
Iteration and continuous adaptation of access is vital. Reflect frequently on key metrics like:
- Administrative sessions per month
- Privileged user logins weekly
- Permissions assignments monthly
- Audit errors triggered per day
What gets measured gets mastered – even MongoDB auth!
Evolving roles and entitlements over time can be daunting but with the above guides you will limit exposure.
Troubleshooting MongoDB Permissions
Despite most careful preparations, access issues crop up especially with new deployments and user onboarding.
Common scenarios include:
❌ Application failing with timeout or not authorized
❌ Analyst blocked from production data they need
❌ Developer requiring new database for testing
❌ Alert of role change or permission breach
Having an expedited process to diagnose and resolve is key.
Start with basics like:
🔎 Is the user present in the expected database?
🔎 Were credentials entered without typo?
🔎 Is network or app configuration correct?
Often surface causes sneak in on permissions issues.
For deeper troubleshooting:
👓 Inspect logs for failed access attempts
🔬 Use MongoDB console to check grants
📊 Analyze recent privilege changes
Getting to speedy diagnosis through runbooks, communication, and simplicity helps tame auth troubles.
Securing Your MongoDB Kingdom
In this extensive guide, we went step-by-step across all facets of access control within MongoDB – from constructing locked down users, crafting precise roles, assigning grants carefully, and troubleshooting issues.
Along the journey we explored critical best practices for security:
🔒 Enable auth to demand authentication
🙅♀️ Follow principle of least privilege always
🔁 Iterate permissions as applications and data evolve
📈 Monitor administrative access closely
Merging these practical patterns with MongoDB‘s granular control planes will help you achieve defense-in-depth for your mission critical data stores. Complex? Definitely. Worthwhile for your peace of mind? Absolutely!
I hope mapping out the terrain of access controls for MongoDB was useful. Reach out with any other questions!