Separation of concern for database administrators (Cassandra) during Kong migration process

[pamiel]

Kong migration process assumes that the Cassandra Database administrator running the Kong migration up command has the full privileges on the DB.

However, for separation of concerns in Production, it often happens that several actors are involved into a system deployment:

• A DBA (Database Administrator) first: holding the keyspace creation rights, he is the one allowing a new application to be deployed on a Cassandra Cluster, by creating a new keyspace
• Then an application administrator: he is the one installing the required tables for an application. It only holds the table creation right; not the keyspace creation right.
• Finally, an applicative runtime account holding neither the keyspace creation not the database table creation rights: this is a basic account used for running the service itself.

The new split between Kong migration and Kong service execution newly introduced in 0.11 allows a applicative runtime account to run Kong. However, the Kong migration process does not allow the separation of concern between the DBA and the application administrator as the Kong migration up command always starts by running the keyspace creation command, and stops immediately in case of error during this keyspace creation (including if the root cause is a “not sufficient privilege” error). It is consequently not possible for the application administrator to run Kong migration process.

A possible solution for the Kong migration up command execution would be to first try to “use keyspace”

• If OK, then it means that the keyspace already exists and it can proceed to table creation
• If not OK, then the process can try to create the keyspace (for backward compatibility with what is done today, and to manage deployments without the separation of concern mentioned above), then it shall “use keyspace” and proceed to table creation (same process as today).
  The potential error raised during the keyspace creation (because the user executing the script might not have sufficient privileges) is acceptable as it highlight the fact that the application administrator shall first ask the DBA for the keyspace creation

Another possible solution (more a workaround…) is to comment out the lines 36 to 38 of the kong/dao/migrations/Cassandra.lua file:

35      local res, err = db:query(keyspace_str, nil, nil, nil, true)
36      --if not res then
37      --  return err
38      --end
39
40      local ok, err = db:coordinator_change_keyspace(keyspace_name)
41      if not ok then
42        return err
43      end

If so, keyspace creation is still executed in any case. However, in case of error (whatever it is due to an access right issue or to any other keyspace creation issue), the processing would not be stopped and would continue up to line 40 that runs a “use keyspace” command. Lines 41 and 42 would then handle any of the errors that might be generated at that time, including the case where the keyspace creation has failed before.
If the user running the migration script has sufficient privilege (today’s situation), then both lines 35 and 40 will be executed correctly.

Additional Details & Logs

• Kong version 0.11.0

[pamiel]

Hi all,
Any feedback on this deployment issue ?
Thanks.