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:
-
DSE Unified Authorization. (DSE feature only).
-
Transparent Data Encryption (TDE) for DSE (DSE feature only).
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.
apiVersion: k8ssandra.io/betaV010 kind: MissionControlCluster metadata: name: cluster1 spec: auth: false ...
With authentication enabled, Mission Control configures a new, default superuser. The username defaults to metadata.name-superuser. From the example spec, the username is cluster1-superuser.
|
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
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.
nodetool
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.
