Native transport authentication schemes and limitations in LCM
Details about supported and unsupported authentication schemes and configurations when using LCM.
cassandra.yaml
The location of the cassandra.yaml file depends on the type of installation:Package installations | /etc/dse/cassandra/cassandra.yaml |
Tarball installations | installation_location/resources/cassandra/conf/cassandra.yaml |
Lifecycle Manager (LCM) authentication options are set in the dse.yaml and cassandra.yaml files in LCM Config Profiles.
LCM requires internal
as the default scheme in dse.yaml
when used in conjunction with DSE Authenticator in
cassandra.yaml.
LCM-compatible authentication schemes
To monitor the cluster and perform ongoing management activities, OpsCenter must be able to issue CQL queries against the cluster. LCM automatically configures the required access and is compatible with the following authentication scenarios:
internal
scheme is not set as the primary scheme, then LCM install jobs
fail when attempting to change the password for the internal cassandra
user built-in to the internal authentication scheme. As a result, LCM fails to register
the cluster with OpsCenter.Internal authentication only
Internal authentication only is the default authentication scheme for LCM. This
scheme uses the cassandra
username with a default password of
cassandra. LCM requires that you change this password in the
Edit Cluster dialog.
The Edit Cluster
dialog prompts for the information necessary to change the default password of the
cassandra
username that is built into the internal authentication
scheme. LCM sets the password for this user as specified, and configures OpsCenter to use
the password when accessing the cluster.
Internal authentication with LDAP or Kerberos
Internal authentication in LCM can be configured as the primary scheme
(default_scheme
), with LDAP or Kerberos (or both) as optional schemes
(other_schemes
).
Adding LDAP or Kerberos as other_schemes
in
dse.yaml is allowed, but LCM and OpsCenter ignore the additional
schemes and use the internal cassandra
username, as described in the
internal authentication only
scheme.
This scenario is useful when client applications using DSE for data storage must have
accounts managed through a centralized Kerberos or LDAP service. OpsCenter will use the
internal cassandra
username to ensure that DSE management operations can
be completed, even if access to the Kerberos or LDAP service is disrupted or
unavailable.
When authentication is enabled in a configuration profile, LCM prompts for credentials after the profile is selected in the Edit Cluster dialog. See Editing a Cluster for more information.
Authentication disabled
Running DSE with authentication disabled is not recommended without appropriate network access controls in place. However, LCM supports configuring OpsCenter to access a DSE cluster that has authentication disabled.
To disable authentication, uncheck the enabled checkbox under authentication_options in dse.yaml. In cassandra.yaml, select DseAuthenticator as the authenticator, which is a flexible option that is recommended in all use cases.
You can also disable authentication by selecting the AllowAllAuthenticator authenticator option in cassandra.yaml, but the DseAuthenticator option is preferred.
Unsupported authentication scenarios
- LDAP authentication in cassandra.yaml instead of DSE authentication, and DSE authentication with LDAP as the default scheme.
- Kerberos in cassandra.yaml instead of DSE authentication, and DSE authentication with Kerberos as the default scheme.
See the authenticator option for details.