The goal of this tutorial is to show you how to view the permissions of various users and the roles within a Cassandra cluster.
Let’s get started.
Step 1: Setup Test User and Role
The first step is configuring a test user and role for illustration purposes. If you are a development database, you can skip this section and use the already existing users in your cluster.
Let’s start by creating a test user:
... WITH PASSWORD = 'password'
... AND LOGIN = true;
The given command uses the CREATE ROLE command to create a user with Linuxhint username.
NOTE: User creation in Cassandra requires the cluster to have a user authentication enabled. Check out our tutorial on the topic to learn more.
Step 2: Create a Test Role
The next step is to create a test role with specific permissions. The following example creates a role called administrator:
We can then assign a full access to the administrator role to a specific keyspace. In this example, we use the “testing” keyspace.
... with replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
Assign a full permission to the previous keyspace:
Finally, we can assign the administrator role to the user that we created earlier by running the following command:
Once we assign the role to a specific user, we can manage the permissions for the administrator role instead of individual user accounts.
Step 3: Cassandra Show User Permissions
Once completed, we can view the permissions of a given user by running the LIST ALL PERMISSIONS command.
For example, to show all the permissions of the Linuxhint’s user, we can run the following command:
The previous command should list a table with detailed information about the permissions of the Linuxhint user.
An example output is as shown in the following:
---------------+---------------+--------------------+------------
administrator | administrator | <keyspace testing> | CREATE
administrator | administrator | <keyspace testing> | ALTER
administrator | administrator | <keyspace testing> | DROP
administrator | administrator | <keyspace testing> | SELECT
administrator | administrator | <keyspace testing> | MODIFY
administrator | administrator | <keyspace testing> | AUTHORIZE
If you do not wish to show the permissions of a specific user, you can use the LIST ALL command which fetches the detailed permissions on all the users in the cluster.
The resulting output is as follows:
---------------+---------------+----------------------------+------------
administrator | administrator | <keyspace testing> | CREATE
administrator | administrator | <keyspace testing> | ALTER
administrator | administrator | <keyspace testing> | DROP
administrator | administrator | <keyspace testing> | SELECT
administrator | administrator | <keyspace testing> | MODIFY
administrator | administrator | <keyspace testing> | AUTHORIZE
cassandra | cassandra | <keyspace testing> | CREATE
cassandra | cassandra | <keyspace testing> | ALTER
cassandra | cassandra | <keyspace testing> | DROP
cassandra | cassandra | <keyspace testing> | SELECT
cassandra | cassandra | <keyspace testing> | MODIFY
cassandra | cassandra | <keyspace testing> | AUTHORIZE
cassandra | cassandra | <all functions in testing> | CREATE
cassandra | cassandra | <all functions in testing> | ALTER
cassandra | cassandra | <all functions in testing> | DROP
cassandra | cassandra | <all functions in testing> | AUTHORIZE
cassandra | cassandra | <all functions in testing> | EXECUTE
cassandra | cassandra | <role administrator> | ALTER
cassandra | cassandra | <role administrator> | DROP
cassandra | cassandra | <role administrator> | AUTHORIZE
cassandra | cassandra | <role administrator> | DESCRIBE
cassandra | cassandra | <role linuxhint> | ALTER
cassandra | cassandra | <role linuxhint> | DROP
cassandra | cassandra | <role linuxhint> | AUTHORIZE
cassandra | cassandra | <role linuxhint> | DESCRIBE
(25 rows)
In this case, the command includes all the users, resources, and their corresponding permissions.
Conclusion
In this post, we covered how to create a Cassandra user account, create roles, assign permissions, and list all permissions of one or all users in the cluster.
Thanks for reading!