Manage roles and permissions
In Hyper-Converged Database (HCD), you use roles and permissions for access control.
Roles are containers for permissions.
Permissions grant access to perform specific actions on specific resources, such as altering keyspaces (MODIFY) or reading tables (SELECT).
Unless a role has the SUPERUSER option enabled, it has no permissions by default.
You can grant permissions directly to a role, or you can grant a role to another role (permissions inheritance).
Always limit roles to the minimum necessary permissions.
CQL commands for roles and permissions
To manage roles and permissions, use the following CQL commands:
Create roles
You must create all necessary roles for your database.
HCD includes only one default role (cassandra), which isn’t meant for production use.
|
When you install HCD, it creates a |
Roles have a name, at minimum.
If authentication is enabled in your database configuration, you can also enable the LOGIN and PASSWORD options.
Use the SUPERUSER option only for true superuser (root) access.
The following example creates a role named readonly with a password, and then grants read permission (SELECT) on the entire cycling keyspace:
CREATE ROLE readonly WITH PASSWORD = 'password' AND LOGIN = true;
GRANT SELECT ON KEYSPACE cycling TO readonly;Roles for users and applications
|
Database roles aren’t for authorizing every application user. They are exclusively for direct access to the database, which is usually programmatic. Access by the general user population is controlled at the application layer. Client applications use database role credentials to send requests to the database in response to user actions at the application layer. |
HCD doesn’t have a dedicated object for users, service accounts, or applications.
Instead, these entities are represented by database roles.
For secure access, enable authentication in your database configuration, and then create roles with the LOGIN and PASSWORD options.
Roles without LOGIN enabled should not be used to authenticate external requests to the database.
Instead, use non-LOGIN roles as containers for permissions, and then grant non-LOGIN roles to LOGIN roles.
This separates your permission hierarchy from individual users or accounts.
For example, an admin role might contain administrative permissions that are then granted to additional roles for specific users, such as amy and joe.
If you follow this model, don’t assign permissions directly to user (LOGIN) roles; only assign permissions to non-LOGIN roles that are then granted to LOGIN roles.
Password requirements
Passwords for CQL roles must meet the following requirements:
-
Includes at least eight characters.
-
Includes a lowercase letter, an uppercase letter, and a number.
-
Doesn’t include parts of the username.
-
Doesn’t repeat any of the role’s last four passwords.
