用户角色与访问控制
管理控制台实现了基于角色的访问控制(RBAC)，以确保用户只能访问其分配角色或组所允许的资源和执行相应的操作。
前提条件
要启用基于角色的访问控制，您需要配置以下设置：
在仪表板配置中：
将
authorization.enabled设置为true通过设置以下内容配置Okta认证：
将
web.authType设置为okta使用您的Okta发行者URL设置
oktaIssuer使用您的Okta客户端ID设置
oktaClientID
确保您的Okta实例已正确配置必要的角色/组
在网关配置中：
将
authorization.enabled和authentication.enabled设置为true在
authentication部分配置OIDC设置以进行令牌验证
配置示例
仪表板配置：
注意：确保您的Okta实例已正确配置必要的组和角色。每个用户应被分配到与其在系统中的访问级别相对应的适当组。
默认权限模型
系统提供了三种预定义的用户类型，具有不同的访问级别：
超级用户：对系统内的所有页面和操作具有无限制的访问权限。
管理员用户：作为组级别的管理员，对所有数据具有只读访问权限，但只能修改其分配组内的资源。
普通用户：默认情况下，这些用户没有访问权限，登录后将被重定向到403禁止页面。
对于更灵活的访问控制，您可以使用OPA文件实现自定义授权规则。有关详细信息，请参阅"通过OPA自定义授权"部分。
OPA配置参数
在authorization部分，可以使用以下关键参数：
roleFieldName：指定包含用户角色信息的令牌字段。groupFieldName：指定包含用户组信息的令牌字段。superUser/adminUser：定义被授予超级用户或管理员权限的角色列表。denyApis（仅限网关）：列出将被阻止的 API 端点。allowApis(仅限网关)：列出绕过授权检查的API端点。groups：定义每个组的访问控制规则。此部分在OPA中充当data.yaml。默认rego文件使用此数据确定用户授权。
仪表板组结构
groups 字段为列表类型，其中每个条目用于定义组内特定角色可访问的页面和组件。
若上述默认权限模型符合您的需求，则无需额外配置。
但如果需要对组内特定角色隐藏某些 UI 元素，可添加此配置。
有关可配置选项，请参见 可用 disallowPages 选项 和 可用 disallowComponents 选项。
网关组结构
groups是一个列表，其中每个条目用于定义某个组可以访问或禁止访问的资源路径。在 allow部分，需定义 API 可访问的资源前缀；在 deny 部分，需定义特定 API 禁止访问的资源前缀。
配置示例
以下示例演示了如何实现具有以下要求的基于角色的访问控制系统：
用户角色由用户令牌中的
userType字段确定（在Okta中预配置）用户组由用户令牌中的
department字段确定（在Okta中预配置）超级用户对所有页面和操作具有完全访问权限
搜索管理员可以查看所有页面，但仅限于挂载和加载以
/search和/related-to-search为前缀的路径推荐管理员可以查看所有页面，但仅限于操作以
/recommend为前缀的资源所有其他角色在登录后被拒绝访问并重定向到403禁止页面
仪表板配置
通过OPA自定义授权
使用
ConfigMap挂载文件在
filenames中列出它设置适当的
query
您可以根据需要检查并修改仪表板和网关的ConfigMap中的默认OPA文件。
注意：仪表板OPA策略必须返回以下格式的对象：
仪表板使用此响应根据用户权限动态隐藏页面和UI元素。
可用的disallowPages选项：
disallowPages选项：可用的disallowComponents选项：
disallowComponents选项：createMount– 挂载页面上的"创建"按钮createQuota– 配额页面上的"创建"按钮createTTL– TTL页面上的"创建"按钮createPriority– 优先级页面上的"创建"按钮createJob– 预加载和释放页面上的"创建"按钮*- 所有组件
响应示例
如果OPA评估返回：
用户将无法访问许可证页面，并且挂载页面上的"创建"按钮将被隐藏。
如果OPA评估返回：
用户将在登录后被重定向到403禁止页面。
Last updated