About roles

Role-based access control (RBAC) is only available after completing Enabling DSE Unified Authentication.

DataStax Enterprise (DSE) doesn’t have a dedicated object for users. Instead, users are represented by database roles.

Role management modes

The DSE Role Manager mode in dse.yaml effects how a role is assigned to an authenticated user:

internal: Uses a primary role for each individual user and is a 1-to-1 mapping. A role is assigned by matching the authenticated user name to a role name.

You can create roles specifically to grant access to users or service accounts, or you can create roles to contain sets of permissions that are then granted to other roles. For example, an admin role might contain administrative permissions that are then granted to additional roles for specific users, such as amy and joe.

DataStax recommends that you manage permissions by nesting roles. Use GRANT <role_name> TO <role_name> to give all the permissions from the first role to the second role. If you alter the first role, the permissions inherited by the second role automatically change.
ldap: Uses LDAP group membership and is a 1-to-many mapping. The DSE Role Manager looks up the user in LDAP and returns a list of groups. Users are assigned all the roles that match their group name. Roles for each individual user are not required and the assigned DSE roles automatically change when LDAP group membership changes.

Create database roles to manage permissions for each group. DSE disables nested roles when LDAP mode is selected; using GRANT <role_name> TO <role_name> results in an error.

Configure the assignment method by setting role_management_options and mode in the dse.yaml.

Managing roles

Creating a role to manage access to database objects is a two step process, first you create a role and then you grant permissions on a resource.

Use the CQL CREATE ROLE, ALTER ROLE, and DROP ROLE commands to manage roles using the following syntax:

(CREATE | ALTER | DROP ) <role_name>
 [WITH (LOGIN = true | SUPERUSER = true | password = 'password')];

Role properties:

SUPERUSER: (Default: false) Execute ALL CQL commands, equivalent to a root account. See Add a superuser role.
LOGIN: (Default: false) Required to execute CQL requests. When managing permissions using roles as an assignable permission set, the permission set role does not require login.
PASSWORD: (Default: null) Stores a bcrypt-salted hash password for the role in the system_auth keyspace. A role that has a password represents an individual user that can authenticate against the internal scheme (also requires LOGIN = true).

Use the LIST ROLES command to show all roles that you have describe permission on or all roles assigned to a role.

LIST ROLES [of <role_name>];

Only SUPERUSER roles or roles with CREATE, ALTER, and DROP permission can manage roles.

Permissions to create, modify, and drop roles

To manage roles the following permissions are required:

Role management permissions
Permission	Database resource	Description
ALTER	ALL ROLES \| ROLE <role_name>	ALTER ROLE on all roles or specified role.
CREATE	ALL ROLES \| ROLE <role_name>	CREATE ROLE with any name or only create a role with specific name, automatically is granted AUTHORIZE on the new role.
DESCRIBE	ALL ROLES \| ROLE <role_name>	LIST privilege on all roles or only roles granted to another, specified role.
DROP	ALL ROLES \| ROLE <role_name>	DROP ROLE on any role or permission to drop a specific role.

Permissions to manage access control

In order to manage permissions, the role with the GRANT or REVOKE command must have AUTHORIZE permission on both the target role and the resource.

To allow a role to manage permissions of a database object:

GRANT AUTHORIZE on <resource_name> to <management_role>;

To allow a role to manage permissions of a role:

GRANT AUTHORIZE on <target_role> to <management_role>;

To allow a role to create proxy roles:

GRANT AUTHORIZE on <proxy_role> to <management_role>;
GRANT AUTHORIZE on <application_role> to <management_role>

where AUTHORIZE gives GRANT and REVOKE permission to the role for managing permissions of other roles, resource_name is any database resources, see database resources.

Restriction: The following rules apply when managing roles and access to database objects:

Creating a new role requires CREATE granted on ALL ROLES.
GRANT and REVOKE requires the permission to be grantable (AUTHORIZE FOR <permission_name>) on the resource.
Users can not modify the LOGIN and SUPERUSER options for their own role. This prevents users with ALTER permissions from self-promoting to SUPERUSER or creating SUPERUSER roles.

About roles

Role management modes

Managing roles

Permissions to create, modify, and drop roles

Permissions to manage access control

Was this helpful?

Give Feedback