Configure authentication

What is authentication?

Authentication is the act of validating that a user is who they claim to be. 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.

Authentication protocols are an important part of database security. Mission Control supports several authentication and encryption features for DSE or Apache Cassandra® databases:

Enabling authentication

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.

kind: MissionControlCluster
  name: cluster1
  auth: false

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

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 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 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 Mission Control.

Mission Control uses secrets to store super-user credentials. For every set of credentials, Mission Control supplies a default username and a default password. 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.


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

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

Mission Control User Interface (UI) access

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

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000,