Internal authentication and why the default "cassandra" user should be avoided

Summary

When enabling internal authentication in Apache Cassandra, the default "cassandra" user should not be used after initial setup.

Details

Internal authentication when first setup will create a default "cassandra" user. The purpose of this user is to enable logging into the system and creation of subsequent users that are going to be implemented going forward from that point.

The "cassandra" user also authenticates with a consistency level of "Quorum" therefore there must be a Quorum of nodes available across the entire cluster.

If this default user is subsequently used during normal production operations, issues may occur because logins will need to be authenticated across potentially slower network links (i.e. WAN links between remote DCs).

Solution

Once authentication is configured, the required users should be added with the correct "superuser" privileges and the default "cassandra" user have its password changed and the elevated privileges revoked.

Further reading

Further information is available here:

http://docs.datastax.com/en/datastax_enterprise/4.7/datastax_enterprise/sec/secConfiguringInternalAuthentication.html

http://docs.datastax.com/en/datastax_enterprise/4.7/datastax_enterprise/sec/secChangingDefaultSuperuser.html

This blog entry also explains this issue very well:

https://lostechies.com/ryansvihla/2014/09/22/cassandra-auth-never-use-the-cassandra-user-in-production/