MongoDB的授权模型围绕角色展开，每个角色包含一组针对特定资源（数据库或集合）的操作权限。系统内置了read、readWrite、dbAdmin、userAdmin等角色，覆盖了大多数通用场景，但这些角色通常以整个数据库为粒度，无法细化到集合级别或限制特定字段。当多个应用共享同一个MongoDB实例、或者需要让某个账号只能操作指定集合时，自定义角色就成为必要的权限控制手段。通过db.createRole命令，可以精确声明允许执行的操作和资源范围，实现最小权限原则，避免因过度授权带来的数据泄露风险。
一、理解MongoDB角色与权限模型
MongoDB的权限由两部分组成：资源（resource）和操作（action）。资源可以是整个集群、某个数据库或某个集合；操作则是find、insert、update、remove、createCollection等具体的数据库指令。角色是权限的集合，可以被授予用户。内置角色如readWrite在数据库级别授予所有非系统集合的读写权限，但无法限制到单个集合，如果只希望某个账号访问orders集合，内置角色就显得过于宽泛。自定义角色通过privileges数组逐条声明资源和允许的操作，可以精确到一个集合甚至一个字段。
自定义角色还支持继承其他角色，通过roles数组引用内置角色或另一个自定义角色。这种继承关系使得权限管理可以分层设计，基础角色负责通用权限，扩展角色负责额外权限，既减少重复配置又便于审计。需要注意MongoDB不允许在自定义角色中授予某些特权操作，如shutdown、serverStatus等涉及服务器管理的命令通常需要内置的hostManager或clusterManager角色才能执行。
资源定义中的db和collection字段决定了权限的作用范围。db必须是已存在的数据库名，collection可以是具体的集合名，也可以是空字符串表示该数据库下所有集合。这种细粒度控制非常适合微服务架构，每个服务只操作自己的集合，互不干扰。
二、使用db.createRole创建自定义角色
创建自定义角色使用db.createRole方法，基本语法如下。需要指定角色名称、角色所属数据库、权限数组以及可选的继承角色数组。角色名称在同一个数据库中必须唯一，但不同数据库可以有同名角色。通常在admin数据库中创建角色以便全局使用，也可以在业务数据库创建库级角色。
// 在inventory数据库中创建只读集合级别的角色
db.createRole({
role: "inventoryReader",
privileges: [
{
resource: { db: "inventory", collection: "products" },
actions: ["find"]
},
{
resource: { db: "inventory", collection: "categories" },
actions: ["find"]
}
],
roles: []
})
上面这个角色只能对inventory数据库中的products和categories集合执行find操作，不能写入，也不能访问其他集合。如果资源中的collection字段留空字符串，表示该数据库下所有集合。创建成功后，该角色信息会保存在admin数据库的system.roles集合中，并自动复制到副本集其他节点。
接下来展示一个带继承的角色示例，这种模式可以避免重复配置基础权限。
db.createRole({
role: "inventoryManager",
privileges: [
{
resource: { db: "inventory", collection: "products" },
actions: ["insert", "update", "remove"]
}
],
roles: [
{ role: "inventoryReader", db: "inventory" }
]
})
inventoryManager继承了inventoryReader的find权限，并额外获得products集合的写操作。这样设计可以让不同角色复用基础权限，后续如果调整读权限，所有继承者自动同步。继承的目标角色必须已经存在，且不能形成循环继承，否则创建会直接报错。
三、角色权限的作用域与继承细节
资源定义中的db和collection决定了权限作用范围。db必须为已存在的数据库名，collection可以是具体的集合名，也可以是空字符串表示整个数据库。还可以使用特殊资源anyResource来代表所有资源，但使用anyResource需要谨慎，因为权限过于庞大，等同于放弃了细粒度控制。自定义角色创建后，通过db.grantRolesToUser将其授予用户，用户即可获得角色中声明的所有操作权限。
角色继承遵循合并规则，子角色拥有父角色的所有权限加上自身privileges中的权限。如果不同角色之间存在权限冲突，MongoDB采用并集模式，即最终用户可以执行任何被任一角色允许的操作。比如一个角色只允许find，另一个角色允许update，用户同时拥有两个角色时就可以执行find和update。继承链上不允许出现环，否则创建会报错并拒绝写入。
需要注意自定义角色是针对特定数据库创建的，但授权给用户时可以跨数据库授予，前提是使用db.getSiblingDB来切换数据库。比如在admin库创建一个全局角色，然后grantRolesToUser时指定角色数据库为admin，用户可以在任何数据库使用该角色声明的权限。如果角色定义在业务库，用户也必须从该库获取，使用起来会稍显繁琐，因此推荐统一在admin库创建自定义角色。
四、更新、查看与删除自定义角色
角色的生命周期管理同样重要。创建后可能需要调整权限，比如增加新的集合访问权限或移除某个危险操作。MongoDB提供了db.updateRole、db.grantPrivilegesToRole、db.revokePrivilegesFromRole等命令来修改已有角色。查看角色详情可以使用db.getRole命令，输出角色的privileges和roles数组。删除角色使用db.dropRole，但删除前需要确认没有用户被授予该角色，否则会导致用户权限异常。
// 给inventoryReader角色增加对suppliers集合的find权限
db.grantPrivilegesToRole(
"inventoryReader",
[
{
resource: { db: "inventory", collection: "suppliers" },
actions: ["find"]
}
]
)
// 查看角色当前权限
db.getRole("inventoryReader", { showPrivileges: true })
grantPrivilegesToRole会在原有权限基础上追加，不会覆盖已有条目。如果需要移除权限，使用revokePrivilegesFromRole并传入相同的资源与操作描述。如果想整体替换角色的权限和继承关系，可以使用updateRole，它要求传入完整的privileges和roles数组，适合角色重构时使用。
实际使用中建议将角色定义脚本纳入版本控制，通过迁移脚本创建和更新角色，避免直接在production环境手工操作。MongoDB Atlas等托管服务也支持通过UI或API管理自定义角色，但底层命令完全一致。删除角色前先用db.getUsers检查关联用户，如果存在用户依赖该角色，可以先将用户的角色替换为其他角色再执行删除，防止出现无角色用户无法正常登录的情况。
五、自定义角色最佳实践与常见问题
最小权限原则是自定义角色设计的核心。为每个业务模块或微服务创建独立的角色，只授予完成工作所需的操作。比如订单服务只需要访问orders和inventory数据库的部分集合，不要授予整个数据库的readWrite。同时要定期审计角色权限，使用db.getRole查看权限列表，确认没有多余的授权。数据库管理员应养成先建角色再建用户、最后授权的工作习惯，避免直接给用户堆叠过多内置角色。
常见问题之一是误用anyResource资源，导致角色拥有整个集群的全部权限，与使用root角色无异。另一个常见问题是角色名称命名不规范，建议使用“服务名_动作”的格式，例如payment_read、inventory_write，一眼就能看出角色用途。还有一点需要注意，自定义角色创建后不会自动同步到副本集的其他节点，因为角色信息保存在admin.system.roles集合中，副本集节点会通过oplog自动复制，无需手动处理，但在分片集群中需要连接到mongos执行角色管理命令，否则可能只写入到某个分片上。
最后给出一个完整的最小权限用户创建流程，概括前面的知识。假设需要为报表系统创建一个只读账号，该账号只能读取sales数据库中orders和customers两个集合，不能接触其他数据。
// 1. 在admin库创建角色
db.getSiblingDB("admin").createRole({
role: "reportReader",
privileges: [
{ resource: { db: "sales", collection: "orders" }, actions: ["find"] },
{ resource: { db: "sales", collection: "customers" }, actions: ["find"] }
],
roles: []
})
// 2. 创建用户并授予角色
db.getSiblingDB("admin").createUser({
user: "reportUser",
pwd: "securePassword123",
roles: [
{ role: "reportReader", db: "admin" }
]
})
该用户只能读取sales数据库中orders和customers两个集合，无法写入或访问其他数据，满足报表系统的只读需求。在实际项目中，还可以把角色定义和用户创建拆分成多个脚本，方便在不同环境重复执行，同时配合审计日志检查是否存在越权访问。
MongoDB自定义角色createRole数据库权限修改时间：2026-09-26 23:25:56