Apache Cassandra 1.2 Documentation

Managing object permissions using internal authorization

You use familiar relational database GRANT/REVOKE paradigm to grant or revoke permissions to access Cassandra data. A superuser grants initial permissions, and subsequently a user may or may not be given the permission to grant/revoke permissions.

Accessing system resources

Read access to these resources is implicitly given to every authenticated user because the tables are used by most Cassandra tools:

  • system.schema_keyspace
  • system.schema_columns
  • system.schema_columnfamilies
  • system.local
  • system.peers

Configuration

CassandraAuthorizer is one of many possible IAuthorizer implementations, and the one that stores permissions in the system_auth.permissions column family to support all authorization-related CQL 3 statements. Configuration consists mainly of changing the authorizer option in the cassandra.yaml to use the CassandraAuthorizer.

To configure internal authorization for managing object (resource) permissions:

  1. In the cassandra.yaml, comment out the default AllowAllAuthorizer and add the CassandraAuthorizer as shown here:

    #authorizer: org.apache.cassandra.auth.AllowAllAuthorizer
authorizer: org.apache.cassandra.auth.CassandraAuthorizer

    You can use any authenticator except AllowAll.

  2. Configure the system_auth keyspace replication factor.

  3. Fetching permissions can be an expensive operation. If necessary, adjust the validity period for permissions caching in the cassandra.yaml. You can disable permission caching by setting this option to 0.

  4. Restart Cassandra after changing the cassandra.yaml file.

CQL 3 supports the following authorization statements: