You use the 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. Object permission management is independent of authentication (works with Kerberos or Cassandra).
Read access to these system tables is implicitly given to every authenticated user because the tables are used by most Cassandra tools:
CassandraAuthorizer is one of many possible IAuthorizer implementations, and the one that stores permissions in the system_auth.permissions table 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 permissions:
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.
Fetching permissions can be an expensive operation. If necessary, adjust the validity period for permissions caching by setting the permissions_validity_in_ms option in the cassandra.yaml. You can also disable permission caching by setting this option to 0.
Restart the node after changing the cassandra.yaml file.
CQL 3 supports the following authorization statements, which are described in the CQL alphabetical security command reference: