Configure Authentication

DataStax Mission Control is current in Private Preview. It is subject to the beta agreement executed between you and DataStax. 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 contact your DataStax account team.

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.
Authentication apps: Generate security codes via an outside party that grants access.

Enabling authentication

K8ssandra enables authentication by default. It uses the Cassandra default PasswordAuthenticator and C`assandraAuthorizer` functionality.

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 K8ssandraCluster 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: K8ssandraCluster
metadata:
  name: cluster1
spec:
  auth: false
  ...

With authentication enabled, K8ssandra configures a new, default superuser. The username defaults to {metadata.name}-superuser. From the example spec, the username is metadata.cluster1-superuser.

K8ssandra 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, you can 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 K8ssandra components, or create your own secrets. It is recommended that you do only one or the other to be consistent in the handling of secrets.

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

Like other objects installed as part of the Helm release, secrets are deleted when you run helm uninstall.

Cassandra default superuser

K8ssandra creates JMX credentials for the default superuser. The username and password are the same as those for Cassandra.

If you change the Cassandra superuser credentials through cqlsh, for example, the JMX credentials are not updated to the new values.

nodetool

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

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