Details
-
Improvement
-
Status: Changes Suggested
-
Normal
-
Resolution: Unresolved
-
None
-
Operability
-
Normal
-
All
-
None
-
Description
The Cassandra Query Language https://cassandra.apache.org/doc/stable/cassandra/cql/security.html / https://cassandra.apache.org/doc/5.0/cassandra/developing/cql/security.html specify that a role can have custom options defined as literal map.
The documentation shows a valid example of these custom options:
CREATE ROLE carlos WITH OPTIONS = { 'custom_option1' : 'option1_value', 'custom_option2' : 99 };
However, the storage/retrieval of such custom options has not been implemented in Cassandra. See for instance, https://github.com/apache/cassandra/blob/18960d6e3443bf002ef4f46c7f0e1f2ee99734e1/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L393-L396
Storing custom options per role could have multiple usages, for instance, it could allow admins to specify fine-grain permissions that can be interpreted by custom authenticator/authorizer.
The goal of this task is to add support for Role custom options, by storing them in an additional table called role_options in the system_auth keyspace.
Creating a role with options should write the information in both the roles and the role_options tables. Creating a role with no options or having an empty map of options should not write any information in the role_options table.
Altering a role should behave as follows when executing an ALTER ROLE statement:
- without specifying OPTIONS: no changes should be done in the role_options table.
- specifying OPTIONS altering a role with no previous custom options: we should insert the custom options in the role_options table.
- specifying OPTIONS altering a role with previous custom options: we should replace the existent custom options
- in the role_options table.
Dropping a role should drop information in both roles and role_options.
Attachments
Issue Links
- links to
