• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

DataStax Enterprise 6.8 Security Guide

    • About DSE Advanced Security
    • Security FAQs
    • Security checklists
    • Securing the environment
      • Securing ports
      • Securing the TMP directory
    • Authentication and authorization
      • Configuring authentication and authorization
        • About DSE Unified Authentication
          • Steps for new deployment
          • Steps for production environments
        • Configuring security keyspaces
        • Setting up Kerberos
          • Kerberos guidelines
          • Enabling JCE Unlimited
            • Removing AES-256
          • Preparing DSE nodes for Kerberos
            • DNS and NTP
            • krb5.conf
            • Principal
            • Keytab
        • Enabling authentication and authorization
          • Defining a Kerberos scheme
          • Defining an LDAP scheme
        • Configuring JMX authentication
        • Configuring cache settings
        • Securing schema information
      • Managing database access
        • About RBAC
        • Setting up logins and users
          • Adding a superuser login
          • Adding database users
          • LDAP users and groups
            • LDAP logins
            • LDAP groups
          • Kerberos principal logins
          • Setting up roles for applications
          • Binding a role to an authentication scheme
        • Assigning permissions
          • Database object permissions
            • Data resources
            • Functions and aggregate resources
            • Search indexes
            • Roles
            • Proxy login and execute
            • Authentication schemes
            • DSE Utilities (MBeans)
            • Analytic applications
            • Remote procedure calls
          • Separation of duties
          • Keyspaces and tables
          • Row Level Access Control (RLAC)
          • Search index permissions
          • DataStax Graph keyspace
          • Spark application permissions
          • DataStax Studio permissions
          • Remote procedure calls
          • DSE client-tool spark
          • JMX MBean permissions
          • Deny (denylist) db object permission
          • Restricting access to data
      • Providing credentials from DSE tools
        • About clients
        • Internal and LDAP authentication
          • Command line
          • File
          • Environment variables
          • Using CQLSH
        • Kerberos
          • JAAS configuration file location
          • Keytab
          • Ticket Cache
          • Spark jobs
          • SSTableLoader
          • Graph and gremlin-console
          • dsetool
          • CQLSH
        • Nodetool
        • JConsole
    • Auditing database activity
      • Enabling database auditing
      • Capturing DSE Search HTTP requests
      • Log formats
      • View events from DSE audit table
    • Transparent data encryption
      • About Transparent Data Encryption
      • Configuring local encryption
        • Setting up local encryption keys
        • Encrypting configuration file properties
        • Encrypting system resources
        • Encrypting tables
        • Rekeying existing data
        • Using tools with TDE-encrypted SSTables
        • Troubleshooting encryption key errors
      • Configuring KMIP encryption
      • Encrypting Search indexes
        • Encrypting new Search indexes
        • Encrypting existing Search indexes
        • Tuning encrypted Search indexes
      • Migrating encrypted tables from earlier versions
      • Bulk loading data between TDE-enabled clusters
    • Configuring SSL
      • Steps for configuring SSL
      • Creating SSL certificates, keystores, and truststores
        • Remote keystore provider
        • Local keystore files
      • Securing node-to-node connections
      • Securing client-to-node connections
        • Configuring JMX on the server side
        • nodetool, nodesync, dsetool, and Advanced Replication
        • JConsole (JMX)
        • SSTableloader
        • Connecting to SSL-enabled nodes using cqlsh
      • Enabling SSL encryption for DSEFS
      • Reference: SSL instruction variables
    • Securing Spark connections
  • DataStax Enterprise 6.8 Security Guide
  • Authentication and authorization
  • Configuring authentication and authorization
  • Enabling authentication and authorization
  • Defining a Kerberos scheme

Defining a Kerberos Scheme

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

The following procedure describes how to add the Kerberos authenticator to cassandra.yaml and Kerberos options to dse.yaml.

Procedure

  1. Locate the cassandra.yaml configuration file. The location of this file depends on the type of installation:

    • Package installations: /etc/dse/cassandra/cassandra.yaml

    • Tarball installations: <installation_location>/resources/cassandra/conf/cassandra.yaml

  2. On each node, edit the cassandra.yaml file to set the authenticator to the DSE Authenticator.

    authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
  3. Set the native_transport_address 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
  4. Locate the dse.yaml configuration file. The location of this file depends on the type of installation:

    • Package installations: /etc/dse/dse.yaml

    • Tarball installations: <installation_location>/resources/dse/conf/dse.yaml

  5. On each node, edit the dse.yaml file:

    1. 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

      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

      auth_enabled

      Turns on authentication using the default scheme.

      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.

      other_schemes

      other_schemes

      scheme_permissions

      Validate that the role mapped to user matches the authentication scheme. Grant the role permission to the scheme.

      allow_digest_with_kerberos

      Allow Kerberos digest-md5 authentication.

      plain_text_without_ssl

      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.

      transitional_mode

      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.

    2. 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 Fully Qualified Domain Name (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 must be 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.

      Default: HTTP/_HOST@REALM

      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:

      • auth - Default: Authentication only.

      • auth-int - Authentication plus integrity protection for all transmitted data.

      • auth-conf - Authentication plus integrity protection and encryption of all transmitted data.

      Encryption using auth-conf is separate and independent of whether encryption is done using SSL. If both auth-conf and SSL are enabled, the transmitted data is encrypted twice. DataStax recommends choosing only one method and using it for both encryption and authentication.

  6. When adding a Kerberos scheme to an authentication enabled cluster, configure Kerberos roles before restarting DSE, see Setting up logins and users.

What is next

When initially configuring authentication, complete the set up by:

  • Performing a rolling restart.

  • Adding a superuser login.

Enabling authentication and authorization Defining an LDAP scheme

General Inquiries: +1 (650) 389-6000 info@datastax.com

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.

Kubernetes is the registered trademark of the Linux Foundation.

landing_page landingpage