尧图网页设计 
Wazuh RBAC 实战从内部用户创建、角色映射到 Agent 分组授权的完整指南【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuhWazuh 采用双层 RBAC体系Indexer 侧的内置用户库负责认证Internal UsersWazuh API 侧的 RBACUser/Role/Policy/Rule负责鉴权。本文基于仓库文档 docs/ref/modules/rbac/README.md 并结合 framework/wazuh/rbac 目录下的源码实现讲解如何创建并配置管理员用户、只读用户、自定义内部用户以及通过 DLSDocument Level Security将用户授权到指定 Agent 分组的完整流程读完后可独立完成 Wazuh 平台中用户—角色—策略—资源全链路的权限规划与落地。RBAC 模型总览两套体系如何协作Wazuh RBAC 允许基于分配给用户的角色和策略来控制对 Wazuh 资源的访问它是一个易于使用的权限管理系统。Wazuh 平台内置一个内部用户数据库可直接用于认证也可以与 LDAP、Active Directory 等外部认证系统叠加使用。从源码结构看Wazuh API 侧的 RBAC 由五种实体构成默认配置集中在 framework/wazuh/rbac/default/ 目录下实体默认配置文件说明Userusers.yamlAPI 内部用户Roleroles.yaml角色聚合多个 Policy可绑定多个 RulePolicypolicies.yaml定义action resource effect(allow/deny)组合Rulerules.yaml认证上下文auth context匹配规则用于 run-as 场景Relationshipsrelationships.yamlUser↔Role、Role↔Policy/Rule 的映射关系内置的默认角色见 roles.yaml包括administrator系统管理员拥有完整访问权限readonly只读角色可读取系统全部信息users_admin用户管理员拥有全部用户相关功能权限agents_readonly/agents_adminAgent 功能的只读/全量管理角色cluster_readonly/cluster_admin集群Manager功能的只读/全量管理角色wazuh_indexer_adminIndexer 管理员只能读取 security 配置而不能修改。而 relationships.yaml 展示了默认角色的权限组合方式administrator组合了agents_all、security_all、cluster_all、mitre_read、task_status五个策略并绑定了wui_elastic_admin、wui_opensearch_admin两条规则readonly则只组合agents_read、cluster_read、mitre_read。默认内部用户见 users.yaml有两个wazuhWazuh 超级用户默认密码wazuh与wazuh-wuiWazuh UI 超级用户默认密码wazuh-wui两者均设置allow_run_as: True均可绑定administrator角色。生产环境中应通过 API 修改这些初始密码修改接口update_user要求新密码满足 12–64 位且含大小写字母、数字与特殊字符的正则校验见 framework/wazuh/security.py 中的_user_password。场景一创建并配置 Wazuh 管理员用户目标创建一个内部用户并赋予管理员权限。操作步骤以管理员身份登录 Wazuh Dashboard。点击左上角菜单图标☰进入Indexer managementSecurityInternal users。点击Create internal user填写用户名和密码Backend role 输入admin点击Create。将该用户映射到 Wazuh点击☰进入Server managementSecurityRoles mapping。点击Create Role mapping并填写Role mapping name映射名称、Roles 选择administrator、Internal users 选择上一步创建的用户。点击Save role mapping。最后确认以下配置文件中run_as已设置为true/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml然后重启 Dashboard 服务并清除浏览器缓存。源码佐证run_as机制对应 API 侧的allow_run_as用户属性。在 framework/wazuh/security.py 的edit_run_as函数中该属性可被动态开启/关闭且受security:edit_run_as动作保护当用户通过认证上下文authorization context登录时系统按角色绑定的 Rule 计算其有效权限——默认规则 rules.yaml 中即包含wui_elastic_admin匹配username: elastic、wui_opensearch_admin匹配user_name: admin等规则把 Indexer 的内置管理员身份自动提升为 Wazuh 的administrator权限。Rule 支持的匹配操作符FIND、FIND$、MATCH、AND/OR/NOT及正则可参考测试数据 framework/wazuh/rbac/tests/data/RBAC_rules_roles.json。场景二创建并配置 Wazuh 只读用户目标创建一个只能查看、不能修改的用户。以管理员身份登录 Wazuh Dashboard。进入Indexer managementSecurityInternal users。创建一个内部用户。进入Roles创建一个角色配置Cluster permissionscluster_composite_ops_roIndex*Index permissionsreadTenant permissionsglobal_tenantRead only将该用户映射到上述角色。在Server managementSecurityRoles mapping中创建对应的 role mappingWazuh 侧选择readonly类角色。保存并重启 Dashboard。源码佐证Wazuh 侧的只读权限由 policies.yaml 中的agents_read与cluster_read策略实现——前者只允许agent:read资源agent:id:*、agent:group:*和group:read资源group:id:*后者只允许cluster:status、cluster:read、cluster:read_api_config等读操作effect 均为allow。这正是readonly角色的默认权限组合。场景三创建任意内部用户并映射到 Wazuh通用流程四步创建内部用户Indexer Internal users创建角色Wazuh 侧 Role或指定已有角色将角色映射到该用户在Server managementSecurity中创建 role mapping。完成后重启 Dashboard 并清除浏览器缓存。Wazuh 侧 RBAC 的鉴权链路源码级解析Wazuh 侧角色、策略、规则的增删改查由 framework/wazuh/security.py 中的框架函数实现每一个函数都被expose_resources装饰器包裹声明其暴露的动作:资源对例如create_user动作security:create_user资源*:*:*无资源约束security.pyget_users动作security:read资源user:id:{user_ids}动态资源取自请求参数set_user_role动作security:update资源user:id:{user_id}与role:id:{role_ids}的组合get_rbac_resources/get_rbac_actions动作security:read_config可直接从 API 查询 RBAC 目录catalog中所有合法资源与动作定义方便在编写 Policy 时对照 api/api/spec/spec.yaml 中的x-rbac-catalog。真正的授权判定逻辑位于 framework/wazuh/rbac/decorators.pyexpose_resourcesL425-L502拦截被装饰的框架函数先通过_get_required_permissions解析出本次请求所需的action - [resource]对资源中的{param}占位符会从请求参数中动态填充如agent:id:{agents_list}会展开为每个 agent id_match_permissionsL253-L276将所需权限与当前 token 中的用户权限由 Role 的 Policies 展开而来做匹配_expand_resourceL23-L74负责通配符展开agent:id:*会展开为系统中所有 agentagent:group:Team_A会被expand_group展开为该组下的所有 agent idagent:group标识符在匹配时统一归一化为agent:id_process_effectL165-L190按 Policy 的effect字段处理allow时把展开后的资源加入允许集合deny时执行集合差运算——因此 Policy 支持显式拒绝可与 allow 策略叠加实现全量放行、个别排除的粒度控制匹配结果决定函数参数被过滤成哪些合法 id无权限且请求指定了 id 时抛出WazuhPermissionError(4000)未指定 id 时自动把查询参数改写为允许集合实现用户只能看到自己有权限的 agent。RBAC 的运行模式由rbac_mode控制API 默认值为white白名单只允许策略明确放行的操作见 api/api/configuration.py在 black 模式下空策略意味着放行具体实现在_match_permissions中的_black_expansion分支。相关的装饰器行为可用 framework/wazuh/rbac/tests/test_decorators.py 及其测试数据如RBAC_decorators_permissions_white.json、RBAC_decorators_permissions_black.json验证白/黑名单两种模式下的判定差异。场景四用例只授权用户读取和管理某个 Agent 分组设定Team_A包含 agent 001、003Team_B包含 agent 002、003。目标是让 Team_A 的运维人员只能看到并操作 Team_A 的 agent。4.1 创建带 DLS 的 Indexer 角色在 Dashboard 侧创建角色并为告警索引配置 DLSDocument Level Security查询{ bool: { must: { match: { agent.labels.group: Team_A } } } }为监控数据monitoring索引配置对应的 DLS{ bool: { must: { match: { group: Team_A } } } }然后把该角色映射到目标用户。DLS 生效的前提仍是run_as: true见场景一。4.2 在 Wazuh 侧完成角色映射创建 PolicyActionagent:readResourceagent:groupResource identifierTeam_A创建 Role 并关联该 Policy如需管理权限可参照 policies.yaml 中agents_all策略的动作集追加agent:delete、agent:modify_group、agent:restart、agent:reload、agent:upgrade等创建 Role mapping 时若还需查看集群状态等基础信息可为该角色叠加cluster_readonly权限其对应的cluster_read策略见 policies.yaml重启 Dashboard。最终效果该用户只能看到 Team_A 的 agent。从源码看这一效果正是_expand_resource中expand_group(Team_A)展开组内 agent id 后与请求资源求交集的结果decorators.py 中还会把agent:group标识符归一化为agent:id再比对。Agent 动作参考表以下 RBAC 动作控制 Agent 相关操作Action可用 Resources说明agent:readagent:id、agent:group读取 agent 信息agent:create*注册新 agentagent:deleteagent:id、agent:group删除 agentagent:modify_groupagent:id、agent:group将 agent 加入/移出分组agent:restartagent:id、agent:group重启 agent要求 agent v5.0.0agent:reloadagent:id、agent:group不重启即可重载 agent 配置要求 agent v5.0.0agent:upgradeagent:id、agent:group升级 agent其中agent:reload是 v5.0.0 随新控制通道机制引入的动作取代了此前基于 Active Response 的重启方式。这一点可从默认策略中得到印证policies.yaml 中agents_all策略的agents段落同时列出了agent:read、agent:delete、agent:modify_group、agent:reconnect、agent:restart、agent:reload、agent:upgrade七个动作资源限定为agent:id:*与agent:group:*。完整的动作目录含每个动作对应的 API 端点与合法资源可通过get_rbac_actions接口从x-rbac-catalog中动态获取security.py编写 Policy 前建议先查询以保证动作名拼写准确。关键实现文件索引默认 RBAC 配置framework/wazuh/rbac/default/roles.yaml、policies.yaml、rules.yaml、users.yaml、relationships.yaml文件头均标注 WAZUH SYSTEM FILE, PLEASE DO NOT MODIFY即出厂基线自定义内容应通过 API/Dashboard 新增而非修改该目录用户/角色/策略/规则管理框架函数framework/wazuh/security.py授权装饰器与资源展开逻辑framework/wazuh/rbac/decorators.py安全数据访问对象AuthenticationManager、RolesManager、PoliciesManager、RulesManagerframework/wazuh/rbac/orm.pyAPI 控制器api/api/controllers/security_controller.pyAPI 规格与 RBAC 目录api/api/spec/spec.yaml集成测试RBAC 黑白名单端点行为api/test/integration/ 目录下的test_rbac_white_*/test_rbac_black_*tavern 用例小结Wazuh 的权限治理分为三步走在 Indexer 侧创建内部用户可选配 DLS 限定文档可见范围在 Wazuh 侧用 Policyactionresourceeffect组装 Role 并映射到用户最后通过 Dashboard 的 role mapping 打通两侧身份。run_as: true是让外部认证上下文生效的总开关rbac_mode默认 white决定未显式授权时的兜底行为而agent:group资源配合expand_group展开机制使得按组授权在 API 层自动等价于对该组内每个 agent id 授权这正是场景四中用户只能看到 Team_A agent 的底层原理。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wazuh RBAC 实战：从内部用户创建、角色映射到 Agent 分组授权的完整指南
Wazuh RBAC 实战从内部用户创建、角色映射到 Agent 分组授权的完整指南【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuhWazuh 采用双层 RBAC体系Indexer 侧的内置用户库负责认证Internal UsersWazuh API 侧的 RBACUser/Role/Policy/Rule负责鉴权。本文基于仓库文档 docs/ref/modules/rbac/README.md 并结合 framework/wazuh/rbac 目录下的源码实现讲解如何创建并配置管理员用户、只读用户、自定义内部用户以及通过 DLSDocument Level Security将用户授权到指定 Agent 分组的完整流程读完后可独立完成 Wazuh 平台中用户—角色—策略—资源全链路的权限规划与落地。RBAC 模型总览两套体系如何协作Wazuh RBAC 允许基于分配给用户的角色和策略来控制对 Wazuh 资源的访问它是一个易于使用的权限管理系统。Wazuh 平台内置一个内部用户数据库可直接用于认证也可以与 LDAP、Active Directory 等外部认证系统叠加使用。从源码结构看Wazuh API 侧的 RBAC 由五种实体构成默认配置集中在 framework/wazuh/rbac/default/ 目录下实体默认配置文件说明Userusers.yamlAPI 内部用户Roleroles.yaml角色聚合多个 Policy可绑定多个 RulePolicypolicies.yaml定义action resource effect(allow/deny)组合Rulerules.yaml认证上下文auth context匹配规则用于 run-as 场景Relationshipsrelationships.yamlUser↔Role、Role↔Policy/Rule 的映射关系内置的默认角色见 roles.yaml包括administrator系统管理员拥有完整访问权限readonly只读角色可读取系统全部信息users_admin用户管理员拥有全部用户相关功能权限agents_readonly/agents_adminAgent 功能的只读/全量管理角色cluster_readonly/cluster_admin集群Manager功能的只读/全量管理角色wazuh_indexer_adminIndexer 管理员只能读取 security 配置而不能修改。而 relationships.yaml 展示了默认角色的权限组合方式administrator组合了agents_all、security_all、cluster_all、mitre_read、task_status五个策略并绑定了wui_elastic_admin、wui_opensearch_admin两条规则readonly则只组合agents_read、cluster_read、mitre_read。默认内部用户见 users.yaml有两个wazuhWazuh 超级用户默认密码wazuh与wazuh-wuiWazuh UI 超级用户默认密码wazuh-wui两者均设置allow_run_as: True均可绑定administrator角色。生产环境中应通过 API 修改这些初始密码修改接口update_user要求新密码满足 12–64 位且含大小写字母、数字与特殊字符的正则校验见 framework/wazuh/security.py 中的_user_password。场景一创建并配置 Wazuh 管理员用户目标创建一个内部用户并赋予管理员权限。操作步骤以管理员身份登录 Wazuh Dashboard。点击左上角菜单图标☰进入Indexer managementSecurityInternal users。点击Create internal user填写用户名和密码Backend role 输入admin点击Create。将该用户映射到 Wazuh点击☰进入Server managementSecurityRoles mapping。点击Create Role mapping并填写Role mapping name映射名称、Roles 选择administrator、Internal users 选择上一步创建的用户。点击Save role mapping。最后确认以下配置文件中run_as已设置为true/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml然后重启 Dashboard 服务并清除浏览器缓存。源码佐证run_as机制对应 API 侧的allow_run_as用户属性。在 framework/wazuh/security.py 的edit_run_as函数中该属性可被动态开启/关闭且受security:edit_run_as动作保护当用户通过认证上下文authorization context登录时系统按角色绑定的 Rule 计算其有效权限——默认规则 rules.yaml 中即包含wui_elastic_admin匹配username: elastic、wui_opensearch_admin匹配user_name: admin等规则把 Indexer 的内置管理员身份自动提升为 Wazuh 的administrator权限。Rule 支持的匹配操作符FIND、FIND$、MATCH、AND/OR/NOT及正则可参考测试数据 framework/wazuh/rbac/tests/data/RBAC_rules_roles.json。场景二创建并配置 Wazuh 只读用户目标创建一个只能查看、不能修改的用户。以管理员身份登录 Wazuh Dashboard。进入Indexer managementSecurityInternal users。创建一个内部用户。进入Roles创建一个角色配置Cluster permissionscluster_composite_ops_roIndex*Index permissionsreadTenant permissionsglobal_tenantRead only将该用户映射到上述角色。在Server managementSecurityRoles mapping中创建对应的 role mappingWazuh 侧选择readonly类角色。保存并重启 Dashboard。源码佐证Wazuh 侧的只读权限由 policies.yaml 中的agents_read与cluster_read策略实现——前者只允许agent:read资源agent:id:*、agent:group:*和group:read资源group:id:*后者只允许cluster:status、cluster:read、cluster:read_api_config等读操作effect 均为allow。这正是readonly角色的默认权限组合。场景三创建任意内部用户并映射到 Wazuh通用流程四步创建内部用户Indexer Internal users创建角色Wazuh 侧 Role或指定已有角色将角色映射到该用户在Server managementSecurity中创建 role mapping。完成后重启 Dashboard 并清除浏览器缓存。Wazuh 侧 RBAC 的鉴权链路源码级解析Wazuh 侧角色、策略、规则的增删改查由 framework/wazuh/security.py 中的框架函数实现每一个函数都被expose_resources装饰器包裹声明其暴露的动作:资源对例如create_user动作security:create_user资源*:*:*无资源约束security.pyget_users动作security:read资源user:id:{user_ids}动态资源取自请求参数set_user_role动作security:update资源user:id:{user_id}与role:id:{role_ids}的组合get_rbac_resources/get_rbac_actions动作security:read_config可直接从 API 查询 RBAC 目录catalog中所有合法资源与动作定义方便在编写 Policy 时对照 api/api/spec/spec.yaml 中的x-rbac-catalog。真正的授权判定逻辑位于 framework/wazuh/rbac/decorators.pyexpose_resourcesL425-L502拦截被装饰的框架函数先通过_get_required_permissions解析出本次请求所需的action - [resource]对资源中的{param}占位符会从请求参数中动态填充如agent:id:{agents_list}会展开为每个 agent id_match_permissionsL253-L276将所需权限与当前 token 中的用户权限由 Role 的 Policies 展开而来做匹配_expand_resourceL23-L74负责通配符展开agent:id:*会展开为系统中所有 agentagent:group:Team_A会被expand_group展开为该组下的所有 agent idagent:group标识符在匹配时统一归一化为agent:id_process_effectL165-L190按 Policy 的effect字段处理allow时把展开后的资源加入允许集合deny时执行集合差运算——因此 Policy 支持显式拒绝可与 allow 策略叠加实现全量放行、个别排除的粒度控制匹配结果决定函数参数被过滤成哪些合法 id无权限且请求指定了 id 时抛出WazuhPermissionError(4000)未指定 id 时自动把查询参数改写为允许集合实现用户只能看到自己有权限的 agent。RBAC 的运行模式由rbac_mode控制API 默认值为white白名单只允许策略明确放行的操作见 api/api/configuration.py在 black 模式下空策略意味着放行具体实现在_match_permissions中的_black_expansion分支。相关的装饰器行为可用 framework/wazuh/rbac/tests/test_decorators.py 及其测试数据如RBAC_decorators_permissions_white.json、RBAC_decorators_permissions_black.json验证白/黑名单两种模式下的判定差异。场景四用例只授权用户读取和管理某个 Agent 分组设定Team_A包含 agent 001、003Team_B包含 agent 002、003。目标是让 Team_A 的运维人员只能看到并操作 Team_A 的 agent。4.1 创建带 DLS 的 Indexer 角色在 Dashboard 侧创建角色并为告警索引配置 DLSDocument Level Security查询{ bool: { must: { match: { agent.labels.group: Team_A } } } }为监控数据monitoring索引配置对应的 DLS{ bool: { must: { match: { group: Team_A } } } }然后把该角色映射到目标用户。DLS 生效的前提仍是run_as: true见场景一。4.2 在 Wazuh 侧完成角色映射创建 PolicyActionagent:readResourceagent:groupResource identifierTeam_A创建 Role 并关联该 Policy如需管理权限可参照 policies.yaml 中agents_all策略的动作集追加agent:delete、agent:modify_group、agent:restart、agent:reload、agent:upgrade等创建 Role mapping 时若还需查看集群状态等基础信息可为该角色叠加cluster_readonly权限其对应的cluster_read策略见 policies.yaml重启 Dashboard。最终效果该用户只能看到 Team_A 的 agent。从源码看这一效果正是_expand_resource中expand_group(Team_A)展开组内 agent id 后与请求资源求交集的结果decorators.py 中还会把agent:group标识符归一化为agent:id再比对。Agent 动作参考表以下 RBAC 动作控制 Agent 相关操作Action可用 Resources说明agent:readagent:id、agent:group读取 agent 信息agent:create*注册新 agentagent:deleteagent:id、agent:group删除 agentagent:modify_groupagent:id、agent:group将 agent 加入/移出分组agent:restartagent:id、agent:group重启 agent要求 agent v5.0.0agent:reloadagent:id、agent:group不重启即可重载 agent 配置要求 agent v5.0.0agent:upgradeagent:id、agent:group升级 agent其中agent:reload是 v5.0.0 随新控制通道机制引入的动作取代了此前基于 Active Response 的重启方式。这一点可从默认策略中得到印证policies.yaml 中agents_all策略的agents段落同时列出了agent:read、agent:delete、agent:modify_group、agent:reconnect、agent:restart、agent:reload、agent:upgrade七个动作资源限定为agent:id:*与agent:group:*。完整的动作目录含每个动作对应的 API 端点与合法资源可通过get_rbac_actions接口从x-rbac-catalog中动态获取security.py编写 Policy 前建议先查询以保证动作名拼写准确。关键实现文件索引默认 RBAC 配置framework/wazuh/rbac/default/roles.yaml、policies.yaml、rules.yaml、users.yaml、relationships.yaml文件头均标注 WAZUH SYSTEM FILE, PLEASE DO NOT MODIFY即出厂基线自定义内容应通过 API/Dashboard 新增而非修改该目录用户/角色/策略/规则管理框架函数framework/wazuh/security.py授权装饰器与资源展开逻辑framework/wazuh/rbac/decorators.py安全数据访问对象AuthenticationManager、RolesManager、PoliciesManager、RulesManagerframework/wazuh/rbac/orm.pyAPI 控制器api/api/controllers/security_controller.pyAPI 规格与 RBAC 目录api/api/spec/spec.yaml集成测试RBAC 黑白名单端点行为api/test/integration/ 目录下的test_rbac_white_*/test_rbac_black_*tavern 用例小结Wazuh 的权限治理分为三步走在 Indexer 侧创建内部用户可选配 DLS 限定文档可见范围在 Wazuh 侧用 Policyactionresourceeffect组装 Role 并映射到用户最后通过 Dashboard 的 role mapping 打通两侧身份。run_as: true是让外部认证上下文生效的总开关rbac_mode默认 white决定未显式授权时的兜底行为而agent:group资源配合expand_group展开机制使得按组授权在 API 层自动等价于对该组内每个 agent id 授权这正是场景四中用户只能看到 Team_A agent 的底层原理。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考