Note
As of release 1.0, the SimpleAuthenticator and SimpleAuthority classes have been moved to the example directory of the Apache Cassandra project repository. They are no longer available in the packaged and binary distributions. They are only examples and do not provide actual security in their current state. DataStax does not officially support them and does not recommend their use.
Using authentication and authorization requires configuration changes in cassandra.yaml and two additional files:
These files are named access.properties and passwd.properties, respectively, and are located in the examples directory of the Apache Cassandra project repository. To test simple authentication, you can move these files to the conf directory.
The location of the cassandra.yaml file depends on the type of installation; see Cassandra Configuration Files Locations or DataStax Enterprise Configuration Files Locations.
To set up simple authentication and authorization
Edit cassandra.yaml, setting org.apache.cassandra.auth.SimpleAuthenticator as the authenticator value. The default value of AllowAllAuthenticator is equivalent to no authentication.
Edit access.properties, adding entries for users and their permissions to read and write to specified keyspaces and tables. See access.properties below for details on the correct format.
Make sure that users specified in access.properties have corresponding entries in passwd.properties. See passwd.properties for details and examples.
After making the required configuration changes, specify the properties files when starting Cassandra with the flags -Dpasswd.properties and -Daccess.properties. For example:
cd <install_location>
sh bin/cassandra -f
-Dpasswd.properties=conf/passwd.properties
-Daccess.properties=conf/access.properties
This file contains entries in the format:
KEYSPACE[.TABLE].PERMISSION=USERS
- KEYSPACE is the keyspace name.
- TABLE is the table name.
- PERMISSION is one of <ro> or <rw> for read-only or read-write respectively.
- USERS is a comma delimited list of users from passwd.properties.
For example, to control access to Keyspace1 and give jsmith and Elvis read-only permissions while allowing dilbert full read-write access to add and remove tables, you would create the following entries:
Keyspace1.<ro>=jsmith,Elvis Presley
Keyspace1.<rw>=dilbert
To provide a finer level of access control to the Standard1 table in Keyspace1, you would create the following entry to allow the specified users read-write access:
Keyspace1.Standard1.<rw>=jsmith,Elvis Presley,dilbert
The access.properties file also contains a simple list of users who have permissions to modify the list of keyspaces:
<modify-keyspaces>=jsmith
This file contains name/value pairs in which the names match users defined in access.properties and the values are user passwords. Passwords are in clear text unless the passwd.mode=MD5 system property is provided.
jsmith=havebadpass
Elvis Presley=graceland4ever
dilbert=nomoovertime