TencentBlueKing / bk-iam-saas

BK-IAM is a centralized permission management service provided by The Tencent BlueKing; based on ABAC
Other
30 stars 40 forks source link

[Backend] ROLE授权范围同步到iam search engine方案 #89

Open zhu327 opened 3 years ago

zhu327 commented 3 years ago

同步方式

使用与policy相同的方式直接写到后台是最简单的方式, 不需要作为单独的逻辑处理, 需要统计下单前可能会增加多少策略数量

  1. 当前saas的策略变更方式 PolicyOperateBiz 的 aleter 方法其实是 create_or_update, 需要新增一个 aleter 支持完整的 create/update/delete方式
  2. 当前后台/engine对subject的type都没有做严格的校验, 可以直接使用type=role的形式处理分级管理员

问题

  1. 单前策略变更都是单系统维度的变更, 所以如果role的授权范围包含多个系统则需要多次调用后台alter接口, 需要评估下是否需要提供批量接口
zhu327 commented 3 years ago

在测试环境下:

总策略数量:

MySQL [bk_iam_app_dev]> select count(*) from bk_iam_dev.policy;
+----------+
| count(*) |
+----------+
|  1501174 |
+----------+

分级管理员授权范围策略数量:

1010705


策略数量过多, 影响iam后台的鉴权性能, 考虑从iam saas直接同步到iam engine

直接同步到Engine

  1. 分级管理员授权范围内的actions没有policy_id, 直接同步到engine可能会影响到engine doc的id的生产(出现id重复)
  2. 后续engine会作为一个被接入系统强依赖的服务, 直接导入大量数据影响engine的性能

思考: 是否需要再启动一个engine实例专门来做role授权范围的搜索

  1. saas的表达式与后端的表达式不一致, 需要有转换逻辑, 可以从iam后台代码中迁移过来
  2. 提供批量写入接口, 全量删除, 全量写入? 更新逻辑过于复杂
zhu327 commented 3 years ago

搜索的问题

  1. 当前的Engine搜索逻辑只针对单个资源单个操作, 如果有批量申请的需求, 会有如下问题
    • 需要批量请求每个操作-实例有权限的分级管理员
    • 分隔审批粒度在哪里, 是否是每个资源都需要不同的分级管理员审批?
    • 合并审批的逻辑该如何处理, 是否是每个操作一起审批?
  2. 一个操作-资源查询出了多个分级管理员, 是否这些分级管理员的所有成员都能审批?
  3. 除了授权范围, 分级管理员还包括人员的范围, 自定义申请的的人员必须要再人员的范围内, 需要额外的处理
  4. 如果对应的实例找不到对应的分级管理员, 该如何处理?

回复:

1.1 是的,需要匹配每个“操作-实例”对应的分级管理员

1.2 审批粒度是“实例”,每个实例都需要不同的分级管理员审批

1.3 申请多个实例存在分级管理员交叉的问题,需要按照分级管理员合并发起审批,即实例a由A、B审批,实例b由B、C审批,c由A、C审批,那么最终合并后:A 审批 a、c,B审批a、b,C审批b、c

  1. 是的,所有分级管理员都拉进来审批,只要其中一人过了就通过

  2. 分级管理员人员范围要去掉“普通用户侧的分级管理员人员范围限制”。--待讨论

  3. 分级管理员审批默认不包含“超级管理员和系统管理员”(除非审批节点明确了由系统管理员或者超级管理员审批),找不到对应的分级管理员,就由“系统管理员”审批。

wklken commented 3 years ago

搜索问题: 目前应该会存在批量实例的问题, 如果单条单条查询, 可能查询量非常大; 并且目前还存在实例审批人这个逻辑

所以, 方案处理前, 得考虑下批量的问题, 同一个操作不同实例, 多个操作等维度; 尽量降低申请单逻辑的复杂度; 考虑汇总资源信息, 批量查询实例审批人, 批量查询分级管理员;

申请单逻辑应该尽可能简单

zhu327 commented 3 years ago

背景

用户在权限中心申请自定义权限时可以选择一下几种角色作为审批人:

在使用超级管理员/系统管理员/leader作为审批人时都存在审批人责权不清的问题, 审批人需要管控的权限范围过大, 不符合细粒度权限管理的需求. 而实例审批人当前只有蓝盾系统实现, 从接入系统的角度来说也并不关注实例到底是谁来审批, 所以需要一种范围管控的角色来支持实例的细粒度审批, 这个角色必须权责清晰, 对所管理的资源有权限分配的权力与责任. 当前在权限中心分级管理员作为一种范围的管控角色, 正好符合这一需求.

