User Roles & Access Control

The Management Console implements role-based access control (RBAC) to ensure users can only access resources and perform actions permitted by their assigned roles or groups.

Prerequisites

To enable role-based access control, you need to configure the following settings:

1. In the dashboard configuration:

   • Set authorization.enabled to true

   • Configure Okta authentication by setting:

     • web.authType to okta

     • oktaIssuer with your Okta issuer URL

     • oktaClientID with your Okta client ID

   • Ensure your Okta instance has proper role/group configurations set up

2. In the gateway configuration:

   • Set authorization.enabled and authentication.enabled to true

   • Configure OIDC settings for token validation in the authentication section

Example Configuration

Dashboard configuration:

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...  

Important Notes: Ensure your Okta instance is properly configured with the necessary groups and roles. Each user should be assigned to appropriate groups that correspond to their access level in the system.

Default Permission Model

The system provides three predefined user types with distinct access levels:

• Super User: Has unrestricted access to all pages and actions within the system.

• Admin User: Functions as a group-level administrator with read-only access to all data, but can only modify resources within their assigned group.

• Regular Users: By default, these users have no access and will be redirected to a 403 Forbidden page upon login.

For more flexible access control, you can implement custom authorization rules using OPA files. See the "Custom Authorization via OPA" section for details.

OPA Configuration Parameters

In the authorization section, the following key parameters are available:

• roleFieldName: Specifies the token field that contains the user's role information.

• groupFieldName: Specifies the token field that contains the user's group information.

• superUser / adminUser: Defines lists of roles that are granted super-user or admin privileges.

• allowApis (gateway only): Lists API endpoints that bypass authorization checks.

• denyApis (gateway only): Lists API endpoints that will be blocked.

• groups: Defines access control rules for each group. This section serves as a data.yaml in OPA. The default rego file uses this data to determine user authorization.

Dashboard Group Structure

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

The groups field is a list where each entry defines which pages and components are accessible to specific roles within a group. If the default permission model described above meets your requirements, no additional configuration is needed. However, if you want to hide certain UI elements from specific roles within a group, you can add this configuration. See Available disallowPages Options and Available disallowComponents Options for configurable options.

Gateway Group Structure

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

The groups field is a list where each entry defines which resource paths a group can or cannot access. Under the allow section, you define resource prefixes that can be accessed by APIs. Under the deny section, you define resource prefixes that cannot be accessed by specific APIs.

Configuration Example

The following example demonstrates how to implement a role-based access control system with the following requirements:

• User roles are determined by the userType field in the user's token (pre-configured in Okta)

• User groups are determined by the department field in the user's token (pre-configured in Okta)

• Super Users have full access to all pages and actions

• Search Admins can view all pages but are restricted to mounting and loading paths prefixed with /search and /related-to-search

• Recommend Admins can view all pages but are limited to operating on resources prefixed with /recommend

• All other roles are denied access and redirected to a 403 Forbidden page after login

Dashboard Configuration

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

Custom Authorization via OPA

You can implement custom authorization rules by providing your own OPA (Open Policy Agent) policy file (.rego). To use a custom policy:

1. Mount the file using a ConfigMap

2. List it in filenames

3. Set the appropriate query

You can examine and modify the default OPA files in the ConfigMap for both dashboard and gateway as needed.

Note: Dashboard OPA policies must return an object in the following format:

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

The dashboard uses this response to dynamically hide pages and UI elements based on user permissions.

Available disallowPages Options:

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

Available disallowComponents Options:

• createMount – "Create" button on the Mount page

• createQuota – "Create" button on the Quota page

• createTTL – "Create" button on the TTL page

• createPriority – "Create" button on the Priority page

• createJob – "Create" button on Preload and Free pages

• * - All components

Example Response

If the OPA evaluation returns:

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

The user will be unable to access the License page, and the "Create" button on the Mount page will be hidden.

If the OPA evaluation returns:

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

The user will be redirected to a 403 Forbidden page after login.