K8SSAND-1841 ⁃ Stargate client-to-node encryption allows unencrypted connections

[adejanovski]

It seems like enabling client to node encryption in k8ssandra-operator, and despite the encryption settings being passed to Stargate, it is still possible to use cqlsh without any encryption setting to connect to the Stargate service. The Cassandra service refuses similar connection attempts in this case.

This can be easily reproduced with the encryption with Stargate manifest we use for e2e test: test/testdata/fixtures/single-dc-encryption-stargate/k8ssandra.yaml

It requires to install first the following manifests to get the encryption stores:

• test/testdata/fixtures/server-encryption-secret.yaml
• test/testdata/fixtures/client-encryption-secret.yaml

Then ssh into one of the Cassandra pods and try both:

cqlsh --username test-superuser --password <superuser password> test-dc1-service
and
cqlsh --username test-superuser --password <superuser password> test-dc1-stargate-service

The former will fail but the latter will succeed.

┆Issue is synchronized with this Jira Task by Unito
┆friendlyId: K8SSAND-1841
┆priority: Medium

[olim7t]

Stargate CQL uses a separate configuration file: provided with -Dstargate.cql.config_path, sample contents here. I'll look at generating and mounting it.

For reference, this was introduced in stargate/stargate#1992.

[adejanovski]

oooooh, I see.
Thanks for taking care of that 🙏

[olim7t]

Useful info from the discussions on #721:

We are only copying the server_encryption_options and client_encryption_options properties from Cassandra [to the Stargate config map] when they are set.

What Stargate CQL needs is client_encryption_options. So we can actually omit them from cassandra.yaml, and copy them to the new file instead.

Note: reusing cassandra.yaml for both would also probably work, but having two separate files is a bit cleaner IMO.