Skip to content
Browse files
February 2022 blog "Tightening Security for Apache Cassandra Part: 3"
patch by Maulin Vasavada, Diogenese Topper; reviewed by Erick Ramirez for

Add blog post titled "Tightening Security for Apache Cassandra Part: 3"
update blog index
add 2 images for blog: "Cassandra-SslContextFactory.png" and "tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg"
  • Loading branch information
dtopdontstop authored and blerer committed Feb 16, 2022
1 parent bb42048 commit fbb538356c533feba1847fb5c51fe64c58907918
Showing 4 changed files with 121 additions and 0 deletions.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
- Replace post tile, date, description and link to you post.

//start card
[openblock,card shadow relative test]
=== Tightening Security for Apache Cassandra: Part 3
==== February 14, 2022
In Part 3 of Maulin Vasavada’s mini-series on improving security, we detail how Cassandra 4.0 delivers ways to customize mTLS/TLS configuration while retaining the hot-reload functionality.

[openblock,card-btn card-btn--blog]
xref:blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc[Read More]

//end card

//start card
[openblock,card shadow relative test]
@@ -0,0 +1,97 @@
= Tightening security for Apache Cassandra: Part 3
:page-layout: single-post
:page-role: blog-post
:page-post-date: February, 14 2022
:page-post-author: Maulin Vasavada
:description: The Apache Cassandra Community


.Image credit:[Jennefer Zacarias^]

In xref:blog/Tightening-Security-for-Apache-Cassandra-Part-2.adoc[Part-2] of this series, we explored avenues for securing data in transit and described how to configure TLS/mTLS with Apache Cassandra 4.0. In Part 3, we’ll look at how you can customize TLS/mTLS for Apache Cassandra 4.0+ to overcome the challenges with a TLS configuration.

=== How We Made TLS Configuration Better With 4.0

With Apache Cassandra 4.0,[we enhanced^] the TLS/mTLS configuration to allow for specifying custom ways to build SSLContext and we provided a default implementation for backward compatibility. We introduced a new configuration, `ssl_context_factory`, where you can specify your custom class to build SSLContext objects required by Java/Netty SSL libraries. You can also add custom properties to it via simple key-value pairs. All of this has been achieved while retaining the ability to hot-reload the security credentials as you could before version 4.0.

To demonstrate this customization, let’s use the example of Kubernetes, the popular cloud-native solution. Kubernetes allows configuring[Secrets^] to store sensitive data. We could potentially use K8s Secrets to store the keystore and truststore artifacts along with their respective passwords. We will assume Apache Cassandra is already running in a K8s environment.

=== Integration with Kubernetes Secrets

We have passwords for keystore and truststore as K8s environment variables loaded from the K8s Secrets. The keystore and truststore files are loaded by the K8s Secrets. The YAML file, below, for the pod reflects these settings. This example also keeps the hot-reloading capability of security credentials by allowing the secret named `keystore/truststore-last-updatedtime`. You can update the timestamp value for those secrets via a `kubectl` command and the implementation will hot-reload the security credentials as it would filesystem-based security credentials.

==== Example K8s Pod Configuration

apiVersion: v1
kind: Pod
name: my-cassandra-pod
app: my-cassandra-app
- name: my-cassandra-app
image: my-cassandrda-app:latest
imagePullPolicy: Always
name: my-ssl-store
key: keystore-password
name: my-ssl-store
key: truststore-password
- name: my-ssl-store
mountPath: "/etc/my-ssl-store"
readOnly: true
- name: my-ssl-store
secretName: my-ssl-store
- key: cassandra_ssl_keystore
path: keystore
- key: keystore-last-updatedtime
path: keystore-last-updatedtime
- key: cassandra_ssl_truststore
path: truststore
- key: truststore-last-updatedtime
path: truststore-last-updatedtime

We will use the[‘KubernetesSecretsSslContextFactory’^] class from Apache Cassandra 4.0 as an example for how to customize the TLS configuration via Kubernetes Secrets as loaded by the pod definition (above).

==== Example Custom TLS Configuration for K8s Secrets

Here we have used the configuration for `server_encryption_options`, but, similarly, you can use it for the `client_encryption_options`:

internode_encryption: none
class_name: `
KEYSTORE_UPDATED_TIMESTAMP_PATH: /etc/my-ssl-store/keystore-last-updatedtime
TRUSTSTORE_UPDATED_TIMESTAMP_PATH: /etc/my-ssl-store/truststore-last-updatedtime
keystore: /etc/my-ssl-store/keystore
truststore: /etc/my-ssl-store/truststore

And Voila! Congratulations, your Apache Cassandra server is now integrated with the Kubernetes Secrets for the TLS configuration. The example above is built on the extensible class hierarchy shown, below. You can build extensions at three different levels and use composition to offer hybrid solutions you might need.

image::blog/Cassandra-SslContextFactory.png[A diagram of Apache Cassandra’s extensible class hierarchy]

=== Future work
On top of having the ability to customize TLS configuration, the community is[working on^] supporting other popular formats for security credentials, such as[PEM^] (originally “**P**rivacy **E**nhanced **M**ail”).

As the Apache Cassandra community, our goal is to provide best-in-class software and keep enhancing it as the use-cases and requirements grow and evolve over time. I hope this particular enhancement makes Cassandra operators’ life easier while supporting industry standards for data security.

0 comments on commit fbb5383

Please sign in to comment.