MongoDB自定义角色需先启用--auth，再在admin库用db.createRole()定义Privileges（资源+操作三元组），Resources须明确数据库与集合名，Actions大小写敏感且不可拼错。
如何在MongoDB中创建自定义角色并指定Privileges与Resources
直接给结论：MongoDB的RBAC不是靠“开开关”启用的，而是必须先启动--auth（或配置security.authorization: enabled），再通过db.createRole()显式定义角色——没这步，所有用户都只能用内置角色，无法精确控制Privileges与Resources。
Privileges本质是「对哪些Resources执行哪些Actions」的三元组，比如「对orders集合允许find和insert」；Resources必须明确指定数据库名、集合名（支持通配符但慎用），不能只写「所有集合」。
- 必须在
admin库中运行db.createRole()，否则报错not authorized on admin to execute command - Resources里写
{ db: "myapp", collection: "" }表示整个库，写{ db: "myapp", collection: "users" }才精准到集合 - Actions要查官方文档确认拼写，比如
remove不是delete，collMod需要admin库权限 - 避免用
{ db: "", collection: "" }（空字符串全匹配），它等价于超级权限，审计时一眼被揪出
db.createRole({
role: "appReader",
privileges: [{
resource: { db: "myapp", collection: "orders" },
actions: ["find"]
}, {
resource: { db: "myapp", collection: "logs" },
actions: ["insert"]
}],
roles: [] // 不继承其他角色
})
为什么给用户分配角色后还是提示Unauthorized
常见原因是Resources范围和实际操作不匹配——比如角色只授权了{ db: "myapp", collection: "orders" }，但应用连的是test库，或执行db.orders.find()却没切换到myapp库上下文。
- MongoDB的权限检查严格绑定当前
use的数据库，db.getSiblingDB("myapp").orders.find()不会触发myapp.orders的权限规则 - 如果角色定义在
admin库，但用户在myapp库认证（即db.auth({user:"u", db:"myapp"})），则该角色完全不生效 - 内置角色如
read只对当前认证库生效，想跨库得用readAnyDatabase（但这是高危权限） - 用
db.runCommand({connectionStatus: 1})查看当前会话实际拥有的角色和生效范围
如何让一个角色既能读A库又能写B库
不能靠单个Privilege条目覆盖多库，必须拆成多个resource+actions组合，且全部写进同一个createRole()调用里。
- 每个Privilege对象只能描述一个Resource，所以读A库、写B库至少要两个Privilege项
- Resources之间无隐式关联，
{ db: "a", collection: "" }和{ db: "b", collection: "c" }必须分开列 - 如果B库的写操作需要索引管理（如
createIndex），得额外加对应action，它不属于insert或update - 测试时用
mongo --username u --password p --authenticationDatabase admin myapp确保连接参数和认证库一致
db.createRole({
role: "crossDbApp",
privileges: [
{ resource: { db: "a", collection: "" }, actions: ["find"] },
{ resource: { db: "b", collection: "events" }, actions: ["insert", "createIndex"] }
],
roles: []
})
内置角色够用吗？什么时候必须自定义
够用的情况极少。内置角色如readWrite默认作用于认证库，但现代应用几乎都跨库协作——用户数据在auth库，业务数据在orders库，日志写进logs库。硬套readWriteAnyDatabase等于放弃最小权限原则。
-
dbAdmin允许dropDatabase，但日常运维不需要普通应用有删库能力 -
clusterAdmin能关节点、改配置，明显超出应用层需求 - 审计要求「谁在何时访问了哪个集合」，只有自定义角色才能把权限粒度卡死到collection级
- 注意：自定义角色本身不自动同步到副本集其他节点，需在primary上创建，并确保
system.roles集合已复制（默认开启）
最易忽略的一点：角色定义里的actions数组顺序无关，但大小写敏感；写成["Find"]或["find ", "insert"]（带空格）都会导致权限静默失效，错误日志里只报not authorized，不会提示action名错误。
