Until recently, Cassandra clusters were for all intents and purposes, single-tenant; One team managed a single application (or set of closely related services) on a purpose-built Cassandra cluster (often co-located on the database nodes themselves). With the cluster formerly known as AQS being retooled as Generated Datasets, and the deprecation of RESTBase and its use-cases being decomposed along team boundaries, some clusters will now become explicitly multi-tenant. As a result, patterns of access that relied upon a 1:1 relationship between application and cluster will need to be rethought.

Proposed

Roles

For each separately deployed service that connects to Cassandra, there should exist (at least) one unique role (user). Utilizing one role for multiple services (for example, because they have a team in common) should be avoided. Where possible, multiple roles can be used to selectively limit grants (for example, a role with only SELECT for a read-only service, and another with MODIFY for a process that ingests data). See: https://en.wikipedia.org/wiki/Principle_of_least_privilege

Secrets

Credentials for Cassandra roles must be managed in the private Git repository, and written to a location readable by the deployed service (for example to a configuration file created through templating).

Developer/admin access

TBD