> For the complete documentation index, see [llms.txt](https://documentation.alluxio.io/ee-ai-en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.alluxio.io/ee-ai-en/ai-3.6/start/overview/user-roles-access-control.md). # 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: ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: dashboard: image: /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: /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 ```yaml 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](#default-permission-model) 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](#available-disallowpages-options) and [Available disallowComponents Options](#available-disallowcomponents-options) for configurable options. ### Gateway Group Structure ```yaml 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 ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: dashboard: image: /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: /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)](https://www.openpolicyagent.org/docs/latest/) 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: ```json { "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: ```json { "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: ```json { "disallowPages": ["*"], "disallowComponents": ["*"] } ``` The user will be redirected to a 403 Forbidden page after login.