# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.alluxio.io/ee-ai-en/ai-3.6/start/overview/user-roles-access-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.