Kong Ingress Controller DBless and oauth2 via Cassandra?

Kubernetes
1

We absolutely love the Kong Ingress Controller. Being able to configure Kong via Kubernetes resources makes our lives so much easier.

But we also leverage the oauth2 plugin, and historically have used Cassandra as our db backend.

I understand the latest version of the KIC no longer supports Cassandra. We’ve heavily invested in Cassandra for other needs, and have Cassandra clusters that span many datacenters. In other projects leveraging Kong (not the KIC), this has allowed us to perform DR moving customers from one data center to another without them having to request another oauth2 token - they don’t even notice (as Cassandra handles the replication of their oauth2 tokens to all our data centers)

To achieve the same level of availability and be able to leverage the KIC we could deploy postgreSQL, but we’d really like to not have to invest in another db technology given our current investments and expertise around Cassandra. Is it possible to run the KIC DB-less - and just have the oauth2 tokens stored in Cassandra? I’ve been reading up on the data and control plane features of Kong but it wasn’t clear to me if this is the direction we should be heading to achieve this or not.

2

In further reading of the docs around Hybrid mode it appears it, “uses declarative config as the config sync format which means it has the same limitations as declarative config as of today. Please refer to the Plugin Compatibility section of declarative config documentation for more information.” Which states that the oauth2 plugin is not compatible with declarative config. So much for Hybrid mode then.

Any other ideas or thoughts?

3

Is it possible to run the KIC DB-less - and just have the oauth2 tokens stored in Cassandra?

This isn’t possible, no, not with the way tokens are implemented currently. The oauth2 code declares datastore objects for them, and the underlying Kong code that handles that can’t support one datastore for some objects and another datastore for others.

If you’re interested in adding new code to the plugin, I’d look at adding Redis support for its tokens. That’s fairly standard for plugins that need to maintain runtime data, and why the rate limiting plugins are partially compatible with DB-less versus oauth2 being completely incompatible.