Infisical 如何重构 RBAC 权限系统
There is no 10x RBAC
我最近在 Infisical 中实现了一个看似简单却工程复杂的特性：基于文件夹的权限控制。RBAC 系统往往被视为基础设施，用户希望它无感且正确，但一旦出错可能导致严重的安全事故或服务中断。传统的基于角色的权限模型难以灵活应对特殊场景，例如需要额外权限或需剥离部分权限的工程师。我们没有迁移到 Zanzibar 风格的系统，而是在保留现有复杂架构的基础上，通过标准化五层权限等级和巧妙的缓存失效策略，成功实现了更直观的文件夹级访问控制。这证明了即使是枯燥的权限工程，也能通过精心设计让系统“恰好工作”。
访问控制是产品必须勾选的选项，而非杀手级功能，但这并不意味着它不重要。
- sandeepkd
从我观察到的情况来看，这个话题需要比目前得到的关注多得多，而现实是，在绝大多数地方，内部的访问规则都相当宽松。这正是集中化（使用 AuthZed 这类方案）和去中心化（在本地根据业务域跳过检查）之间形成良性张力的领域，需要懂业务领域的人来确保其高效运行。
- jzelinskie
我喜欢读这类文章，因为它表明授权系统已不再像过去那样小众。我也能理解在为本地部署的企业软件交付时避免依赖的心情；在创立 AuthZed/SpiceDB 之前，我们在为 Quay 的企业客户提供服务时，就曾过度依赖 Postgres。作为工程师，你的职责就是判断何时该采用专用系统，何时该继续投入自建方案。
我忍不住发现他们的设计与 Zanzibar/SpiceDB 中的概念有相似之处，这很棒！这也意味着，如果他们将来遇到现有系统不再可行的情况（比如工程师离职，或新的设计约束需要重新思考），他们可以轻松地迁移到专用解决方案。
不过，这篇文章中似乎没有提到一个权衡点：工具链的牺牲。专用解决方案拥有可用于调试和证明正确性的工具链，你可以将其集成到 CI/CD 中，而自研方案通常抽不出时间也为自己构建一套好用的工具链。
- bbkane
也许是因为我不是 RBAC 专家，但我很难理解文件夹的数据模型。它们是主体（subject）吗？然后是一个分层的 CASL，各层之间互相覆盖？而用户是执行者（actor）吗？