KeyAuth plugin on a Cassandra DB

jgrammen-agilitypr · December 6, 2018, 8:55pm

I am curious about how the key-auth plugin works, specifically when used with a cassandra backing db.

Kong/kong/blob/master/kong/plugins/key-auth/daos.lua

local utils = require "kong.tools.utils"

local SCHEMA = {
  primary_key = {"id"},
  table = "keyauth_credentials",
  cache_key = { "key" },
  fields = {
    id = {type = "id", dao_insert_value = true},
    created_at = {type = "timestamp", immutable = true, dao_insert_value = true},
    consumer_id = {type = "id", required = true, foreign = "consumers:id"},
    key = {type = "string", required = false, unique = true, default = utils.random_string}
  },
}

return {keyauth_credentials = SCHEMA}

it appears that the keys is set to unique but how is the uniqueness enforced?
I am asking because it seems that this uniqueness would force a full table scan in cassandra, how else would kong know if the key is unique or not.

If the contraint is forcing full table scans should the key field not be an index?

hbagdi · December 7, 2018, 5:23pm

The key field is indexed if that’s what you mean.
https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/migrations/cassandra.lua#L15

jgrammen-agilitypr · December 7, 2018, 9:08pm

I see that you pointed out that there is an index, but even with the index you cannot search (WHERE clause) based on the field. So how is the uniqueness enforced? could cassandra no need to run a search on the table to see if that key has been previously used?

hbagdi · December 19, 2018, 5:02am

I’m not sure but I think Kong uses a query with a where clause to enforce uniqueness. This is handled transparently by the DAO layer in Kong.

jgrammen-agilitypr · December 19, 2018, 1:06pm

thank you for the reply.

If i am reading the code you linked to correctly, kong is walking through all the rows in the returned set and checking if the key exists. If this assumption is correct, then my original statement is also correct, kong is doing a full table scan (or rather walking through all the rows). This seems like a very bad idea, for a table that would be added to frequently, because as the number of rows grows the query would take longer and longer.

hbagdi · December 19, 2018, 6:48pm

AFAIK, we try to avoid reads before writes as much as possible. Kong used to that a lot more before and with the new DAO, such harmful patterns can now be found in much fewer places.

@thibaultcha or @hisham can comment on this better.