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, EXECUTE, UNMASK, and SELECT_MASKED.
endif:cass50[]
This role can assigned to another role, that role will inherit the granted privileges that cycling_admin role is granted.
When alice is granted the role cycling_admin, alice will now have all permissions on the keyspace cycling:
GRANT cycling_admin TO alice;An individual user can be granted any number of roles, just as any functional role can be granted another role’s permissions.
The role of inheritance is further illustrated by the next example:
CREATE ROLE cycling_analyst WITH PASSWORD = 'zyxw9876';
GRANT SELECT ON TABLE cycling.cyclist_alt_stats TO cycling_analyst;
CREATE ROLE hockey_analyst WITH PASSWORD = 'Iget2seeAll';
GRANT SELECT ON TABLE hockey.analysis TO hockey_analyst;
GRANT hockey_analyst TO cycling_analyst;
GRANT cycling_analyst TO alice;Two roles, cycling_analyst and hockey_analyst, are created.
Each is granted access to execute queries (SELECT) on the cyclist_alt_stats table in their respective keyspaces.
Next, everyone with the cycling_analyst role is granted the same permission as the hockey_analyst.
Finally, alice is granted the cycling_analyst role, gaining both the permissions of that role and those of the hockey_analyst role by inheritance.
She has access to query two tables, cycling.cyclist_alt_stats and hockey.analysis.
|
Permissions and |
A role can be authorized to create roles or be authorized to grant and revoke permissions:
GRANT CREATE ON ALL ROLES TO cycling_accounts; (1)
GRANT AUTHORIZE ON KEYSPACE cycling TO cycling_accounts; (2)
// LOG IN AS cycling_accounts before running the following commands:
GRANT cycling_accounts TO jane;
GRANT cycling_accounts TO john;| 1 | Give cycling_accounts the right to create roles. |
| 2 | Give cycling_accounts the right to grant or revoke permissions. |
