We've now created a user account for our data analytics team, but so far that user can't actually do anything in our database. We'd like to give the data analytics team read access to all the data in our application's keyspace, but no ability to modify data or schema structures. To do this, we'll use the GRANT command:
GRANT SELECT PERMISSION ON KEYSPACE "my_status" TO 'data_analytics';
Now the data_analytics user can read the data from any table in the my_status keyspace; however, it can't make any modifications to anything. The SELECT permission we used above is one of six that Cassandra makes available:
|
Permission |
Description |
CQL commands allowed |
|---|---|---|
|
|
Read data |
|
|
|
Add, update, and remove data in existing tables |
|
|
|
Create keyspaces and tables |
|
|
|
Modify the structure of existing keyspaces and tables |
|
|
|
Drop existing keyspaces and tables |
|
|
|
Grant or revoke permissions to other users |
|
There is also an ALL permission that is simply shorthand for granting all six of the permissions listed above.
As well as granting a permission across an entire keyspace, we can also grant permissions to operate on a specific table. For instance, we might want to give the data analytics team full read/write access to the status_update_views table that we created in Chapter 9, Aggregating Time-Series Data, since the data in that table is primarily an analytics concern. To do that, we'll use GRANT to issue a permission on a specific table:
GRANT MODIFY PERMISSION ON TABLE "my_status"."status_update_views" TO 'data_analytics';
Note that we use ON TABLE instead of ON KEYSPACE here, and that we provide the fully-qualified name of the table we want the permission to apply to. Of course, if we've previously issued a USE "my_status"; command in this session, we can refer to the table name without providing the keyspace name explicitly.
Note
The GRANT statement can be used to provide all manner of access, from a very broad mandate to a very narrow set of permissions. For full details of the
GRANT syntax, see the DataStax CQL reference: http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/grant_r.html.
Much like user accounts, permissions are stored in a human-readable way in a Cassandra table, in this case the permissions table. We can see the effects of the permissions that we granted by reading from this table:
SELECT * FROM "system_auth"."permissions";
We'll see a row for each of the permissions we've granted:
Note that the resource column contains a path to the keyspace or column family that the user has permissions on, and that the permissions column is in fact a set column. Note also that the cassandra user does not appear in this list; as a superuser, the cassandra user automatically has permission to do anything it wants, and does not need explicit authorization of the kind stored in the permissions table.
Let us say that, having slept on it, we've reconsidered the decision to give the data analytics team read/write access to the status_update_views table. After all, the data in that table is generated automatically by the application, and there's no need for the analytics team to be able to modify it. Happily, we can revoke that permission just as easily as we granted it, using the REVOKE command:
REVOKE MODIFY PERMISSION ON "my_status"."status_update_views" FROM 'data_analytics';
The syntax of the REVOKE command is identical to that of the GRANT command, except that the TO keyword is replaced by FROM. We can check the system_auth.permissions table to satisfy ourselves that the permissions are how we'd like:
We can rest easy knowing that the only remaining access granted to the analytics team is keyspace-wide read-only permissions.
Note
For more on REVOKE, see the DataStax CQL documentation: http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/revoke_r.html.