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:
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
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:
# Allow adding and modifying keyspaces <modify-keyspaces>=operator # Allow creating and modifying Column Families App.<rw>=operator # CF-based permissions App.Logs.<rw>=operator App.Configuration.<ro>=user App.Configuration.<rw>=operator App.Data.<rw>=operator,user
So, in brief, this is how it should be designed to work in a way described above.