GRANT PERMISSION

This page documents a preview version. v2.23 Preview
Preview includes features under active development and is for development and testing only.
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

GRANTall_permissionspermissionONresourceTOrole_name

all_permissions

ALLPERMISSIONS

permission

CREATEALTERDROPSELECTMODIFYAUTHORIZEDESCRIBEEXECUTEPERMISSION

resource

ALLKEYSPACESROLESKEYSPACEkeyspace_nameTABLEtable_nameROLErole_name

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, and role_name are text identifiers (table_name may be qualified with a keyspace name).

Semantics

  • Permission AUTHORIZE on ALL 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;

See also