Apache Cassandra authentication is highly extensible. Users can create plugins to add authentication methods such as Kerberos, SigV4, and SAML to connect with their servers.
Unfortunately, this support was not universally applied. The CQL shell (CQLSH), the basic tool for interacting with the Cassandra system, did not tap into this mechanism. This forced users to try to create their own tool to interact with a Cassandra DB.
In Cassandra 4.1, we added support for authentication plugins in CASSANDRA-16456, letting you use any Python authentication mechanism with the CQL shell.
Each plugin is a library installed in the Python module path. Usually, the easiest way to install it is by using pip. For example, to install the sigv4 version:
$ pip install cassandra-sigv4
Each authentication plugin contains a Python class meant to be used in client code. These classes have a constructor which takes in named parameters. Here’s a simple example for PlainTextAuthProvider:
class PlainTextAuthProvider(AuthProvider): """ An :class:`~.AuthProvider` that works with Cassandra's PasswordAuthenticator. Example usage:: from cassandra.cluster import Cluster from cassandra.auth import PlainTextAuthProvider auth_provider = PlainTextAuthProvider(username='cassandra', password='cassandra') cluster = Cluster(auth_provider=auth_provider) """ def __init__(self, username, password): self.username = username self.password = password def new_authenticator(self, host): return PlainTextAuthenticator(self.username, self.password)
To use this with CQLSH, we need to simply add an auth_provider section to the cqlshrc file (which defaults to
The auth_provider section details a
module which is the path to the class and a
classname. So if we have
mycassandra.auth.foo.BarAuthProvider we would tell CQLSH to use it by specifying it like this in
[auth_provider] module = mycassandra.auth.foo class = BarAuthProvider
To specify non-secret properties, we can simply add the names in the same section. So if
BarAuthProvider has a constructor that is passed a parameter called
property1, we could specify it by adding
property1 directly in cqlshrc:
[auth_provider] module = mycassandra.auth.foo class = BarAuthProvider property1 = value
Authentication often involves using secret properties. To make sure these don’t fall into the wrong hands, CQLSH uses a file called credentials (
You can use this file to pass secret properties to an auth provider. To do this, create a section in the credentials file with the classname, then add the parameters as values.
Let’s suppose that
secret_property2 in its constructor. We can safely specify it by using the following credentials file:
[BarAuthProvider] secret_property2 = secret1
For a simple working example, let’s use the plugin mechanism with PlainTextAuthProvider, a provider already included with CQLSH. Suppose my
user1, and my
pass1. I could configure CQLSH to use this by creating a CQLSHRC file with:
[auth_provider] module = cassandra.auth classname = PlainTextAuthProvider
To make sure that my secret is secure, I would create a credentials file (that only the owner could read) in
~/.cassandra/credentials and specify my two secrets:
[PlainTextAuthProvider] username = user1 password = pass1
If you execute cqlsh it will automatically pick up the secret and authentication method. In my case:
$ cqlsh [cqlsh 6.1.0 | Cassandra 4.1-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5] Use HELP for help. user1@cqlsh >
Stay tuned for upcoming further security enhancements, such as CASSANDRA-17501.