用户角色与访问控制

管理控制台实现了基于角色的访问控制(RBAC)，以确保用户只能访问其分配角色或组所允许的资源和执行相应的操作。

前提条件

要启用基于角色的访问控制，您需要配置以下设置：

1. 在仪表板配置中：

   • 将authorization.enabled设置为true

   • 通过设置以下内容配置Okta认证：

     • 将web.authType设置为okta

     • 使用您的Okta发行者URL设置oktaIssuer

     • 使用您的Okta客户端ID设置oktaClientID

   • 确保您的Okta实例已正确配置必要的角色/组

2. 在网关配置中：

   • 将authorization.enabled和authentication.enabled设置为true

   • 在authentication部分配置OIDC设置以进行令牌验证

配置示例

仪表板配置：

apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
  dashboard:
    image: <PRIVATE_REGISTRY>/alluxio-dashboard
    imageTag: AI-3.6-12.0.2
    enabled: true
    authorization:
      enabled: true
      type: opa
      opa:
        opa config for web console...    
    web:
      authType: okta
      oktaIssuer: your-okta-issuer-url
      oktaClientID: your-okta-client-id

  gateway:
    image: <PRIVATE_REGISTRY>/alluxio-gateway
    imageTag: AI-3.6-12.0.2
    enabled: true
    authentication:
      enabled: true
      type: oidc
      oidc:
        jwksConfigMapName: your-jwks-config-map-name
        jwksFilename: your-jwks-filename
    authorization:
      enabled: true
      opa:
        opa config for gateway...  

注意：确保您的Okta实例已正确配置必要的组和角色。每个用户应被分配到与其在系统中的访问级别相对应的适当组。

默认权限模型

系统提供了三种预定义的用户类型，具有不同的访问级别：

• 超级用户：对系统内的所有页面和操作具有无限制的访问权限。

• 管理员用户：作为组级别的管理员，对所有数据具有只读访问权限，但只能修改其分配组内的资源。

• 普通用户：默认情况下，这些用户没有访问权限，登录后将被重定向到403禁止页面。

对于更灵活的访问控制，您可以使用OPA文件实现自定义授权规则。有关详细信息，请参阅"通过OPA自定义授权"部分。

OPA配置参数

在authorization部分，可以使用以下关键参数：

• roleFieldName：指定包含用户角色信息的令牌字段。

• groupFieldName：指定包含用户组信息的令牌字段。

• superUser / adminUser：定义被授予超级用户或管理员权限的角色列表。

• denyApis（仅限网关）：列出将被阻止的 API 端点。

• allowApis (仅限网关)：列出绕过授权检查的API端点。

• groups：定义每个组的访问控制规则。此部分在OPA中充当data.yaml。默认rego文件使用此数据确定用户授权。

仪表板组结构

groups:
- group: some-group
  role:
  - some-role
  pages:
  - /some-page
  components:
  - some-component

groups 字段为列表类型，其中每个条目用于定义组内特定角色可访问的页面和组件。 若上述默认权限模型符合您的需求，则无需额外配置。 但如果需要对组内特定角色隐藏某些 UI 元素，可添加此配置。 有关可配置选项，请参见 可用 disallowPages 选项 和 可用 disallowComponents 选项。

网关组结构

groups:
- group: some-group
  allow:
    pathPrefixes:
      - prefix: /some-path
        apis:
          - /some-api
  deny:
    pathPrefixes:
      - prefix: /some-path
        apis:
          - /some-api

groups是一个列表，其中每个条目用于定义某个组可以访问或禁止访问的资源路径。在 allow部分，需定义 API 可访问的资源前缀；在 deny 部分，需定义特定 API 禁止访问的资源前缀。

配置示例

以下示例演示了如何实现具有以下要求的基于角色的访问控制系统：

• 用户角色由用户令牌中的userType字段确定（在Okta中预配置）

• 用户组由用户令牌中的department字段确定（在Okta中预配置）

• 超级用户对所有页面和操作具有完全访问权限

• 搜索管理员可以查看所有页面，但仅限于挂载和加载以/search和/related-to-search为前缀的路径

• 推荐管理员可以查看所有页面，但仅限于操作以/recommend为前缀的资源

• 所有其他角色在登录后被拒绝访问并重定向到403禁止页面

仪表板配置

apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
  dashboard:
    image: <PRIVATE_REGISTRY>/alluxio-dashboard
    imageTag: AI-3.6-12.0.2
    enabled: true
    authorization:
      enabled: true
      type: opa
      opa:
        roleFieldName: userType
        groupFieldName: department
        superUser: ['Super', 'SuperUser']
        adminUser: ['Admin', 'Team-Admin']
        groups:
    #      You can leave this section empty if the default permission model is sufficient.
    #      If uncommented, Search Admin will not be able to view the mount page
    #      - group: Search
    #        role:
    #          - Admin
    #        pages:
    #          - /mount
  gateway:
    image: <PRIVATE_REGISTRY>/alluxio-gateway
    imageTag: AI-3.6-12.0.2
    enabled: true
    authorization:
      enabled: true
      type: opa
      opa:
        roleFieldName: userType
        groupFieldName: department
        allowApis: ['/api/allow/all']
        denyApis: ['/api/deny/all']
        superUser: ['Super', 'SuperUser']
        adminUser: ['Admin', 'Team-Admin']
        groups:
        - group: Search
          allow:
            pathPrefixes:
              - prefix: /search
              # If not defined, defaults to allowing all APIs with /search path
              - prefix: /related-to-search
                apis:
                  - /mount
                  - /load
        - group: Recommend
          allow:
            pathPrefixes:
              - prefix: /recommend

通过OPA自定义授权

您可以通过提供自己的OPA (Open Policy Agent)策略文件(.rego)来实现自定义授权规则。要使用自定义策略：

1. 使用ConfigMap挂载文件

2. 在filenames中列出它

3. 设置适当的query

您可以根据需要检查并修改仪表板和网关的ConfigMap中的默认OPA文件。

注意：仪表板OPA策略必须返回以下格式的对象：

{
  "disallowPages": [],
  "disallowComponents": []
}

仪表板使用此响应根据用户权限动态隐藏页面和UI元素。

可用的disallowPages选项：

/monitoring/overview
/monitoring/components
/storage
/operations/preload
/operations/free
/settings/resource-management
/settings/cache-eviction
/support/snapshot
/license
/documentation
* (all pages)

可用的disallowComponents选项：

• createMount – 挂载页面上的"创建"按钮

• createQuota – 配额页面上的"创建"按钮

• createTTL – TTL页面上的"创建"按钮

• createPriority – 优先级页面上的"创建"按钮

• createJob – 预加载和释放页面上的"创建"按钮

• * - 所有组件

响应示例

如果OPA评估返回：

{
  "disallowPages": ["/license"],
  "disallowComponents": ["createMount"]
}

用户将无法访问许可证页面，并且挂载页面上的"创建"按钮将被隐藏。

如果OPA评估返回：

{
  "disallowPages": ["*"],
  "disallowComponents": ["*"]
}

用户将在登录后被重定向到403禁止页面。