Understanding User and Role Management in Cassandra Clusters Across Data Centers

Background : When a client runs list users on a Cassandra cluster and encounters an error, the article investigates why simple queries may fail and offers a unified analysis of user and role inspection across data centers.

Cassandra Overview : A Cassandra cluster consists of Nodes, Racks, and Data Centers. It uses the Gossip protocol for decentralized communication and Snitch mechanisms for node awareness. Data is partitioned on a ring using tokens generated from hash functions, enabling dynamic scaling and data distribution.

Replication Strategy : Nodes store replicas of data ranges; the replication factor determines how many nodes hold each piece of data. The primary replica is the node whose token range contains the data, and additional replicas are placed according to the chosen strategy.

Local Environment Testing : The article sets up a multi‑data‑center cluster (DC1 and DC2) with specific node IPs and seed nodes, then demonstrates user and role operations using CQLSH.

Creating and Listing Users :

cqlsh 10.186.60.61 -u cassandra -p cassandra

CREATE USER root WITH PASSWORD 'rootroot' SUPERUSER;
list users;
name      | super | datacenters
----------+-------+-------------
cassandra |  True |         ALL
root      |  True |         ALL
(2 rows)

Only SUPERUSER can create or delete users, and a user cannot delete itself. Deleting the default cassandra account requires logging in with a newly created superuser.

Viewing Users Across Data Centers :

cqlsh 10.186.60.53 -u cassandra -p cassandra
SELECT * FROM system_auth.roles;

Direct list users works only within the same data center; cross‑data‑center queries must use the system_auth.roles table.

Creating and Listing Roles :

create role appgroup1;
create role appgroup2 with password='appgroup2' and login=true;

list roles;
role      | super | login | options | datacenters
----------+-------+-------+---------+-------------
appgroup1 | False | False |      {} |         ALL
appgroup2 | False |  True |      {} |         ALL
cassandra |  True |  True |      {} |         ALL
root      |  True |  True |      {} |         ALL
(4 rows)

Roles created in one data center are not directly visible from another; the system_auth.roles table is required for cross‑center visibility.

Common Errors :

Unauthorized: Error from server: code=2100 [unauthorized] message="Unable to perform authorization of login permission: cannot achieve consistency level LOCAL_ONE"

This occurs when a node in a different data center attempts to list users or roles without sufficient consistency.

Summary of Findings :

Only the data center that created a user or role can list it directly; other centers must query system_auth.roles .

If both data centers have created users/roles, direct list commands are blocked for all, requiring deletion from one center to restore visibility.

Deletion of users or roles must be performed from the data center where they were originally created.