Configuring internal authentication and authorization

Set internal authentication and authorization at the same time, then set object permissions.

You must set internal authentication and authorization at the same time. After setting the Authorizer and the Authenticator in the cassandra.yaml file, set object permissions, as described in Managing object permissions using internal authorization.

Procedure

Perform the first three steps on every node.

Change the authenticator option in the to the native Cassandra PasswordAuthenticator by uncommenting only the PasswordAuthenticator:

The location of the cassandra.yaml file depends on the type of installation:

Package installations	/etc/dse/cassandra/cassandra.yaml
Tarball installations	`install_location`/resources/cassandra/conf/cassandra.yaml

authenticator: org.apache.cassandra.auth.PasswordAuthenticator

You can use any authenticator except AllowAll.

Change the authorizer option by commenting the AllowAllAuthorizer and adding the CassandraAuthorizer:

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

Restart the node.

Note: You can enable internal authorization on existing clusters with no downtime.
On one node, configure the system_auth keyspace replication factor.

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 cassandra.yaml. You can also disable permission caching by setting this option to 0.
Run a full repair of the system_auth keyspace.
Start cqlsh using the same superuser name and password (cassandra) that you use to start the supported client. For example, to start cqlsh on Linux:
```
./cqlsh -u cassandra -p cassandra
```
The cassandra user name is provided only as an example.
Note: Use the default cassandra user only to assist with initial setup of new users and superusers, and then disable it.
- Logins for the cassandra user are performed with QUORUM consistency.
  Do not use the default cassandra user in production, because QUORUM consistency has significant performance degradation for multiple data centers.
- Logins for all other users are performed with LOCAL_ONE consistency.
Best practices for security and performance:
- Restrict rights of users as appropriate for security. For example, do not allow access to other keyspaces.
- Follow these steps to change the default superuser.
Change the superuser's user name and password.