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
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].
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
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:
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;
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.