Configure Authentication

DataStax Mission Control is currently in Public Preview. DataStax Mission Control is not intended for production use, has not been certified for production workloads, and might contain bugs and other functional issues. There is no guarantee that DataStax Mission Control will ever become generally available. DataStax Mission Control is provided on an “AS IS” basis, without warranty or indemnity of any kind.

If you are interested in trying out DataStax Mission Control please join the Public Preview.

What is authentication?

Authentication is the act of validating that a user is who they claim to be. Two methods of authentication are common:

Passwords: Usernames and passwords are the most common authentication factors. If a user enters the correct data, the system assumes the identity is valid and grants access.

Enabling authentication

DataStax Mission Control enables authentication by default.

Keep authentication enabled. Turning on authentication for an existing cluster is not a trivial task and it may involve downtime.

The enabling option is set in the MissionControlCluster YAML specification file. In its spec section, the auth option is set to true by default. While it can be toggled to false, that is not recommended.

apiVersion: k8ssandra.io/betaV010
kind: MissionControlCluster
metadata:
  name: cluster1
spec:
  auth: false
  ...

With authentication enabled, DataStax Mission Control configures a new, default superuser. The username defaults to metadata.name-superuser. From the example spec, the username is cluster1-superuser.

DataStax Mission Control disables and does not use the default superuser, cassandra.

The password is a random alphanumeric string that is 20 characters long.

You can override the default username and password by setting the spec.cassandra.superuserSecretRef property to an existing secret containing both the username and the password.

Credentials are stored in a secret named metadata.name-superuser. If your cluster name is cluster1, for example, retrieve the username and password as follows:

kubectl get secret cluster1-superuser -o json | jq -r '.data.username' | base64 --decode

kubectl get secret cluster1-superuser -o json | jq -r '.data.password' | base64 --decode

Kubernetes Secrets

Kubernetes secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image. You can use the secrets generated by DataStax Mission Control components, or create your own secrets. Be consistent in your handling of secrets to avoid confusion. Either manage all by yourself, or let all of them be created by DataStax Mission Control.

DataStax Mission Control uses secrets to store super-user credentials. For every set of credentials, DataStax Mission Control supplies a default username and a default password. DataStax Mission Control generates a random, alphanumeric string 20 characters long for the password. These values are stored under the username and password keys in the secret.

nodetool

When JMX authentication is enabled, you must specify the username and password options with nodetool, as follows:

nodetool -u <username> -pw <password> status

DataStax Mission Control User Interface (UI) access

The DataStax Mission Control UI uses LDAP or OIDC connectors for authentication through a Backend For Frontend (BFF) pattern. The REST API shares the authentication state with the UI through an encrypted session cookie. The REST API proxies the credentials provided by the client on the UI login and consent windows to the configured authentication connector. Upon verification, The REST API loads and returns data to the client browser.