如何为分布式系统worker配置独立的资源访问权限

认知澄清：OIDC 不局限于密码认证 #

你对OIDC的理解存在偏差，OIDC协议本身支持多种认证授权流程，其中*客户端凭证模式（Client Credentials Grant）*就是专门为无用户参与的服务间认证场景设计的，完全不需要依赖用户密码，完美适配你的worker到data service的调用场景。

基于现有Keycloak的落地方案 #

你已经在使用Keycloak，完全可以基于现有组件实现需求，不需要额外引入其他安全框架，也不需要自研任何安全逻辑：

• 动态注册客户端：worker容器启动时，通过Keycloak的管理API为当前worker实例创建独立的OIDC客户端，启用客户端凭证模式，你可以选择为客户端分配随机client_secret，或者更安全的配置公私钥签名认证，避免秘钥明文传输风险。
• 权限绑定：在Keycloak中为每个worker对应的客户端配置自定义权限属性，通过内置的Mapper能力，将允许访问的数据集范围、操作权限等字段注入到后续签发的Access Token中。
• worker身份认证：worker启动后，使用自身的客户端凭证向Keycloak请求Access Token，后续所有向data service发起的请求都在请求头中携带Authorization: Bearer <Access Token>。
• data service鉴权：data service只需要集成标准的OIDC资源服务器校验逻辑，本地即可完成Token签名有效性校验，不需要额外调用Keycloak接口，解析Token中的自定义权限字段即可完成访问权限校验，全程不需要信任worker的任何身份声明。

方案优势 #

1. 完全符合零信任要求：所有身份凭证、权限都由Keycloak统一管控，worker凭证泄露可以直接在Keycloak侧吊销对应客户端，无需修改data service配置；即使worker被攻破、运行恶意用户代码，攻击者也只能拿到当前worker权限范围内的Token，无法越权访问其他数据。
2. 无自研安全逻辑：所有认证、鉴权、凭证管理逻辑都是OIDC标准能力，由Keycloak原生实现，完全规避自研安全逻辑的漏洞风险。
3. 适配容器动态扩缩容场景：worker的创建、销毁对应Keycloak客户端的注册、销毁，完全适配容器化部署的弹性需求。

其他方案对比 #

• Kerberos：部署维护成本极高，需要额外维护KDC服务，票据生命周期管理复杂，对容器动态扩缩容的适配成本很高，完全没必要引入。
• SAML：面向浏览器端用户SSO场景的协议，数据格式臃肿，不适合服务间API调用场景，不用考虑。

内容的提问来源于stack exchange，提问作者Leonardo Tavares