Configure DataStax Enterprise nodes to use Kerberos authentication.
Prerequisites
Completely set up Kerberos for DSE nodes before turning on Kerberos authentication.
When switching authentication methods, or enabling authentication for the first time
in a production environment, DataStax recommends setting up applications to use
Kerberos tickets before restricting access to only authenticated connections. When
DSE Authenticator is disabled, the credentials portion of the connection request is
ignored. Therefore, you can pass Kerberos tickets to DSE before implementing
authentication in the environment.
Change the replication strategy and default replication factor for the system_auth
and dse_security
keyspaces, see Configuring
system_auth keyspace replication
How to add the Kerberos authenticator to and
Kerberos options to .
dse.yaml
The location of the
dse.yaml file depends on the type of
installation:
Package installations |
/etc/dse/dse.yaml |
Tarball installations |
installation_location/resources/dse/conf/dse.yaml |
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 |
Procedure
-
On each node, edit the file to
set the authenticator to the DSE Authenticator.
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
-
Set the and
listen_address to
the IP address. Do not use localhost or the hostname.
native_transport_address: 100.200.182.1
listen_address: 100.200.182.1
-
On each node, edit the file:
-
Set Kerberos as default or other scheme in the authentication
options:
authentication_options:
enabled: false
default_scheme: kerberos
other_schemes:
- internal
scheme_permissions: true
allow_digest_with_kerberos: true
plain_text_without_ssl: warn
transitional_mode: disabled
Note: When initially enabling authentication, specify the internal
scheme as the default or other. After restarting DSE, to establish
roles requires using the internal default cassandra account.
Table 1. authentication_options
Option |
Description |
|
Turns on authentication using the default
scheme. |
|
Specifies the authentication scheme when not
defined in the connection:
- internal - Plain text
authentication using internal login role with
password, supply the role name and password as
credentials. No additional configuration
required.
- ldap - Plain text
authentication using pass-through LDAP
authentication. See Defining an LDAP scheme.
- kerberos - GSSAPI
authentication using the Kerberos authenticator.
See Defining a Kerberos scheme.
|
|
|
|
Validate that the role mapped to user matches the
authentication scheme. Grant the role permission to
the scheme. |
|
Allow Kerberos digest-md5 authentication. |
|
Handling of plain text connection requests:
- block - Block the request with an authentication error.
- warn - Log a warning but allow the request.
- allow - Allow the request without any warning.
|
|
Sets the behavior when authentication fails and
credentials are missing:
- disabled - Disable transitional mode. All connections must provide valid
credentials and map to a login-enabled role.
- permissive - Only super users are authenticated and logged in. All other
authentication attempts are logged in as the anonymous user.
- normal - Allow all connections that provide credentials. Maps all authenticated
users to their role, and maps all other connections to
anonymous .
- strict - Allow only authenticated connections that map to a login-enabled role
OR connections that provide a blank username and password as
anonymous .
|
-
Configure the Kerberos options.
The options are located in the kerberos_options
section.
Example:
kerberos_options:
keytab: /etc/dse/dse.keytab
service_principal: dse/_HOST@REALM
http_principal: HTTP/_HOST@REALM
qop: auth
Table 2. kerberos_options
Option |
Description |
keytab |
The keytab file must contain the credentials for
both of the fully resolved principal names, which
replace _HOST with the FQDN of the
host in the service_principal and
http_principal settings. The UNIX
user running DataStax Enterprise must also have read
permissions on the keytab. |
service_principal |
Sets the principals name for the DSE database and
DSE Search (Solr) processes. Use the form
dse/_HOST@REALM , where dse is the
service name. Leave
_HOST as is. This variable is
used in dse.yaml. DataStax
Enterprise automatically substitutes the FQDN of
the host where it runs. Credentials must exist for
this principal in the keytab file and readable by
the user that Cassandra runs as, usually
cassandra. The
service_principal must be
consistent everywhere:
- dse.yaml file
- keytab
- cqlshrc file (where it is
separated into the service/hostname)
|
http_principal |
Used by the Tomcat application container to run DSE Search. The Tomcat
web server uses the GSSAPI mechanism (SPNEGO) to negotiate the GSSAPI
security mechanism (Kerberos). REALM is the name of
your Kerberos realm. In the Kerberos principal, REALM
must be uppercase. |
qop |
A comma-delimited list of Quality of Protection
(QOP) values that clients and servers can use for
each connection. The client can have multiple QOP
values, while the server can have only a single QOP
value. The valid values are: |
-
When adding a Kerberos scheme to an authentication enabled cluster, configure
Kerberos roles before restarting DSE, see Setting up logins and users.
What's next
When initially configuring authentication complete the set up by: