The role-based access control model in YCQL is a collection of permissions on resources given to roles. Thus, the entire RBAC model is built around roles, resources and permissions. It is essential to understand these concepts in order to understand the RBAC model.
Roles in YCQL can represent individual users or a group of users. They encapsulate a set of permissions that can be assigned to other roles (or users). Roles are essential to implementing and administering access control on a YugabyteDB cluster. Below are some important points about roles:
Roles which have login permission are users. Hence, all users are roles but all roles are not users.
Roles can be granted to other roles, making it possible to organize roles into a hierarchy.
Roles inherit the permissions of all other roles granted to them.
YCQL defines a number of specific resources, that represent underlying database objects. A resource can denote one object or a collection of objects. YCQL resources are hierarchical as described below:
- Keyspaces and tables follow the hierarchy:
- ROLES are hierarchical (they can be assigned to other roles). They follow the hierarchy:
The table below lists out the various resources.
||Denotes one keyspace. Typically includes all the tables and indexes defined in that keyspace.|
||Denotes one table. Includes all the indexes defined on that table.|
||Denotes one role.|
||Collection of all keyspaces in the database.|
||Collection of all roles in the database.|
Permissions are necessary to execute operations on database objects. Permissions can be granted at any level of the database hierarchy and are inherited downwards. The set of permissions include:
||keyspace, table, role||ALTER|
||keyspace, table, role||GRANT PERMISSION, REVOKE PERMISSION|
||keyspace, table, role, index||CREATE|
||keyspace, table, role, index||DROP|
||keyspace, table||INSERT, UPDATE, DELETE, TRUNCATE|
ALTERpermission on the base table is required in order to
DROPindexes on it.
Read more about YCQL permissions.