Managing DSE Security using LCM

Authentication for DataStax Enterprise clusters is enabled by default in a Lifecycle Manager configuration profile.

Authentication

Authentication for DataStax Enterprise clusters is enabled by default in a Lifecycle Manager configuration profile. Configuration profiles created for supported DSE versions earlier than DSE version 5.0 enable the PasswordAuthenticator option by default. Configuration profiles created for DSE version 5.0 and later use the DSE Authenticator by default:

The following links provide more information about the available security options in cassandra.yaml:

Node-to-Node Encryption

Lifecycle Manager can configure DataStax Enterprise clusters to use node-to-node encryption. The feature is disabled by default. See Configuring SSL/TLS for DSE using LCM for step-by-step instructions for enabling internode encryption using LCM Config Profiles.

When internode_encryption is enabled (by selecting a value of all, dc, or rack in the Security panel of cassandra.yaml in Config Profile), Lifecycle Manager automates the process of setting up SSL certificates using an internal certificate authority and deploys the resulting keystore and truststore to each node automatically. No further action is necessary beyond running an install or configure job.

Important: When enabling node-to-node encryption on an existing cluster, the cluster will experience a network partition during the transition, leading to temporary loss of consistency. If possible, choose whether to employ node-to-node encryption when first creating the cluster.

Client-to-Node Encryption

Lifecycle Manager can configure DataStax Enterprise clusters to use client-to-node encryption. The option is disabled by default. See Configuring SSL/TLS for DSE using LCM for step-by-step instructions for enabling client encryption using LCM Config Profiles.

When client-to-node encryption is enabled (by selecting enabled for client_encryption_options in the Security panel of cassandra.yaml in Config Profile), Lifecycle Manager automates the process of preparing server certificates, exactly as it does for node-to-node encryption.

Some organizations might not want to use the internal certificate authority in Lifecycle Manager, and can manually deploy the keystore and truststore as described for node-to-node encryption.

Before drivers, cqlsh, and other CQL clients can connect to a cluster with client-to-node encryption enabled, they typically must be configured to trust the appropriate certificates. The process is different for each CQL client and Lifecycle Manager does not automatically configure CQL clients. After enabling client-to-node encryption, configure your CQL clients to use the appropriate certificates.
Note: Enabling require_client_auth for client_encryption_options requires special steps due to an LCM limitation. For more information, refer to the Knowledge Base Article.

Internal Certificate Authority generated by LCM

The process of manually preparing certificates and deploying them can be a barrier to the adoption of security features. To simplify deployments, Lifecycle Manager optionally generates certificates using an internal certificate authority.
  • When Lifecycle Manager is first started, it creates a self-signed 2048 bit RSA certificate authority that is stored in the [lifecycle_manager].cacerts_directory in opscenterd.conf.
  • When running install or configure jobs, Lifecycle Manager generates a keystore and truststore for each node if necessary. Certificate generation occurs if either node-to-node or client-to-node encryption is enabled, and if there is no pre-existing keystore or truststore in the locations specified by the configuration profile.
  • When generating a keystore for each node, Lifecycle Manager creates a certificate signing request for the node, signs the request with the internal certificate authority, and packages the resulting certificate in a JKS-formatted keystore.
  • When generating a truststore for each node, Lifecycle Manager packages the CA certificate in a JKS-formatted truststore. The same CA is used to sign certificates for all nodes in all clusters, and it enables validation of all automatically generated certificates.

Using non-LCM generated certificates

Some organizations might want to generate certificates for DataStax Enterprise servers using a commercial or enterprise certificate authority external to LifeCycle Manager:
  1. Prior to running an install or configure job, prepare keystores and truststores for each node outside of Lifecycle Manager.
  2. Deploy the appropriate keystore and truststore to each DataStax Enterprise server using scp, rsync, or some other method of file deployment. The keystore files are commonly deployed to the /etc/dse/keystores/ directory.
  3. Edit the config profile in Lifecycle Manager so that the keystore and truststore paths point to the location where the files were deployed as mentioned above; for example /etc/dse/keystores/server.keystore and /etc/dse/keystores/server.truststore.
  4. Edit the config profile in Lifecycle Manager so that the keystore and truststore passwords allow DataStax Enterprise to unlock the files that were manually deployed.
  5. Run an install or configure job. When executing the job, Lifecycle Manager configures each DataStax Enterprise server to use the pre-deployed keystore and truststore you have provided. Lifecycle Manager does not attempt to prepare certificates using the internal certificate authority when it finds a pre-existing keystore and truststore present on a DataStax Enterprise server.

opscenterd.conf

The location of the opscenterd.conf file depends on the type of installation:

  • Package installations: /etc/opscenter/opscenterd.conf
  • Tarball installations: install_location/conf/opscenterd.conf