There exists a Cassandra TCP Connector with username and password based authentication

[BradleyBoutcher]

Overview

There exists a TCP connector for Apache Cassandra in secretless-broker

We are using gocql as a third party library to assist in implementing the underlying cassandra protocol.

Connected to #1242

Definition of done

• [ ] There is a docker-compose environment that stands up cassandra and secretless for validating flows

• [ ] There is an initial e2e implementation of a cassandra connector that can take a client request with no or bad credentials, get valid creds from the secretless config, negotiate the user/password authn with the cassandra server, and return the authenticated connection to the client to make subsequent privileged queries

• [ ] There is a README with minimal information about how to run the initial flow and what we validated it with, so that other people can also try this initial POC connector

Currently Supported Actions

• Creating a docker environment for testing by running the start script in the Cassandra integration test directory
• Creating a connection, queries, and passing certain flags using the cqlsh command line tool. Not all flags have been tested, but -u and -p currently work properly.

Example

When we run cqlsh localhost 2223 --debug --connect-timeout="1000000" -u "cassandra" -p "cassandra", we successfully connect to the cassandra node through secretless as the user cassandra

Additional Information

• Cassandra relies on a cassandra.yml file for configuration before creating the node. According to their docs, it seems they discourage configuring your node after creation. Currently I am uncertain as to how we can inject this yml file into a docker-compose script, but we may need to make a custom Dockerfile.

• Authentication needs to be configured in advance, including username and password based authentication. We can create a cassandra.yml using information found here

• gocql uses a custom struct, Conn, as a wrapper for a network connection. This can be used to expand support for features such as username and password based authentication and handling the underlying protocols

• Cassandra makes use of authenticators for handling username and password based authenticators. These are defined when the cassandra node is created, and are implemented in gocql to decorate our cluster configuration before performing our call to connect. More info can be found here

Known issues

• Secretless broker creates a single connection when communicating with cqlsh. Currently, two connections are created for unknown reasons.

• Disconnecting from a node and attempting to re-connect can result in an error where we attempt to send a STARTUP packet again, and the node has already received this packet from a previous connection. It then rejects the connection.

[izgeri]

@BradleyBoutcher can you add the cassandra.yml as a volume mount to the cassandra container (if you define it locally in your test dir)?

Does the cassandra.yml file include the authentication configuration info for the cassandra instance, eg to use username-password auth and/or set the username/password?

Can you run the test with secretless configured to set username cassandra, but with the client invoked as cqlsh localhost {secretless port for cassandra connector} --debug --connect-timeout="1000000" -u "not-cassandra" -p "badpassword" - and still make the connection?

[izgeri]

I'd like to see the definition of done be:

• there is a docker-compose environment that stands up cassandra and secretless for validating flows
• there is an initial e2e implementation of a cassandra connector that can take a client request with no or bad credentials, get valid creds from the secretless config, negotiate the user/password authn with the cassandra server, and return the authenticated connection to the client to make subsequent privileged queries
• there is a README with minimal information about how to run the initial flow and what we validated it with, so that other people can also try this initial POC connector

[BradleyBoutcher]

@izgeri

• Cassandra doesn't automatically search for the configuration file, so we'd need to find some way to pass the file in still. That may require modifying the entrypoint for the container, as their docs don't provide any information on the subject outside of this example: docker run ... cassandra -Dcassandra.config=/path/to/cassandra.yaml

• I'm not sure how extensively the cassandra.yml file is used at the moment, but so far it looks like a means of defining what authenticators the node supports, what encryption the node supports, and other parameters of the same nature. I haven't been able to find any information on creating usernames or passwords in advance, but do know that the default account is cassandra with the same password.

Can you run the test with secretless configured to set username cassandra, but with the client invoked as cqlsh localhost {secretless port for cassandra connector} --debug --connect-timeout="1000000" -u "not-cassandra" -p "badpassword" - and still make the connection?

Currently, no. That will be the primary objective of this spike, as we currently cannot inject credentials through secretless yet.

[izgeri]

Thanks! That helps me understand where it's at. So Secretless can proxy right now, but it's not "secretless" yet :)