Home

Deployment

When deploying the Operator, append a new section for console as shown below.

global:
  image: <PRIVATE_REGISTRY>/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.

Configuration example with Okta enabled:

global:
  image: <PRIVATE_REGISTRY>/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:

kubectl get pods -n alluxio-operator

Example output:

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.

global:
  image: <PRIVATE_REGISTRY>/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:

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:

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

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

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:

apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
  console:
    enabled: true
    image: <PRIVATE_REGISTRY>/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

    # 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

    apiVersion: k8s-operator.alluxio.com/v1
kind: AlluxioCluster
spec:
  gateway:
    enabled: true
    image: <PRIVATE_REGISTRY>/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: <PRIVATE_REGISTRY>/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

  1. Complete the basic configuration with your application name and some options

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

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

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

Last updated