Main menu

Post navigation

More on Cassandra’s SimpleAuthority permissions

Few days ago I had some doubts on how Cassandra’s SimpleAuthenticator and SimpleAuthority really work. I mean – I was not sure of the way I should configure them to get the expected results. It may seem obvious now, but I had to look at source code to find out what is possible and what is not. So, to save your time, here’s a brief description of this.

As you probably know, Cassandra’s permission system (at least when using SimpleAuthority class) refers to two main resources types: Keyspaces and Column Families. In SimpleAuthority source code they are presented as a nested structure:

/cassandra/keyspaces/<keyspace>/<column family>

For each of them there are two access levels: read-only <ro> and read-write <rw>. It’s quite obvious what does it mean to let user have a read-write access to Column Family – it allows him to read and modify data in a Column Family. But what does it mean to have a permission for a Keyspace? It means that you can create and modify Column Families in this Keyspace. Note that “modifying” Column Family means that you can change their attributes (i.e. comparator type or so)

The last, special permission is <modify-keyspaces> which allows user to add new keyspaces and modify existing ones.

However, when you define your own access.properties file you do it in a different way that described above – the main difference is that you ignore the “cassandra” and “keyspace” parts of path. Secondly – path items are separated with dots instead of slashes.

To give you an example, here’s how I would design permissions for a sample application. Let’s say that we have two users accessing Cassandra:

operator – system administrator, can do everything, including creating new Keyspaces and CF’s,

user – system user, can read most of the data, but can write only to one CF.

Additionally, there’s a Keyspace “App” containing three CFs:

Logs – stores some logging data which should be accessed only by operator,

Configuration – stores a system-wide settings; everyone can read it, but only operator can modify it

Data – some application data; both – operator and user – can read and write to this CF.

So, for these (a bit unreal) requirements, /etc/cassandra/conf/access.properties will look like this: