Security quickstart

Like many databases, Apache Cassandra® uses rolenames and passwords for internal authentication. Role-based authentication applies to both users and roles to enforce authorization. Roles can represent either actual individual users or roles that users are granted in CQL.

Apache Cassandra® is configured with a default superuser role and password pair of cassandra/cassandra by default. Using this role, additional roles are created using CQL commands. To secure the system, this default role should be deleted once one non-default superuser has been created.

Let’s look at an example of securing CQL users.

Roles-based access control (RBAC)

roles

In order to create a role, a user must have:

  • login privileges

  • either a superuser role assign already OR

  • a non-superuser role already assigned that grants permissions for the role to create roles

A role named alice is created and given login privileges:

CREATE ROLE alice WITH PASSWORD = 'enjoyLife' AND LOGIN = true;

You want to assign a role to a user, so that you can grant them additional roles and/or permissions. Roles can be created with superuser or non-superuser status, and with or without login privileges. Superuser privileges allow a role to perform any database operations.

Next, create a role that has access to all the functionality of a particular keyspace:

CREATE ROLE cycling_admin WITH PASSWORD = '1234abcd';
GRANT ALL PERMISSIONS ON KEYSPACE cycling TO cycling_admin;

This role can assigned to another role with privileges; any role that is granted this role will inherit the cycling_admin privileges. The cycling_admin role is granted all permissions on the keyspace cycling in the second command.

When alice is granted the role cycling_admin, alice is now granted all permissions on the keyspace_cycling_:

GRANT cycling_admin TO alice;

An individual user can be granted any number of roles, just as any functional role can be granted another role’s permissions.

The role of inheritance is further illustrated by the next example:

CREATE ROLE cycling_analyst WITH PASSWORD = 'zyxw9876';
GRANT SELECT ON TABLE cycling.analysis TO cycling_analyst;
CREATE ROLE hockey_analyst WITH PASSWORD = 'Iget2seeAll';
GRANT SELECT ON TABLE hockey.analysis TO hockey_analyst;
GRANT hockey_analyst TO cycling_analyst;
GRANT cyclist_analyst TO jane;

Two roles, cycling_analyst and hockey_analyst, are created. Each is granted access to execute queries on an analysis table in their respective keyspaces. Next, everyone with the cycling_analyst role is granted the same permission as the hockey_analyst. And finally, jane is assigned the cycling_analyst, gaining both the permissions of that role and those of a hockey_analyst by inheritance. She has access to query two tables, cycling.analysis and hockey.analysis.

Permissions and SUPERUSER status are inherited, but the LOGIN privilege is not.

A role can be authorized to create roles or be authorized to grant and revoke permissions:

// Give cycling_accounts the right to create roles
GRANT CREATE ON ALL ROLES TO cycling_accounts;
// Give cycling_accounts the right to grant or revoke permissions
GRANT AUTHORIZE ON KEYSPACE cycling TO cycling_accounts;
GRANT cyclist_accounts TO jane;
GRANT cyclist_accounts TO john;

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com