Cassandra

Set the Server and Database connection properties to connect to Cassandra.

To connect to a distributed system, you can set Server to a comma-separated list of servers and ports, separated by colons. You will also need to set ConsistencyLevel.

The following sections detail connection properties for authentication, security, and data access.

1 Connecting to CosmosDB with the Cassandra API

To obtain the connection string needed to connect to a Cosmos DB account using the Cassandra API, log in to the Azure Portal, select Azure Cosmos DB, and select your account. In the Settings section, click Connection String and set the following values.

  • Server: Set this to the Host value, the FQDN of the server provisioned for your account. You can also specify the port here or in Port.

  • Port: Set this to the port.

  • Database: Set this to the database you want to read from and write to.

  • User: The Cosmos DB account name.

  • Password: The account key associated with the Cosmos DB account.

  • UseSSL: Set to True

You can use the following properties to gain greater control over Cassandra API features and the strategies the provider uses to surface them:

  • AllowFiltering: Set this property to allow the server to process slow-performing searches.

  • UseJsonFormat: Set this property to use CQL literals instead of JSON.

  • QueryPassthrough: This property enables you to use native CQL statements instead of SQL.

  • RowScanDepth: This property determines the number of rows that will be scanned to detect column data types when generating table metadata.

This property applies if you are working with the dynamic schemas generated from Automatic Schema Discovery or if you are using QueryPassthrough.

2 Securing Cassandra Connections

You can set UseSSL to negotiate SSL/TLS encryption when you connect. By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.

3 Authenticating to Cassandra

The provider supports Basic authentication with login credentials and the additional authentication features of DataStax Enterprise (DSE) Cassandra. The following sections detail connection properties your authentication method may require.

You need to set AuthScheme to the value corresponding to the authenticator configured for your system. You specify the authenticator in the authenticator property in the cassandra.yaml file. This file is typically found in /etc/dse/cassandra. or through the DSE Unified Authenticator on DSE Cassandra.

3.1 Basic Authentication

Basic authentication is supported through Cassandra's built-in default PasswordAuthenticator.

  • Set the AuthScheme property to 'BASIC' and set the User and Password properties.

  • In the cassandra.yaml file, set the authenticator property to 'PasswordAuthenticator'.

3.2 Kerberos Authentication

Kerberos authentication is supported through DataStax Enterprise Unified Authentication.

  • Set the AuthScheme property to 'KERBEROS' and set the User and Password properties.

  • Set the KerberosKDC, KerberosRealm, and KerberosSPN properties.

  • In the cassandra.yaml file, set the authenticator property to "com.datastax.bdp.cassandra.auth.DseAuthenticator".

  • Modify the authentication_options section in the dse.yaml file, specifying the default_schema and other_schemas properties as 'kerberos'.

  • Modify the kerberos_options section in the dse.yaml file, specifying the keytab, service_principle, http_principle and qop properties

To authenticate to Cassandra using Kerberos, set the following properties:

  • AuthScheme: Set this to KERBEROS

  • KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.

  • KerberosSPN: Set this to the service and host of the Cassandra Kerberos Principal. This will be the value prior to the '@' symbol (for instance, hbase/MyHost) of the principal value (for instance, hbase/MyHost@EXAMPLE.COM).

You can use one of the following options to retrieve the required Kerberos ticket.

3.2.1 MIT Kerberos Credential Cache File

This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you won't need to set the User or Password connection properties with this option.

  1. Ensure that you have an environment variable created called KRB5CCNAME.

  2. Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file will be created when generating your ticket with MIT Kerberos Ticket Manager.

  3. To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.

  4. Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Cassandra.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider will use the specified cache file to obtain the kerberos ticket to connect to Cassandra.

3.2.2 Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.

3.2.3 User and Password

If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a User and Password combination. To do this, set the User and Password properties to the user/password combo that you use to authenticate with Cassandra.

3.2.4 Cross-Realm Authentication

More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g. where one realm/KDC is used for user authentication and another realm/KDC used for obtaining the service ticket).

In such an environment, the KerberosRealm and KerberosKDC properties can be set to the values required for user authentication. The KerberosServiceRealm and KerberosServiceKDC properties can be set to the values required to obtain the service ticket.

3.3 LDAP Authentication

LDAP authentication is supported through DataStax Enterprise Unified Authentication.

  • Set the AuthScheme property to 'LDAP' and set the User and Password properties.

  • In the cassandra.yaml file, set the authenticator property to "com.datastax.bdp.cassandra.auth.DseAuthenticator".

  • Modify the authentication_options section in the dse.yaml file, specifying the default_schema and other_schemas properties as 'ldap'.

  • Modify the ldap_options section in the dse.yaml file, specifying the server_host, server_port, search_dn, search_password, user_search_base, and user_search_filter properties

3.4 Using PKI

You can specify a client certificate to authenticate the provider with SSLClientCert, SSLClientCertType, SSLClientCertSubject, and SSLClientCertPassword.

The following are the connection properties for Cassandra. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Last updated