Deployment
To enable the web based Management Console, make sure both the dashboard and gateway components are enabled in your operator configuration. This ensures that the Console is deployed properly within your Kubernetes cluster.
The Management Console is currently only supported for Kubernetes deployments. Bare metal deployments are not supported.
Example Configuration
Below is an example configuration for the Management Console to add to the existing Alluxio cluster configuration yaml file:
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
gateway:
enabled: true
image: <PRIVATE_REGISTRY>/alluxio-gateway
imageTag: AI-3.6-12.0.2
dashboard:
enabled: true
image: <PRIVATE_REGISTRY>/alluxio-dashboard
imageTag: AI-3.6-12.0.2
Accessing the Management Console
There are a few ways to access the console.
Accessing via Node Hostname
The Management Console will expose its service on port 80 on its host. Use kubectl to get the hostname:
kubectl -n alx-ns get pod $(kubectl -n alx-ns get pod -l app.kubernetes.io/component=dashboard --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 dashboard component.
Below is an example Service definition for exposing the dashboard via a Load Balancer:
apiVersion: v1
kind: Service
metadata:
name: load-balancer
namespace: alx-ns
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 80
selector:
app.kubernetes.io/instance: alluxio-dashboard
app.kubernetes.io/name: dashboard
Save the above as load-balancer.yaml
and create it via
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:
kubectl -n alx-ns get service load-balancer
Example output:
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.
Logging Into The Console
With the default authType
of simple
, the login page will only request for a username. As it is meant for testing use, no validation is performed and any username will be accepted.
For production use, the authentication type should be modified to authenticate with okta.
Advanced configuration
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/dashboard/audit-logs/dashboard-audit.log
inside the web console pod.
Configuration Example:
apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
dashboard:
enabled: true
image: <PRIVATE_REGISTRY>/alluxio-dashboard
imageTag: AI-3.6-12.0.2
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.
Prepare Certificate Files
Obtain a valid CA certificate file (typically named
ca.crt
)Prepare the Gateway certificate (
server.crt
) and private key (server.key
) filesEnsure the Gateway certificate is properly signed by the CA
Create a Kubernetes Secret
# 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
Configure Your Alluxio Cluster
apiVersion: k8s-operator.alluxio.com/v1 kind: AlluxioCluster spec: gateway: enabled: true image: <PRIVATE_REGISTRY>/alluxio-gateway imageTag: AI-3.6-12.0.2 tls: enabled: true secretName: gateway-k8s-secret-name certFile: server.crt certKeyFile: server.key dashboard: enabled: true image: <PRIVATE_REGISTRY>/alluxio-dashboard imageTag: AI-3.6-12.0.2 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 secretAll filenames (
caFile
,certFile
,certKeyFile
) must match the filenames used in the secretVerify 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
Log in to your Okta Admin Dashboard
Navigate to Applications > Applications
Click Create App Integration
Select the Single-Page Application (SPA) type
This application type utilizes the Authorization Code Flow with PKCE for secure client-side token acquisition
Complete the basic configuration with your application name and some options
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
andyour-port
with your actual domain and port valuesThese settings ensure proper redirection after Okta authentication completes
Save your application configuration
2. User Group Assignment and Authorization
To control access to the Management Console:
In your Okta Admin Dashboard, navigate to Directory > Groups
Create user groups if they don't already exist (e.g., "Admins")
Assign appropriate users to these groups
Return to your application settings
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:
In your Okta Admin Dashboard, navigate to Security > API
Select your authorization server (or create one if needed)
Go to the Scopes tab
Click Add Scope
Create a scope named
alluxio
with an appropriate descriptionThe Management Console requires both the
openid
scope (default in Okta) and this customalluxio
scopeIf 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 touserType
andgroupFieldName
is set todepartment
. Please visit User Roles & Access Control for more information.
4. Obtaining Configuration Values
After completing the setup, gather these values for your Management Console configuration:
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
)
Client ID:
Go to your application's settings
Copy the Client ID from the Client Credentials section
Update your Alluxio configuration with these values:
web: authType: okta oktaIssuer: https://your-okta-domain/oauth2/default oktaClientID: your-client-id-value
5. Login Process
When using Okta authentication:
Navigate to your Management Console URL
The login page will display a "Login with Okta" button
Click this button to be redirected to your organization's Okta authentication portal
Enter your Okta credentials and complete any multi-factor authentication if configured
Upon successful authentication, you will be redirected back to the Management Console's dashboard
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 serverConfirm 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 documentation.
Last updated