Cassandra Client-to-node encryption

Questions
1

Not sure if this is the right place for this or if Github would be better, but i figured i’ll start here…
We want to use Kong with an existing Cassandra cluster, our cluster is configured with mutual TLS encryption and require_client_auth: true meaning all clients connecting to the cluster must present a valid TLS certificate signed by a CA that C* trusts.
Looking at the C* options in the kong documentation it appears that only the following options are supported:
cassandra_ssl - Enable SSL connections to the nodes
cassandra_ssl_verify - If cassandra_ssl is enabled, toggle server certificate verification. See lua_ssl_trusted_certificate setting.
It doesn’t seem like there is any config option available to pass the client certificate and key to use…

I dug into it a bit further and looked at the code and it seems like Kong uses lua-cassandra for the C* client implementation. Looking through that package (sorry not a lua guy…) i see that the _Host.new (http://thibaultcha.github.io/lua-cassandra/modules/cassandra.html#_Host.new) function in the Cassandra module (http://thibaultcha.github.io/lua-cassandra/modules/cassandra.html) supports passing the additional parameters:
cert - Path to the client SSL certificate (LuaSec usage only).
key - Path to the client SSL key (LuaSec usage only)
In the client_options (http://thibaultcha.github.io/lua-cassandra/modules/cassandra.html#client_options)

However the _Cluster.new function (http://thibaultcha.github.io/lua-cassandra/modules/resty.cassandra.cluster.html#_Cluster.new) in the resty.cassandra.cluster module (http://thibaultcha.github.io/lua-cassandra/modules/resty.cassandra.cluster.html) does not seem to support these options in it’s cluster_options…

I wanted to ask if anyone knows why that is and more importantly does anyone know if there’s a way to make kong work with a C* cluster that enforces Client-to-node encryption?

Appreciate any help or comments.

2

Hi,

The lua-cassandra driver is built to be compatible with both plain Lua (using LuaSocket) and OpenResty (using the cosocket API). The name of the two modules offered by the driver reflects this: cassandra and resty.cassandra.cluster.

While LuaSocket has support for client certificates, OpenResty’s cosocket API does not, hence why those options are documented as “LuaSec usage only”, as you noted. There exist a pending PR for client certificate in OpenResty’s cosockets:

3

thanks for the reply @thibaultcha! So basically the way i interpret the response is currently this is not supported and may be at some point once that PR is merged and Kong upgrades it’s dependencies and adds support for these options…

4

Correct. Sorry if this is a disappointment, hope that clarifies things.

If this answers your question (I believe it does, however disappointing the answer may be…), would you please mark the answer as such? This is to make “solved/answered” topics easily browsable for the community, so that they can navigate the forum easily. Thank you!

5

Hello,

I am facing the same issue than @deanefrati, and for the moment the only option I see if I want to use kong with my existing cassandra cluster, is to disable require_client_auth in client encryption options which is quite blocking for us, according to our security requirements. I am a bit surprised that I didn’t find more issue opens about this.

@thibaultcha can you point me what we can do to help to add this feature to kong?

6

@nmeylan You are correct in your config settings as we have always gone with this, db traffic is still over TLS just not mutual tls which is what we settled on. Would be neat to see you implement for Kong though!

7

The blocker isn’t on Kong, but on OpenResty. You will notice the PR I linked to isn’t merged.

Testing the PR on your end, and eventually with Kong and Cassandra (which would require some extra work to use the PR to implement mTLS in the Cassandra driver) could be helpful, since we have the ability to ship a patched OpenResty release in our Kong release artifacts. At this moment, this isn’t a high priority item for us, but we will give it our attention in the future (no timeline so far).

8

Hello, thanks for you answers.
I have finally found a workaround to keep everything working without changing my Cassandra configuration (keeping require_client_auth=true in client encryption options).
I have put haproxy between kong and cassandra, which gives something like this: kong <--1 way tls -->haproxy<-- 2 way tls--> cassandra (haproxy is configured to be only accessible by kong, and cannot be accessed from external).
While this is not the perfect solution, it works and is quite easy to deploy.

I’ve spent time to read the OpenResty pull request, however I don’t have enough knowledge to verify that the ssl part is correctly implemented, thus even if I make this pull request works, it still would not be safe to ship it in Kong. So, I think I won’t investigate further.

Thanks for your work on Kong.