Dynamic Permission Allocation in Cassandra 1.1
In this short post I would like to introduce readers to the new authorization interface which would be included, along with current one, into upcoming Cassandra 1.1.6 release.
A drop of history
The aim of the authorization interface have always been toward flexibility (or pluggability if you like), users are given two kinds of permissions, namely READ and WRITE, and two kinds of resources – Keyspace and ColumnFamily, although it’s important to note that there is a third kind of resource which is a keyspace administration. Resource can be represented as a string in the following format “/cassandra/keyspaces[/<keyspace>[/<column_family>]]”, where keyspace and column_family are optional.
IAuthority interface consists of a “authorize” method which takes a user name and resource and produces a set of permissions that user has for a given resource, and “validateConfiguration” method which checks implementation configuration on system startup. Having such simple methods to implement users are free to store permissions just in the way they want to: be it a native Cassandra storage or some external persistance layer. The only thing this approach is missing though is permission management, this is what IAuthority2 is up to fix.
The new IAuthority2 interface
Grant
Takes five arguments:
- granter – user who runs this command.
- permission – The specific permission to grant grantee access to.
- grantee – The user being granted the permission.
- resource – The resource permission applies to, in format of “/cassandra/keyspaces[/<keyspace>[/<column_family>]]”.
- grant_option – Gives grantee the ability to grant the same kind of a permission to this resource to other users.
It’s also available thought CQL3 interface for user convenience as GRANT <permission> ON <resource> TO <user> [WITH GRANT OPTION].
Revoke
Takes four arguments:
- revoker – user who runs this command.
- permission – The specific permission to revoke.
- grantee – The user to revoke permission from.
- resource – The resource affected by permission change, in format of “/cassandra/keyspaces[/<keyspace>[/<column_family>]]”
It’s also available thought CQL3 interface for user convenience as REVOKE <permission> ON <resource> FROM <user>.
It’s important to note that
List Permissions
Takes one argument:
- user – The user to look up permission/resource set.
It’s also available thought CQL3 interface for user convenience as LIST GRANTS FOR <user>.
Permission set has also been updated and now consists of following:
- FULL_ACCESS
- NO_ACCESS
- DESCRIBE
- CREATE
- ALTER
- DROP
- UPDATE
- DELETE
- SELECT
All of the permissions are accessible by the listed names via CQL3 interface.
Examples of the CQL3 command usage:
GRANT SELECT ON myks.my_cf TO omega;
GRANT FULL_ACCESS ON myks TO omega WITH GRANT OPTION;
REVOKE UPDATE ON ks FROM omega;
REVOKE SELECT ON ks.cf FROM tango;
LIST GRANTS FOR alpha;
Conclusion
As you can see the new API allows developers to easily create own permission management schemas keeping in mind that, by default, new interface does not put any restriction on grant/revoke/list usage so it should be done by implementors. See CASSANDRA-4490 for code and technical discussion.
Hi Pavel,
This looks interesting. Permission management functionality was certainly needed.
I have one question. After a grantee has been granted new permission, do those permission become available in the existing sessions of the grantee, or does the grantee have to open a new session to be able to use the new permissions?
Thanks,
Devdatta
Hi Devdatta,
It depends on the implementation but it is designed to be able to handle updates as part of existing connection.