DataStax Developer Blog

Dynamic Permission Allocation in Cassandra 1.1

By Pavel Yaskevich -  September 13, 2012 | 2 Comments

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

As shown in the previous paragraph the IAuthority interface is good in permission checking but it’s hard to implement even a basic permission management if required. IAuthority2 extends the old interface and adds a new dynamic permission management facilities such a “grant”, “revoke” and “list grants” methods as well as extended set of permissions. Let’s take a look at the new commands separately:

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 in grant/revoke CQL3 examples should be given in following format <keyspace>[.<column_family>].

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.



Comments

  1. Devdatta Kulkarni says:

    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

  2. Pavel Yaskevich says:

    Hi Devdatta,

    It depends on the implementation but it is designed to be able to handle updates as part of existing connection.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>