GRANT PERMISSION
For production, use the latest stable version (v2024.1).
Synopsis
Use the GRANT PERMISSION
statement to grant a permission (or all the available permissions) to a role.
When a database object is created (keyspace, table, or role), an automatic and explicit grant of all the permissions relevant to the object are granted to the role creating it.
This statement is enabled by setting the YB-TServer flag --use_cassandra_authentication
to true
.
Syntax
Diagram
grant_permission
all_permissions
permission
resource
Grammar
grant_permission := GRANT all_permission | permission ON resource TO role_name;
all_permissions := ALL [ PERMISSIONS ]
permission := ( CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE | EXECUTE ) [ PERMISSION ]
resource := ALL ( KEYSPACES | ROLES ) | KEYSPACE keyspace_name | [ TABLE ] table_name | ROLE role_name;
Where
keyspace_name
,table_name
, androle_name
are text identifiers (table_name
may be qualified with a keyspace name).
Semantics
- Permission
AUTHORIZE
onALL ROLES
or on the role being used in the statement is necessary. Otherwise, an unauthorized error will be returned.
Permissions
This section describes the permissions (represented by ALTER
, AUTHORIZE
, CREATE
, DESCRIBE
, DROP
, MODIFY
, and SELECT
) that are necessary to execute operations on the database objects. A permission can be granted on a specific object (represented by resources KEYSPACE
, TABLE
, and ROLE
) or on a whole group of objects (represented by resources ALL KEYSPACES
, and ALL ROLES
). Some permissions are granted implicitly, which means that you will never see them listed when you query system_auth.role_permissions
table. Implicitly granted permissions follow these rules:
- Any permission granted on
ALL KEYSPACES
is implicitly granted on every keyspace and table in the database. - Any permission granted on a specific
KEYSPACE
is implicitly granted to any table in that keyspace. - Any permission granted on
ALL ROLES
is implicitly granted on every role.
Permissions needed to execute specific operations on a database object
Operation | Permission | Resource |
---|---|---|
ALTER KEYSPACE |
ALTER |
ALL KEYSPACES , or KEYSPACE |
ALTER ROLE |
ALTER |
ALL ROLES , or ROLE |
ALTER TABLE |
ALTER |
ALL KEYSPACES , KEYSPACE , or TABLE |
CREATE KEYSPACE |
CREATE |
ALL KEYSPACES |
CREATE ROLE |
CREATE |
ALL ROLES |
CREATE TABLE |
CREATE |
ALL KEYSPACES , KEYSPACE |
DROP KEYSPACE |
DROP |
ALL KEYSPACES , or KEYSPACE |
DROP ROLE |
DROP |
ALL ROLES , or ROLE |
DROP TABLE |
DROP |
ALL KEYSPACES , KEYSPACE , or TABLE |
GRANT PERMISSION or REVOKE PERMISSION on ALL KEYSPACES |
AUTHORIZE |
ALL KEYSPACES |
GRANT PERMISSION or REVOKE PERMISSION on ALL ROLES |
AUTHORIZE |
ALL ROLES |
GRANT PERMISSION or REVOKE PERMISSION on a keyspace |
AUTHORIZE |
ALL KEYSPACES , or KEYSPACE |
GRANT PERMISSION or REVOKE PERMISSION on a role |
AUTHORIZE |
ALL ROLES , or ROLE |
GRANT PERMISSION or REVOKE PERMISSION on a table |
AUTHORIZE |
ALL KEYSPACES , KEYSPACE , or TABLE |
GRANT ROLE or REVOKE ROLE |
AUTHORIZE |
ALL ROLES , or ROLE |
INSERT , UPDATE , DELETE , or TRUNCATE |
MODIFY |
ALL KEYSPACES , KEYSPACE , or TABLE |
LIST ROLES (not yet implemented) |
DESCRIBE |
ALL ROLES |
SELECT |
SELECT |
ALL KEYSPACES , KEYSPACE , or TABLE |
Examples
Grant MODIFY
permission on a table so role qa
can insert rows into a table
ycqlsh:example> GRANT MODIFY ON TABLE performance_tests.metrics TO qa;
Grant SELECT
permission on a table so role qa
can read the table
ycqlsh:example> GRANT SELECT ON performance_tests.metrics TO qa;
Grant CREATE
permission on ALL KEYSPACES
so role tests
can create new keyspaces
ycqlsh:example> GRANT CREATE ON ALL KEYSPACES TO tests;