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.
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.
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.
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
DataStax Mission Control disables and does not use the default superuser,
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 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
password keys in the secret.
When JMX authentication is enabled, you must specify the
password options with
nodetool, as follows:
nodetool -u <username> -pw <password> status
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.