OpenRAG安全体系深度解析OpenSearch多租户与角色权限配置原理【免费下载链接】openragOpenRAG is a comprehensive, single package Retrieval-Augmented Generation platform built on Langflow, Docling, and Opensearch.项目地址: https://gitcode.com/GitHub_Trending/open/openragOpenRAG 是基于 Langflow、Docling 和 OpenSearch 构建的单包检索增强生成RAG平台。本文带你深入 OpenRAG 的安全体系解析它是如何用 OpenSearch 认证域、角色权限映射与 DLS 文档级安全实现多用户环境下的数据隔离与最小权限访问。一、安全体系全景三层纵深防御 ️OpenRAG 把安全做成了清晰的三层结构每一层各司其职层级机制核心文件认证层OIDCJWT 内部用户 Basic 双通道config.yml授权层RBAC 角色 角色映射roles_mapping.yml数据隔离层DLS 文档级安全roles.yml普通用户登录后系统并非能看到所有文档而是由 OpenSearch 在每次检索时自动过滤只返回该用户拥有或被授权的数据。这是 OpenRAG 多用户共享同一套向量索引却互不串扰的关键。二、双通道认证OIDC 优先Basic 兜底打开 securityconfig/config.yml可以看到两个按优先级排列的认证域openid_auth_domainorder 0优先用户带着Authorization: Bearer JWT请求时OpenSearch 会回调 OpenRAG 后端的/.well-known/openid-configuration端点验证令牌并从 JWT 中提取sub用户身份与roles角色声明。basic_internal_auth_domainorder 1兜底标准的用户名/密码通道后端是 OpenSearch 内部用户表主要服务于 onboarding 时的admin用户。这种先验 JWT、后验密码的顺序设计很聪明OIDC 用户走无状态令牌校验而初始化阶段平台自身还没有 OIDC 签发能力时Basic 通道保证了系统自举可行。 云上部署IBM 模式有独立的一套 cloud_securityconfig/ 配置差异在于 JWT 身份取user_id、角色取user_roles字段以适配 IBM 身份平台。三、角色与权限映射从登录身份到数据权限1️⃣ 定义角色— roles.yml 中定义了openrag_user_role它授予对documents、knowledge_filters、api_keys等索引的读取权限且每条index_permissions都绑定了一段 DLS 查询下一节详解。2️⃣ 映射角色— roles_mapping.yml 负责谁拥有哪个角色backend_roles: [openrag_user]→ 任何携带openrag_user后端的角色声明的用户自动获得openrag_user_role内部用户admin→ 获得内置的all_access角色。3️⃣ JWT 角色解析— 后端源码 jwt_roles.py 中的extract_jwt_role_names()会把 JWT 里的角色声明值如admin/developer/user/viewer映射成 OpenRAG 内置角色。声明缺失或格式非法时会安全降级为无角色而不是抛错放行这是典型的防御式编程。这套 RBAC 的总开关由 rbac_service.py 中的is_rbac_enforced()控制。四、DLS 文档级安全数据隔离的核心魔法 ✨DLSDocument Level Security是 OpenSearch 的安全特性权限检查下沉到每一条文档。看 roles.yml 中openrag_user_role对文档索引的 DLS 查询它的逻辑是——一条文档只有满足以下任一条件才对当前用户可见owner字段等于当前用户名或 JWT 邮箱allowed_users字段包含当前用户文档级分享allowed_principals关联到该用户的 DLS 主体记录群组/连接器 ACL文档没有owner字段视为公共文档。这实现了检索即过滤即使向量检索召回了 100 条 chunkOpenSearch 也会把不属于你的先剔除掉泄漏在架构层面就不可能发生。群组共享如何实现DLS 只能看到当前 OpenSearch 用户无法直接感知用户属于哪些群组。OpenRAG 的解法是维护一个openrag_dls_principals查找索引dls_principal_service.py 中的DLSPrincipalService会按用户写入一行该用户名 → 其全部 ACL 主体别名的映射DLS 查询再通过terms查找间接命中。服务内置了 TTL 缓存与按用户加锁避免高频重复写。API Key 同样受 DLS 保护roles.yml用户只能读到user_id是自己的密钥或者无主密钥——别人的 API Key 天然不可见。五、多租户策略为何选择全局租户 DLS查看 tenants.yml 会发现它是空的# Empty tenants - using global tenant only这意味着 OpenRAG 刻意没有用 OpenSearch 的项目租户Project Tenants做物理隔离而是采用所有用户共享全局租户 DLS 逻辑隔离的模型。权衡在于✅ 共享租户让跨用户的文档共享allowed_users零成本实现无需跨租户数据搬运✅ 向量索引只建一份索引管理与 embedding 模型迁移更简单✅ DLS 由 OpenSearch 内核强制执行不依赖应用层代码记得过滤。对于绝大多数团队级 RAG 场景逻辑隔离的强度已经足够若你需要更严格的物理隔离如合规审计可在此基础上按租户划分索引或启用项目租户。六、启动时如何落地这些安全配置 安全配置不是一次性的而是每次启动自动校验同步opensearch_init.py 的init_index()在平台启动时执行索引初始化它调用 opensearch_utils.py 中的setup_opensearch_security()根据运行模式自动选择 securityconfig/标准模式或 cloud_securityconfig/云模式目录角色、角色映射、内部用户等配置随后被同步进 OpenSearch 的安全索引环境变量OPENRAG_SKIP_OS_SECURITY_SETUPtrue可跳过该步骤适用于安全由外部平台托管的场景。七、关键配置清单与延伸阅读 配置/源码作用config.yml认证域定义OIDC Basic 顺序与参数roles.yml角色权限与 DLS 查询定义roles_mapping.yml用户/后端角色 → 角色的映射internal_users.yml内部用户admin 占位密码启动时注入jwt_roles.pyJWT 角色声明解析与降级策略dls_principal_service.py群组 ACL 主体的 DLS 查找行维护opensearch_utils.py启动时安全配置同步入口总结OpenRAG 的安全体系可以概括为一句话认证交给 OIDC授权交给 RBAC隔离交给 DLS。三层机制全部依托 OpenSearch 内核强制执行应用层代码只需正确写入owner/allowed_users字段数据隔离即自动生效——这正是企业级 RAG 平台与普通 demo 项目的分水岭。理解这套机制后你就能自信地回答我的文档会不会被别人检索到这个问题不会除非你主动分享。【免费下载链接】openragOpenRAG is a comprehensive, single package Retrieval-Augmented Generation platform built on Langflow, Docling, and Opensearch.项目地址: https://gitcode.com/GitHub_Trending/open/openrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenRAG安全体系深度解析：OpenSearch多租户与角色权限配置原理
OpenRAG安全体系深度解析OpenSearch多租户与角色权限配置原理【免费下载链接】openragOpenRAG is a comprehensive, single package Retrieval-Augmented Generation platform built on Langflow, Docling, and Opensearch.项目地址: https://gitcode.com/GitHub_Trending/open/openragOpenRAG 是基于 Langflow、Docling 和 OpenSearch 构建的单包检索增强生成RAG平台。本文带你深入 OpenRAG 的安全体系解析它是如何用 OpenSearch 认证域、角色权限映射与 DLS 文档级安全实现多用户环境下的数据隔离与最小权限访问。一、安全体系全景三层纵深防御 ️OpenRAG 把安全做成了清晰的三层结构每一层各司其职层级机制核心文件认证层OIDCJWT 内部用户 Basic 双通道config.yml授权层RBAC 角色 角色映射roles_mapping.yml数据隔离层DLS 文档级安全roles.yml普通用户登录后系统并非能看到所有文档而是由 OpenSearch 在每次检索时自动过滤只返回该用户拥有或被授权的数据。这是 OpenRAG 多用户共享同一套向量索引却互不串扰的关键。二、双通道认证OIDC 优先Basic 兜底打开 securityconfig/config.yml可以看到两个按优先级排列的认证域openid_auth_domainorder 0优先用户带着Authorization: Bearer JWT请求时OpenSearch 会回调 OpenRAG 后端的/.well-known/openid-configuration端点验证令牌并从 JWT 中提取sub用户身份与roles角色声明。basic_internal_auth_domainorder 1兜底标准的用户名/密码通道后端是 OpenSearch 内部用户表主要服务于 onboarding 时的admin用户。这种先验 JWT、后验密码的顺序设计很聪明OIDC 用户走无状态令牌校验而初始化阶段平台自身还没有 OIDC 签发能力时Basic 通道保证了系统自举可行。 云上部署IBM 模式有独立的一套 cloud_securityconfig/ 配置差异在于 JWT 身份取user_id、角色取user_roles字段以适配 IBM 身份平台。三、角色与权限映射从登录身份到数据权限1️⃣ 定义角色— roles.yml 中定义了openrag_user_role它授予对documents、knowledge_filters、api_keys等索引的读取权限且每条index_permissions都绑定了一段 DLS 查询下一节详解。2️⃣ 映射角色— roles_mapping.yml 负责谁拥有哪个角色backend_roles: [openrag_user]→ 任何携带openrag_user后端的角色声明的用户自动获得openrag_user_role内部用户admin→ 获得内置的all_access角色。3️⃣ JWT 角色解析— 后端源码 jwt_roles.py 中的extract_jwt_role_names()会把 JWT 里的角色声明值如admin/developer/user/viewer映射成 OpenRAG 内置角色。声明缺失或格式非法时会安全降级为无角色而不是抛错放行这是典型的防御式编程。这套 RBAC 的总开关由 rbac_service.py 中的is_rbac_enforced()控制。四、DLS 文档级安全数据隔离的核心魔法 ✨DLSDocument Level Security是 OpenSearch 的安全特性权限检查下沉到每一条文档。看 roles.yml 中openrag_user_role对文档索引的 DLS 查询它的逻辑是——一条文档只有满足以下任一条件才对当前用户可见owner字段等于当前用户名或 JWT 邮箱allowed_users字段包含当前用户文档级分享allowed_principals关联到该用户的 DLS 主体记录群组/连接器 ACL文档没有owner字段视为公共文档。这实现了检索即过滤即使向量检索召回了 100 条 chunkOpenSearch 也会把不属于你的先剔除掉泄漏在架构层面就不可能发生。群组共享如何实现DLS 只能看到当前 OpenSearch 用户无法直接感知用户属于哪些群组。OpenRAG 的解法是维护一个openrag_dls_principals查找索引dls_principal_service.py 中的DLSPrincipalService会按用户写入一行该用户名 → 其全部 ACL 主体别名的映射DLS 查询再通过terms查找间接命中。服务内置了 TTL 缓存与按用户加锁避免高频重复写。API Key 同样受 DLS 保护roles.yml用户只能读到user_id是自己的密钥或者无主密钥——别人的 API Key 天然不可见。五、多租户策略为何选择全局租户 DLS查看 tenants.yml 会发现它是空的# Empty tenants - using global tenant only这意味着 OpenRAG 刻意没有用 OpenSearch 的项目租户Project Tenants做物理隔离而是采用所有用户共享全局租户 DLS 逻辑隔离的模型。权衡在于✅ 共享租户让跨用户的文档共享allowed_users零成本实现无需跨租户数据搬运✅ 向量索引只建一份索引管理与 embedding 模型迁移更简单✅ DLS 由 OpenSearch 内核强制执行不依赖应用层代码记得过滤。对于绝大多数团队级 RAG 场景逻辑隔离的强度已经足够若你需要更严格的物理隔离如合规审计可在此基础上按租户划分索引或启用项目租户。六、启动时如何落地这些安全配置 安全配置不是一次性的而是每次启动自动校验同步opensearch_init.py 的init_index()在平台启动时执行索引初始化它调用 opensearch_utils.py 中的setup_opensearch_security()根据运行模式自动选择 securityconfig/标准模式或 cloud_securityconfig/云模式目录角色、角色映射、内部用户等配置随后被同步进 OpenSearch 的安全索引环境变量OPENRAG_SKIP_OS_SECURITY_SETUPtrue可跳过该步骤适用于安全由外部平台托管的场景。七、关键配置清单与延伸阅读 配置/源码作用config.yml认证域定义OIDC Basic 顺序与参数roles.yml角色权限与 DLS 查询定义roles_mapping.yml用户/后端角色 → 角色的映射internal_users.yml内部用户admin 占位密码启动时注入jwt_roles.pyJWT 角色声明解析与降级策略dls_principal_service.py群组 ACL 主体的 DLS 查找行维护opensearch_utils.py启动时安全配置同步入口总结OpenRAG 的安全体系可以概括为一句话认证交给 OIDC授权交给 RBAC隔离交给 DLS。三层机制全部依托 OpenSearch 内核强制执行应用层代码只需正确写入owner/allowed_users字段数据隔离即自动生效——这正是企业级 RAG 平台与普通 demo 项目的分水岭。理解这套机制后你就能自信地回答我的文档会不会被别人检索到这个问题不会除非你主动分享。【免费下载链接】openragOpenRAG is a comprehensive, single package Retrieval-Augmented Generation platform built on Langflow, Docling, and Opensearch.项目地址: https://gitcode.com/GitHub_Trending/open/openrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考