Security quickstart
Like many databases, the Cassandra-based CQL uses rolenames and passwords for internal authentication. Role-based authentication applies to both users and roles to enforce authorization. Roles can represent either actual individual users or roles that users are granted in CQL.
|
Cassandra is configured with a default superuser role and password pair of cassandra/cassandra by default. Using this role, additional roles are created using CQL commands. To secure the system, this default role should be deleted once one non-default superuser has been created. |
Let’s look at an example of securing CQL users.
Roles-based access control (RBAC)
In order to create a role, a user must have:
-
login privileges
-
either a
superuserrole assigned already OR -
a non-superuser role already assigned that grants permissions for the role to create roles
Role with login privileges
Create a role named alice is with login privileges:
CREATE ROLE IF NOT EXISTS alice
WITH LOGIN = true
AND PASSWORD = 'enjoyLife';The concept of a user is not a separate entity in CQL; only roles exist.
You assign a role to a user, so that you can grant them additional roles and/or permissions.
Superuser privileges allow a role to perform any database operations.
Roles are created with superuser or non-superuser status, and with or without login privileges.
Role with all permissions on a keyspace
Create a cycling_admin role, and then assign that role access to all the functionality of the cycling keyspace:
CREATE ROLE IF NOT EXISTS cycling_admin
WITH PASSWORD = 'All4One2day!';
GRANT ALL PERMISSIONS ON KEYSPACE cycling TO cycling_admin;The cycling_admin role is granted all permissions on the keyspace cycling in the second command.
Those permissions are CREATE, ALTER, DROP, SELECT, MODIFY, AUTHORIZE, DESCRIBE, and EXECUTE.
