rbac是通过“用户→角色→权限→资源”四级映射实现权限管控，核心是角色作为权限容器，权限由资源、操作、作用域三要素构成，支持动态绑定与最小权限实践。
RBAC（基于角色的访问控制）不是给用户直接配权限，而是通过“角色”这个中间层做映射。核心逻辑就一句话：用户拥有角色，角色拥有权限，权限定义了对哪些资源能执行什么操作。
角色是权限的容器
角色不是人，也不是岗位头衔，而是一组明确权限的集合。比如一个 devops-operator 角色，可以包含：
- 在
prod命名空间中对deployments执行get、list、patch - 对所有命名空间的
events执行watch - 但不包含
delete或exec权限
这样设计的好处是，权限变更只需改角色定义，所有绑定该角色的用户自动同步生效。
权限 = 资源 + 操作 + 作用域
一条权限规则必须同时说明三件事：
-
资源：比如
pods、secrets、ingresses.networking.k8s.io -
操作：如
create、update、get、log（注意：pods/log是子资源，需单独授权） - 作用域：是单个命名空间（Role + RoleBinding），还是整个集群（ClusterRole + ClusterRoleBinding）
例如，只允许查看日志却不允许进入容器，就必须显式授予 pods/log，而不是只给 pods。
用户与角色的绑定方式决定权限范围
绑定不是静态的，不同系统有不同实现机制：
- Kubernetes：用
RoleBinding（命名空间级）或ClusterRoleBinding（集群级），绑定对象可以是User、Group或ServiceAccount - MongoDB：创建用户时直接指定
{role: "read", db: "sales"}，支持跨库分配多个角色 - Docker UCP：通过 Grant 关联 Subject（用户/团队）、Role 和 Collection（资源分组）
关键点：同一个用户在不同上下文中可被赋予不同角色，比如开发人员在测试环境有 edit 权限，在生产环境只有 view 权限。
避免常见映射陷阱
权限映射失效往往不是配置错了，而是忽略了隐含约束：
- API 组写错：核心资源（Pods、Services）属于
""组，扩展资源（Ingress、NetworkPolicy）必须写对组名，如networking.k8s.io - 子资源遗漏：给了
pods权限，但没给pods/exec，用户仍无法kubectl exec - 冲突覆盖：Kubernetes 中，
ClusterRoleBinding和RoleBinding同时存在时，权限是叠加的，不是覆盖或取交集 - 最小权限未落实：一个 CI 流水线账户被绑定了
cluster-admin，就违背了最小权限原则
