# Deployment When [deploying the Operator](https://documentation.alluxio.io/ee-ai-en/ai-3.7/start/installing-on-kubernetes#id-2.-deploy-alluxio-operator), append a new section for `console` as shown below. ```yaml global: image: /alluxio-operator imageTag: 3.3.2 console: web: authType: none ``` When `authType` is `none`, the management console has no login page and does not perform any authentication. For production environment security, it is recommended to enable authentication. You can change `authType` to `okta` to integrate with Okta. For more details, please refer to [Okta Auth Type](#okta-auth-type). Configuration example with Okta enabled: ```yaml global: image: /alluxio-operator imageTag: 3.3.2 console: web: authType: okta oktaIssuer: https://your-okta-domain/oauth2/default oktaClientID: your-client-id-value ``` After installing the Operator, you can verify that the console pod is running in the `alluxio-operator` namespace: ```bash kubectl get pods -n alluxio-operator ``` Example output: ```bash NAME READY STATUS RESTARTS AGE alluxio-cluster-controller-6768ff89dc-4dggt 1/1 Running 0 2m alluxio-collectinfo-controller-87bbf67c8-m6rf6 1/1 Running 0 2m alluxio-console-7ff487467c-kt88v 1/1 Running 0 2m alluxio-csi-controller-67b6c49786-55g9w 2/2 Running 0 2m alluxio-csi-nodeplugin-lszbp 2/2 Running 0 2m alluxio-csi-nodeplugin-pmcwg 2/2 Running 0 2m alluxio-csi-nodeplugin-qknjd 2/2 Running 0 2m alluxio-license-controller-55fb54868-rmsq8 1/1 Running 0 2m alluxio-ufs-controller-579c85f95f-vpd8d 1/1 Running 0 2m ``` Look for the `alluxio-console-*` pod (in this example, `alluxio-console-7ff487467c-kt88v`) to confirm the management console is running. Once confirmed, you can proceed to access the management console as described below. ## Accessing the Management Console There are a few ways to access the console. ### Accessing via Node Hostname By default, the management console creates a Kubernetes Service of type `ClusterIP`, making it accessible only within the cluster. To access from outside via hostname or IP address, you can change the Service type to `NodePort` and specify a port (e.g., `30002`) to expose the service. ```yaml global: image: /alluxio-operator imageTag: 3.3.2 console: web: authType: okta oktaIssuer: https://your-okta-domain/oauth2/default oktaClientID: your-client-id-value service: type: NodePort ports: api: 80 nodePort: 30002 ``` If you know the host's IP address and have configured the appropriate security groups (specific settings depend on your cloud service provider), you can access the service via `IP-address:30002`. If you want to access via hostname, you can get the hostname: ```shell kubectl -n alluxio-operator get pod $(kubectl -n alluxio-operator get pod -l app.kubernetes.io/component=console --no-headers -o custom-columns=:metadata.name) -o jsonpath='{.spec.nodeName}' ``` Assume the hostname is `foo.kubernetes.org`, then you can access the Management Console on: ``` http://foo.kubernetes.org:80/ ``` ### Accessing via Load Balancer To expose the Management Console externally, you can configure a Kubernetes Service of type `LoadBalancer`. This allows traffic from outside the cluster to reach the console component. Below is an example Service definition for exposing the Console via a Load Balancer: ```yaml apiVersion: v1 kind: Service metadata: name: load-balancer namespace: alluxio-operator annotations: # The following annotations are AWS-specific. For other cloud providers, please refer to their documentation for LoadBalancer configuration. service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-type: nlb spec: type: LoadBalancer ports: - protocol: TCP port: 80 targetPort: 80 selector: app.kubernetes.io/instance: operator app.kubernetes.io/name: console ``` Save the above as `load-balancer.yaml` and create it via ```shell kubectl create -f load-balancer.yaml ``` Once the service is created, Kubernetes will provision an external IP or DNS name, depending on your cloud provider. You can check the status using: ```bash kubectl -n alluxio-operator get service load-balancer ``` Example output: ```bash load-balancer LoadBalancer 171.33.111.33 some-random-string.region.elb.amazonaws.com 80:30977/TCP 8m50s ``` You can now access the Management Console in your browser using the external IP or DNS name. ### Cluster Management After entering the homepage, the page will display all deployed Alluxio clusters in the current Kubernetes environment.
You can also click the Add Cluster button to create a new cluster. The system provides two ways to create clusters: * **Manual Configuration**: Configure cluster parameters by filling out forms, suitable for scenarios requiring step-by-step configuration * **Upload Yaml**: Directly upload existing Alluxio YAML configuration files, suitable for cases where configuration files already exist In this example, we demonstrate how to use Manual Configuration to create a cluster by filling out forms.
In the Manual Configuration page, you need to fill in the basic information of the cluster. In this example, we will deploy a cluster with a Console, so we need to enable both Gateway and Console.
After clicking Next, the system will generate a YAML file with resource type AlluxioCluster. This file will be used to create a new cluster named "alluxio". You can edit this YAML file as needed, adding or modifying configuration items.
From the generated YAML file, you can see that because Gateway and Console are enabled, the system has automatically generated basic configurations for these two components. Next, we will focus on Console-related configuration options. #### Enable Audit Logging Audit logging tracks user activities and system events in the Management Console for security and compliance purposes. This feature is enabled by default and requires no additional configuration. **Accessing Audit Logs:** You can view the log files at `/opt/alluxio/console/audit-logs/console-audit.log` inside the Web Console Pod. **Configuration Example:** ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: console: enabled: true image: /alluxio-console imageTag: AI-3.7-13.0.0 auditLog: enabled: true # Set to false to disable audit logging ``` ### Configuring TLS Connection Between Gateway and Console When TLS (Transport Layer Security) is enabled in your Gateway, you need to configure the Management Console to establish secure TLS connections. This involves providing a CA (Certificate Authority) certificate to the Web Console, which it will use to verify the Gateway's TLS certificate. 1. **Prepare Certificate Files** * Obtain a valid CA certificate file (typically named `ca.crt`) * Prepare the Gateway certificate (`server.crt`) and private key (`server.key`) files * Ensure the Gateway certificate is properly signed by the CA 2. **Create a Kubernetes Secret** ```bash # Create a secret with the CA certificate, Gateway certificate, and key kubectl create secret generic gateway-k8s-secret-name \ --from-file=ca.crt=/path/to/ca.crt \ --from-file=server.key=/path/to/server.key \ --from-file=server.crt=/path/to/server.crt \ --namespace=alx-ns ``` 3. **Configure Your Alluxio Cluster** ```yaml apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: gateway: enabled: true image: /alluxio-gateway imageTag: AI-3.7-13.0.0 tls: enabled: true secretName: gateway-k8s-secret-name certFile: server.crt certKeyFile: server.key console: enabled: true image: /alluxio-dashboard imageTag: AI-3.7-13.0.0 gateway: secretName: gateway-k8s-secret-name caFile: ca.crt ``` **Important Notes:** * The `secretName` in your configuration must exactly match the name of the created Kubernetes secret * All filenames (`caFile`, `certFile`, `certKeyFile`) must match the filenames used in the secret * Verify that your CA certificate and Gateway certificate are valid and not expired * The Management Console uses the CA certificate to verify the Gateway's TLS certificate during connection * **Critical:** The CA certificate must belong to the same certificate chain as the Gateway's certificate; using an unrelated CA will cause TLS verification failures ### Okta Auth Type The Okta authentication provides secure enterprise-level access control for your Management Console. Follow these steps to set up and use Okta authentication: **1. Application Configuration in Okta** 1. Log in to your Okta Admin Dashboard 2. Navigate to **Applications** > **Applications** 3. Click **Create App Integration** 4. Select the **Single-Page Application (SPA)** type * This application type utilizes the [Authorization Code Flow with PKCE](https://developer.okta.com/docs/guides/implement-grant-type/authcodepkce/main/#about-the-authorization-code-grant-with-pkce) for secure client-side token acquisition
5. Complete the basic configuration with your application name and some options
6. In the **Login** section of your application settings, configure: * **Sign-in redirect URIs**: `http://your-domain:your-port/login/callback` * **Sign-out redirect URIs**: `http://your-domain:your-port/user/login` * Replace `your-domain` and `your-port` with your actual domain and port values * These settings ensure proper redirection after Okta authentication completes
7. Save your application configuration **2. User Group Assignment and Authorization** To control access to the Management Console: 1. In your Okta Admin Dashboard, navigate to **Directory** > **Groups**
2. Create user groups if they don't already exist (e.g., "Admins") 3. Assign appropriate users to these groups 4. Return to your application settings 5. Under the **Assignments** tab, assign the user groups that should have access to the Management Console
**3. Authorization Server Configuration** The Management Console requires specific OAuth scopes for proper operation: 1. In your Okta Admin Dashboard, navigate to **Security** > **API** 2. Select your authorization server (or create one if needed) 3. Go to the **Scopes** tab 4. Click **Add Scope**
5. Create a scope named `alluxio` with an appropriate description 6. The Management Console requires both the `openid` scope (default in Okta) and this custom `alluxio` scope 7. If authorization is enabled in your deployment, associate your specified claims with this scope. Here in the screenshot down below, the `roleFieldName` in authorization config is set to `userType` and `groupFieldName` is set to `department`. Please visit [User Roles & Access Control](https://documentation.alluxio.io/ee-ai-en/ai-3.7/administration/overview/user-roles-access-control) for more information.
**4. Obtaining Configuration Values** After completing the setup, gather these values for your Management Console configuration: 1. **Okta Issuer URL**: * Navigate to **Security** > **API** in your Okta Admin Dashboard * Select your authorization server * Copy the Issuer URL (format: `https://your-okta-domain/oauth2/default`) 2. **Client ID**: * Go to your application's settings * Copy the Client ID from the **Client Credentials** section 3. Update your Alluxio configuration with these values: ```yaml web: authType: okta oktaIssuer: https://your-okta-domain/oauth2/default oktaClientID: your-client-id-value ``` **5. Login Process**

Management Console login page with Okta option

Okta authentication portal

When using Okta authentication: 1. Navigate to your Management Console URL 2. The login page will display a "Login with Okta" button 3. Click this button to be redirected to your organization's Okta authentication portal 4. Enter your Okta credentials and complete any multi-factor authentication if configured 5. Upon successful authentication, you will be redirected back to the Management Console's dashboard 6. Your session will remain active based on your Okta token configuration **6. Troubleshooting Okta Integration** If you encounter issues with Okta authentication: * Verify that redirect URIs are correctly configured in both Okta and your application * Check that users are assigned to the appropriate groups with access to the application * Ensure the `alluxio` scope is properly created and associated with your authorization server * Confirm that the Issuer URL and Client ID in your configuration match the values in Okta ### Configuring Authorization The Management Console supports access control to restrict user permissions based on roles and responsibilities. Authorization can be configured to control which users can access specific features and perform certain operations within the system. For detailed instructions on setting up and managing authorization, please refer to the [User Roles & Access Control](https://documentation.alluxio.io/ee-ai-en/ai-3.7/administration/overview/user-roles-access-control) documentation.