本文档描述如何实现分级管理员审批实例权限.

需求

在权限中心个人用户申请自定义权限时, 自动查找到包含申请的操作-资源的授权范围的分级管理员, 使用分级管理员的成员作为审批人提申请单.

基于类似于操作-资源的查找有权限的subject的需求, 可以复用当前iam-search-engine的能力, 把分级管理员作为一种新的subject, 分级管理员的授权范围作为policy数据导入到iam-search-engine中, 所以以上需求可以拆分为2个:

  1. 在分级管理员创建/修改时同步分集管理员的授权范围到iam-search-engine
  2. 在用户申请个人的自定义权限时使用iam-search-engine搜索出有权限的分集管理员作为审批人创建审批单据

方案

1. 在分级管理员创建/修改时同步分集管理员的授权范围到iam-search-engine

参考当前普通的policy如何同步到iam-search-engine过程:

image

iam saas在授权时保存了SaaS侧的表达式后, 翻译为后端的表达式push到iam backend, iam-search-engine定时拉取iam backend接口获取到后端表达式翻译之后的鉴权表达式转换为ES Dock存储到引擎中.

方案1

要同步分级管理员的授权范围到iam-search-engine, 最简单的方式是把分级管理员的授权范围作为policy调用iam backendalert_policies接口存到iam backend的数据库中, 然后iam-search-engine走拉取逻辑.

但是查询测试环境的数据后发现, 测试环境有策略1501174条, 同步分级管理员的授权范围有1010705条, 评估后这些对于鉴权没有意义的数据会影响到iam backend的鉴权性能, 所以方案1放弃.

方案2

iam saas直接push分级管理员的授权范围到iam-search-engine不经过iam backend, 需要解决2个问题:

  1. iam saas当前只支持到iam backend的表达式转换, 还需要支持到iam-search-engine的表达式转换
  2. 分级管理员的授权范围没有policy_id导致不能直接同步到iam-search-engine的policy索引中

针对第一个问题, 经评估在当前的iam saas的表达是翻译逻辑的基础上只要少许修改就可以支持给到iam-search-engine的表达式.

第二个问题, 可以通过使用独立的policy索引来解决, 单独为分级管理员的搜索系统相关的接口, 走独立的索引, 同时启动内存数据到快照的定时任务, 定时打快照.

变更
  1. iam saas在创建修改分级管理员时调用iam-search-engine的策略修改/删除接口更新对应的数据, 实现表达式翻译的逻辑

  2. iam-search-engine需要为分级管理员提供一下接口

    POST /batch-search 批量search GET /stats POST /policy 批量policy创建 DELETE /policy/{subject_type}/{subject_id} 删除subject的所有policy

iam-search-engine

2. 在用户申请个人的自定义权限时使用iam-search-engine搜索出有权限的分集管理员作为审批人创建审批单据

常规的逻辑:

  1. 拆分自定义申请的策略数据为单一的操作-实例的策略
  2. 针对以上每一个操作-实例查询到iam-search-engine批量查询有权限的分级管理员ID
  3. 通过以上分级管理员ID查询到分级管理员的成员, 使用成员作为审批人合并单据并提单

问题:

  1. 如果用户申请的操作-实例比较多, 比如蓝盾, 一次申请100个操作, 每个操作5个实例, 就会产生500次的iam-search-engine的查询, 性能问题会导致产品体验非常差
  2. 如果实例对应的分级管理员比较多, 比如查询出有5个分管理员, 每个分级管理员中有10个成员, 会导致审批人有50个, 造成责权不清晰
wklken commented 3 years ago
  1. /search 接口也需要提供
  2. 批量删除再批量创建, 中间存在一个时间差, 会导致期间这个分级管理员不会被命中. 有没有什么逻辑可以尽量减少这个影响? 使用bulk接口 delete 和 add放在一起处理?
  3. 分级管理员的更新时间 要同 es 里面的某个字段映射, 以便未来排查数据一致性问题
zhu327 commented 1 year ago

需要跟进:

  1. 与产品讨论相关方案, 当前暴力计算过于粗暴, 不合理
  2. 考虑计算平台离线计算是否能满足