Manage roles and permissions

You assign permissions to roles to determine the level of access that a user or application has to a database. Permissions determine what actions you can perform on a resource, such as reading from a table or writing to a keyspace.

Use the LIST PERMISSIONS CQL command to view the permissions assigned to a role.

Examples of permissions include:

For more information, see List permissions.

Roles define the access level a user or application can have to a database. Each role consists of:

The database administrator must create all roles used to access the database, except for the default cassandra superuser role, which comes preconfigured. Default roles are used to manage the database and are not intended for regular user access.

You can assign roles to users or applications to grant access to a database. You can also assign roles to other roles, allowing you to manage access in a hierarchical manner.

For more information on roles, see Create role.

The only default role is the cassandra superuser role. The cassandra role grants full access to all databases and keyspaces.

DataStax recommends that you do not use the cassandra role for regular user access. Instead, create a custom superuser role immediately after creating a keyspace. Once you have created a custom superuser, you can delete the cassandra role from the keyspace. For more information, see Manage superuser accounts.

To limit the databases a role can access, you must create a custom role.

The first role you should set is the default superuser role. Think of this role as the root user in a Linux system. The superuser role grants full access to all keyspaces and tables in the database. By default, the system assigns this role with the username cassandra and password cassandra.

DataStax recommends changing the default cassandra username and password to more secure values. For guidance, see Reset your superuser password.

For security reasons, always create a custom superuser role and avoid using the default cassandra role for everyday administrative tasks. This reduces the risk of unauthorized access or accidental privilege escalation.

Roles define access control to database resources such as keyspaces, tables, and functions. To manage access control in your HCD database, create roles for users and applications using CQL.

You can create roles with specific permissions to access certain keyspaces and tables. You can also create login accounts for CQL users by assigning them roles.

Examples of roles include the following:

For more information on creating roles, see Create role.

To create a role for a user, define the necessary permissions and scope of access. The following example creates a role for a user named alice with the password alice, allowing access to the cycling keyspace:

Alice will now be able to access the cycling keyspace but only with the SELECT permission. You can create roles with varying levels of access, granting read, write, or other permissions as needed.

Custom roles allow you to fine-tune access control by defining specific permissions and scopes for users or applications. Custom roles are typically managed by a superuser and can be assigned to other roles to inherit permissions.

To create custom roles, use CQL to define a set of permissions that can be granted to other roles or mapped to external users. You can assign permissions to keyspaces and tables.

You can add permissions to both keyspaces and tables.

You manage permissions in HCD using CQL. You can assign permissions to roles using the GRANT statement and remove them with the REVOKE statement. These commands allow you to define which actions roles can perform on database resources.

For more information on how to grant permissions, see Grant permissions.