📚 课程目录第3章 RBAC在Secrets管理中的作用

RBAC 在 Secrets 管理中的作用

权限控制这玩意儿，说白了就是「谁，能对什么东西，做什么事」。在 Secrets 管理里，这个「谁」可能是人，也可能是某个微服务，「什么东西」就是具体的凭证——数据库密码、、SSH 密钥。弄不好，后果很严重。我见过不少团队，最初只是把 Secrets 放一个共享文档，后来用上了 Vault 或类似的工具，但权限全是「管理员 vs 非管理员」——这其实跟共享文档区别不大。

传统权限模型的痛点

先聊聊为什么需要 RBAC。没它的时候，你可能会这么搞：

DAC（自主访问控制）：所有者说了算。张三创建了一个 Secret，他能决定给谁看。问题在于，张三离职了怎么办？或者他一时兴起给了前端的同学生产环境的数据库密码……别笑，我真遇到过。
ACL（访问控制列表）：每个资源挂一个长长的名单。比如「Secret-A」允许 user1、user2、service-b 读。初期人少还行，微服务一多，ACL 的维护成本直接爆炸。
全量共享：所有人都能读所有 Secret。这是最可怕的——一个前端的 CI job 居然可以读到支付证书的私钥。

这些做法共同的问题是：太细了难管，太粗了危险。RBAC 就是在中间找到了一个平衡点。

RBAC 的核心思路

RBAC 不直接把人跟资源绑在一起。它加了一层「角色」作为中介。结构是这样的：

用户 / 服务账号 ——> 角色 ——> 权限
          |               |
     身份属性         一组操作能力

你想想看，一个运维团队 20 个人，每个人都要读生产环境的数据库密码。如果用 ACL，你得给这 20 个人各自加一条记录。如果有新人加入，又得加一条。如果离职了，还得记得删。而用 RBAC，你只需要创建一个「数据库管理员」角色，赋予它读生产数据库 Secrets 的权限，然后把 20 个人扔进这个角色。新人加入只需要分配角色，离职了移除角色就行。少了很多琐事。

维度	ACL / DAC	RBAC
授权单位	逐个用户或服务	角色（一组用户）
变更成本	高：每个用户都要改	低：改角色即可
审计粒度	细，但查询复杂	按角色审计，清晰
适用规模	几十个以内	几百到几千个实体

RBAC 在 Secrets 管理中的三个核心作用

我个人习惯把 RBAC 在 Secrets 场景下的作用归结为三点：隔离、最小化、可审计。

隔离：开发环境的 Secrets 不会暴露给生产，生产环境的 Secrets 不会流入开发者的本地电脑。角色天然带着「环境」和「业务域」的标签。
最小化权限：一个只负责日志采集的服务，不应该有读写数据库密码的权限。给它一个「只读日志 Secrets」的角色就够了。
可审计：所有操作都跟角色挂钩。一旦出现泄露，你能很快定位出到底是哪个角色、哪个用户或服务在什么时间执行了读取操作。

关键认知：RBAC 不是靠「禁止所有人」来保证安全，而是靠「只允许必要的人」来缩小攻击面。前者是黑名单思维，后者是白名单思维。在 Secrets 管理上，白名单是唯一可靠的策略。

一个具体的例子

假设我们有一个微服务架构，包含三个服务：订单服务、支付服务、日志服务。它们都需要访问不同的 Secrets。

# 角色定义（伪配置）
role "order-service-r" {
  policies = ["read", "list"]
  paths    = ["secret/data/order/*"]
}

role "payment-service-rw" {
  policies = ["read", "write", "list"]
  paths    = ["secret/data/payment/*"]
}

role "log-service-r" {
  policies = ["read"]
  paths    = ["secret/data/infra/log/*"]
}

# 服务绑定角色
service "order-svc" {
  roles = ["order-service-r"]
}
service "payment-svc" {
  roles = ["payment-service-rw"]
}
service "log-svc" {
  roles = ["log-service-r"]
}

这样的好处很明显。支付服务只知道支付相关的 Secret，订单服务只知道订单相关的。日志服务甚至没法看到其他两个路径的 Secret 存在与否。权限被严格限定在业务域内。我在项目中遇到过反面教材——有人图省事把所有服务都塞进一个「共享读写」角色，结果日志服务的一个漏洞把整个集群的凭证全暴露了。嗯，那一次排查花了两天，最后发现是角色定义太粗。

避免一个常见的坑：角色爆炸

RBAC 用多了也会遇到新问题。有的团队给每个服务都创建了四五个角色，结果角色数量比服务还多，管理起来反而头疼。我建议的做法是：

按职责域定义角色，而不是按服务名。比如「数据库只读」、「队列生产者」、「配置读写」。
一个服务可以关联多个角色。比如订单服务同时需要「订单 Secrets 只读」和「对外只读」。
定期清理没有被关联的孤儿角色。我曾经扫过一次，发现系统里有三十多个角色，只有不到一半在用。

一个小技巧：在角色命名上加命名空间前缀，比如 prod:readonly:db、dev:fullaccess:config。这样一眼就能看出角色生效的环境和范围，省得后来接手的人猜。

RBAC 与 Secrets 管理的关系框架

下面这张图，是我对两者关系的理解——它不是简单的包含关系，而是一个层层映射的架构。

警告：不要在角色策略里写通配路径覆盖所有环境。比如 secret/data/* 这种写法，等于把整个 Secrets 库的门都打开了。我曾经在一个客户那里看到这样的配置，原因是「方便开发调试」——最后他们花了一整周重构权限策略。

总结一下我个人的体会

RBAC 不是银弹，但它是 Secrets 管理里最成熟、最实用的权限模型。它让安全策略从「因为信任所以授权」变成了「因为职责所以授权」。这两个思路的差别，就是被动挨打和主动防御的差别。我在设计 Secrets 平台时，总是先问三个问题：有哪些角色、每个角色需要哪些路径、路径上允许什么操作。三个问题问清楚，剩下的就是配置和迭代了。

嗯，关于 RBAC 在 Secrets 管理中的作用，就说这么多。记住：角色是桥，不是墙。桥能让你精准地到达该去的地方，而墙只会让人想办法绕过去。