데이터베이스 역할

데이터베이스 역할 (Database Roles)

CQL은 데이터베이스 역할(role)을 사용해 사용자와 사용자 집단을 나타냅니다. 문법적으로 역할은 다음과 같이 정의됩니다:

role_name ::= identifier | string

출처: 문서

본문

CREATE ROLE

역할 만들기는 CREATE ROLE 문을 사용합니다:

create_role_statement ::= CREATE ROLE [ IF NOT EXISTS ] role_name
                          [ WITH role_options ]
role_options ::= role_option ( AND role_option)*
role_option ::= PASSWORD '=' string
                | HASHED PASSWORD '=' string
                | LOGIN '=' boolean
                | SUPERUSER '=' boolean
                | OPTIONS '=' map_literal
                | ACCESS TO DATACENTERS set_literal
                | ACCESS TO ALL DATACENTERS
                | ACCESS FROM CIDRS set_literal
                | ACCESS FROM ALL CIDRS

예를 들어:

CREATE ROLE new_role;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
CREATE ROLE alice WITH HASHED PASSWORD = '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' AND LOGIN = true;
CREATE ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
CREATE ROLE carlos WITH OPTIONS = { 'custom_option1' : 'option1_value', 'custom_option2' : 99 };
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO DATACENTERS {'DC1', 'DC3'};
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO ALL DATACENTERS;
CREATE ROLE bob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1', 'region2' };
CREATE ROLE hob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;

기본적으로 역할은 LOGIN 권한이나 SUPERUSER 상태를 가지지 않습니다.

데이터베이스 리소스에 대한 권한(permission)은 역할에 부여됩니다. 리소스 유형에는 키스페이스, 테이블, 함수, 그리고 역할 자체가 있습니다. 역할은 다른 역할에 부여되어 계층적 권한 구조를 만들 수 있어요. 이 계층에서 권한과 SUPERUSER 상태는 상속되지만, LOGIN 권한은 상속되지 않습니다.

역할이 LOGIN 권한을 가진다면, 클라이언트는 연결 시 그 역할로 식별될 수 있습니다. 그 연결의 기간 동안 클라이언트는 그 역할에 부여된 모든 역할과 권한을 획득합니다.

클라이언트가 SUPERUSER가 아닌 한, CREATE 권한이 있는 클라이언트만 데이터베이스 역할 리소스에 대해 CREATE ROLE 요청을 발행할 수 있습니다. Cassandra에서 역할 관리는 플러그 가능하며, 커스텀 구현은 나열된 옵션의 일부만 지원할 수 있어요.

역할 이름은 영숫자가 아닌 문자를 포함하면 따옴표로 감싸야 합니다.

내부 인증을 위한 자격 증명 설정

내부 인증을 위한 비밀번호를 설정하려면 WITH PASSWORD 절을 사용하고 비밀번호를 작은따옴표로 감싸세요.

내부 인증이 설정되지 않았거나 역할이 LOGIN 권한이 없다면 WITH PASSWORD 절은 필요하지 않습니다.

WITH HASHED PASSWORD를 사용해 jBcrypt 해시 비밀번호를 직접 제공하세요. hash_password 도구를 참고하세요.

특정 데이터센터로의 연결 제한

network_authorizer가 구성되면, ACCESS TO DATACENTERS 절 다음에 사용자가 접근할 수 있는 데이터센터의 set 리터럴을 붙여 로그인 역할을 특정 데이터센터로 제한할 수 있어요. 데이터센터를 지정하지 않으면 암시적으로 모든 데이터센터에 대한 접근이 부여됩니다. ACCESS TO ALL DATACENTERS 절은 명시성을 위해 사용할 수 있지만 기능적 차이는 없습니다.

특정 CIDR 그룹으로부터의 연결 제한

cidr_authorizer가 구성되면, ACCESS FROM CIDRS 절 다음에 사용자가 접근할 수 있는 CIDR 그룹의 set 리터럴을 붙여 역할이 특정 리전(즉 CIDR 그룹)에서만 로그인하도록 제한할 수 있어요. CIDR 그룹을 지정하지 않으면 암시적으로 모든 CIDR 그룹으로부터의 접근이 부여됩니다. ACCESS FROM ALL CIDRS 절은 명시성을 위해 사용할 수 있지만 기능적 차이는 없습니다. 이 절은 CIDR 그룹 제한을 제거하는 데도 사용할 수 있어요. ACCESS FROM CIDRS 절에는 유효한 CIDR 그룹을 사용해야 합니다. nodetool list-cidrgroups 명령으로 클러스터에서 사용 가능한 CIDR 그룹을 볼 수 있습니다.

역할을 조건부로 만들기

기존 역할을 만들려 하면 IF NOT EXISTS 옵션을 사용하지 않는 한 잘못된 쿼리 조건이 됩니다. 옵션을 사용하고 역할이 존재하면 문은 no-op입니다:

CREATE ROLE other_role;
CREATE ROLE IF NOT EXISTS other_role;

ALTER ROLE

역할 옵션 변경은 ALTER ROLE 문을 사용합니다:

alter_role_statement ::= ALTER ROLE [ IF EXISTS ] role_name WITH role_options

예를 들어:

ALTER ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
ALTER ROLE bob WITH HASHED PASSWORD = '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' AND SUPERUSER = false;
ALTER ROLE rob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;
ALTER ROLE hob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1' };

역할이 존재하지 않으면 IF EXISTS를 사용하지 않는 한 문은 오류를 반환하며, 사용하면 연산이 no-op입니다.

WITH HASHED PASSWORD를 사용해 jBcrypt 해시 비밀번호를 직접 제공하세요. hash_password 도구를 참고하세요.

특정 데이터센터로의 연결 제한

network_authorizer가 구성되면, ACCESS TO DATACENTERS 절 다음에 사용자가 접근할 수 있는 데이터센터의 set 리터럴을 붙여 로그인 역할을 특정 데이터센터로 제한할 수 있어요. 데이터센터 제한을 제거하려면 ACCESS TO ALL DATACENTERS 절을 사용하세요.

특정 CIDR 그룹으로부터의 연결 제한

cidr_authorizer가 구성되면, ACCESS FROM CIDRS 절 다음에 사용자가 접근할 수 있는 CIDR 그룹의 set 리터럴을 붙여 역할이 특정 리전에서만 로그인하도록 제한할 수 있어요. CIDR 그룹을 지정하지 않으면 암시적으로 모든 CIDR 그룹으로부터의 접근이 부여됩니다. ACCESS FROM ALL CIDRS 절은 명시성을 위해 사용할 수 있지만 기능적 차이는 없습니다. 이 절은 CIDR 그룹 제한을 제거하는 데도 사용할 수 있어요. ACCESS FROM CIDRS 절에는 유효한 CIDR 그룹을 사용해야 합니다. nodetool list-cidrgroups 명령으로 클러스터에서 사용 가능한 CIDR 그룹을 볼 수 있습니다.

ALTER ROLE 문 실행 조건

• 클라이언트는 다른 역할의 SUPERUSER 상태를 변경하려면 SUPERUSER 상태를 가져야 합니다.
• 클라이언트는 현재 보유한 어떤 역할의 SUPERUSER 상태도 변경할 수 없습니다.
• 클라이언트는 로그인 시 자신이 식별된 역할의 특정 속성만 수정할 수 있습니다(예: PASSWORD).
• 역할의 속성을 수정하려면 클라이언트는 그 역할에 대한 ALTER 권한이 부여되어야 합니다.

DROP ROLE

역할 삭제는 DROP ROLE 문을 사용합니다:

drop_role_statement ::= DROP ROLE [ IF EXISTS ] role_name

DROP ROLE은 클라이언트가 해당 역할에 대한 DROP 권한을 가져야 합니다. 또한 클라이언트는 로그인 시 식별한 역할을 DROP할 수 없습니다. 마지막으로 SUPERUSER 상태의 클라이언트만 다른 SUPERUSER 역할을 DROP할 수 있어요.

존재하지 않는 역할을 삭제하려 하면 IF EXISTS 옵션을 사용하지 않는 한 잘못된 쿼리 조건이 됩니다. 옵션을 사용하고 역할이 존재하지 않으면 문은 no-op입니다.

DROP ROLE은 의도적으로 열려 있는 사용자 세션을 종료하지 않습니다. 현재 연결된 세션은 연결 상태를 유지하고 권한 부여가 필요하지 않은 데이터베이스 동작을 계속 수행할 수 있어요. 하지만 권한 부여가 활성화되면, cassandra.yaml 파일에 구성된 캐싱 옵션에 따라 삭제된 역할의 권한도 취소됩니다. 삭제된 역할이 이후에 재생성되어 새 권한이나 역할이 부여되면, 여전히 연결된 클라이언트 세션은 새로 부여된 권한과 역할을 획득합니다.

GRANT ROLE

역할을 다른 역할에 부여하는 것은 GRANT ROLE 문을 사용합니다:

grant_role_statement ::= GRANT role_name TO role_name

예를 들어:

GRANT report_writer TO alice;

이 문은 report_writer 역할을 alice에 부여합니다. report_writer에 부여된 모든 권한도 alice가 획득합니다.

역할은 방향성 비순환 그래프(directed acyclic graph)로 모델링되므로 순환 부여는 허용되지 않습니다. 다음 예제는 오류 조건이 됩니다:

GRANT role_a TO role_b;
GRANT role_b TO role_a;

GRANT role_a TO role_b;
GRANT role_b TO role_c;
GRANT role_c TO role_a;

REVOKE ROLE

역할 취소는 REVOKE ROLE 문을 사용합니다:

revoke_role_statement ::= REVOKE role_name FROM role_name

예를 들어:

REVOKE report_writer FROM alice;

이 문은 alice로부터 report_writer 역할을 취소합니다. alice가 report_writer 역할을 통해 획득한 모든 권한도 취소됩니다.

LIST ROLES

알려진 모든 역할(시스템의 또는 특정 역할에 부여된)은 LIST ROLES 문으로 나열할 수 있어요:

list_roles_statement ::= LIST ROLES [ OF role_name] [ NORECURSIVE ]

예를 들어:

LIST ROLES;

시스템의 모든 알려진 역할을 반환하며, 이는 데이터베이스 역할 리소스에 대한 DESCRIBE 권한이 필요합니다.

이 예제는 alice에게 부여된 모든 역할을, 전이적으로 획득한 것들을 포함해 나열합니다:

LIST ROLES OF alice;

이 예제는 bob에게 직접 부여된 역할만, 전이적으로 획득한 것을 포함하지 않고 나열합니다:

LIST ROLES OF bob NORECURSIVE;

사용자 (Users)

Cassandra 2.2에서 역할이 도입되기 전에는 인증과 권한 부여가 USER라는 개념을 기반으로 했어요. 하위 호환성을 위해 기존 문법이 보존되었으며 USER 중심 문이 역할 기반의 동등 표현의 동의어가 됩니다. 즉 사용자 생성/업데이트는 역할 생성/업데이트의 다른 문법일 뿐입니다.

CREATE USER

사용자 만들기는 CREATE USER 문을 사용합니다:

create_user_statement ::= CREATE USER [ IF NOT EXISTS ] role_name
                          [ WITH [ HASHED ] PASSWORD string ]
                          [ user_option ]
user_option: SUPERUSER | NOSUPERUSER

예를 들어:

CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE USER bob WITH PASSWORD 'password_b' NOSUPERUSER;
CREATE USER bob WITH HASHED PASSWORD '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG' NOSUPERUSER;

CREATE USER 명령은 LOGIN 옵션이 true인 CREATE ROLE과 동등합니다. 따라서 다음 문 쌍은 동등합니다:

CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;

CREATE USER IF NOT EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE IF NOT EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;

CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = false;

CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;

CREATE USER alice WITH PASSWORD 'password_a';
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;

CREATE ROLE rob WITH LOGIN = true and PASSWORD = 'password_c' AND ACCESS FROM ALL CIDRS;
CREATE ROLE hob WITH LOGIN = true and PASSWORD = 'password_d' AND ACCESS FROM CIDRS { 'region1' };

ALTER USER

사용자 옵션 변경은 ALTER USER 문을 사용합니다:

alter_user_statement ::= ALTER USER [ IF EXISTS ] role_name [ WITH [ HASHED ] PASSWORD string] [ user_option]

역할이 존재하지 않으면 IF EXISTS를 사용하지 않는 한 문은 오류를 반환하며, 사용하면 연산이 no-op입니다. 예를 들어:

ALTER USER alice WITH PASSWORD 'PASSWORD_A';
ALTER USER alice WITH HASHED PASSWORD '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
ALTER USER bob SUPERUSER;

DROP USER

사용자 삭제는 DROP USER 문을 사용합니다:

drop_user_statement ::= DROP USER [ IF EXISTS ] role_name

LIST USERS

기존 사용자는 LIST USERS 문으로 나열할 수 있어요:

list_users_statement::= LIST USERS

이 문은 LIST ROLES와 동등하지만, LOGIN 권한이 있는 역할만 출력에 포함된다는 점을 유의하세요.

데이터 제어 (Data Control)

권한 (Permissions)

리소스에 대한 권한은 역할에 부여됩니다. Cassandra에는 여러 유형의 리소스가 있고, 각 유형은 계층적으로 모델링됩니다:

• Data 리소스(키스페이스와 테이블)의 계층은 ALL KEYSPACES → KEYSPACE → TABLE 구조를 갖습니다.
• 함수 리소스는 ALL FUNCTIONS → KEYSPACE → FUNCTION 구조를 갖습니다.
• 역할을 나타내는 리소스는 ALL ROLES → ROLE 구조를 갖습니다.
• MBeans/MXBeans 집합에 매핑되는 JMX ObjectName을 나타내는 리소스는 ALL MBEANS → MBEAN 구조를 갖습니다.

권한은 이 계층의 어떤 수준에서든 부여될 수 있고 아래로 흐릅니다. 즉 체인의 더 높은 리소스에 권한을 부여하면 그 아래의 모든 리소스에 자동으로 같은 권한이 부여됩니다. 예를 들어 KEYSPACE에 SELECT를 부여하면 그 KEYSPACE의 모든 TABLES에 자동으로 부여됩니다. 마찬가지로 ALL FUNCTIONS에 권한을 부여하면, 어느 키스페이스에 범위가 있든 모든 정의된 함수에 부여됩니다. 특정 키스페이스에 범위가 있는 모든 함수에 권한을 부여하는 것도 가능합니다.

권한에 대한 수정은 기존 클라이언트 세션에 표시됩니다. 즉 권한 변경 후 연결을 다시 설정할 필요가 없습니다.

사용 가능한 전체 권한 집합은:

• CREATE
• ALTER
• DROP
• SELECT
• MODIFY
• AUTHORIZE
• DESCRIBE
• EXECUTE
• UNMASK
• SELECT_MASKED

모든 권한이 모든 리소스 유형에 적용되는 것은 아닙니다. 예를 들어 EXECUTE는 함수 또는 mbean의 맥락에서만 관련이 있습니다. 테이블을 나타내는 리소스에 EXECUTE를 부여하는 것은 무의미합니다. 적용할 수 없는 리소스에 권한을 GRANT하려 하면 오류 응답이 발생합니다. 다음은 어떤 권한을 어떤 리소스 유형에 부여할 수 있는지, 그리고 그 권한이 어떤 문을 활성화하는지 보여줍니다.

권한	리소스	연산
CREATE	ALL KEYSPACES	모든 키스페이스에서 CREATE KEYSPACE 및 CREATE TABLE
CREATE	KEYSPACE	지정된 키스페이스에서 CREATE TABLE
CREATE	ALL FUNCTIONS	모든 키스페이스에서 CREATE FUNCTION 및 모든 키스페이스에서 CREATE AGGREGATE
CREATE	ALL FUNCTIONS IN KEYSPACE	지정된 키스페이스에서 CREATE FUNCTION 및 CREATE AGGREGATE
CREATE	ALL ROLES	CREATE ROLE
ALTER	ALL KEYSPACES	모든 키스페이스에서 ALTER KEYSPACE 및 ALTER TABLE
ALTER	KEYSPACE	지정된 키스페이스에서 ALTER KEYSPACE 및 ALTER TABLE
ALTER	TABLE	ALTER TABLE
ALTER	ALL FUNCTIONS	기존 것 대체: CREATE FUNCTION 및 CREATE AGGREGATE
ALTER	ALL FUNCTIONS IN KEYSPACE	지정된 키스페이스에서 기존 것 대체: CREATE FUNCTION 및 CREATE AGGREGATE
ALTER	FUNCTION	기존 것 대체: CREATE FUNCTION 및 CREATE AGGREGATE
ALTER	ALL ROLES	모든 역할에 대한 ALTER ROLE
ALTER	ROLE	ALTER ROLE
DROP	ALL KEYSPACES	모든 키스페이스에서 DROP KEYSPACE 및 DROP TABLE
DROP	KEYSPACE	지정된 키스페이스에서 DROP TABLE
DROP	TABLE	DROP TABLE
DROP	ALL FUNCTIONS	모든 키스페이스에서 DROP FUNCTION 및 DROP AGGREGATE
DROP	ALL FUNCTIONS IN KEYSPACE	지정된 키스페이스에서 DROP FUNCTION 및 DROP AGGREGATE
DROP	FUNCTION	DROP FUNCTION
DROP	ALL ROLES	모든 역할에 대한 DROP ROLE
DROP	ROLE	DROP ROLE
SELECT	ALL KEYSPACES	모든 테이블에서 SELECT
SELECT	KEYSPACE	지정된 키스페이스의 모든 테이블에서 SELECT
SELECT	TABLE	지정된 테이블에서 SELECT
SELECT	ALL MBEANS	모든 mbean에서 getter 메서드 호출
SELECT	MBEANS	와일드카드 패턴과 일치하는 모든 mbean에서 getter 메서드 호출
SELECT	MBEAN	이름이 지정된 mbean에서 getter 메서드 호출
MODIFY	ALL KEYSPACES	모든 테이블에서 INSERT, UPDATE, DELETE 및 TRUNCATE
MODIFY	KEYSPACE	지정된 키스페이스의 모든 테이블에서 INSERT, UPDATE, DELETE 및 TRUNCATE
MODIFY	TABLE	지정된 테이블에서 INSERT, UPDATE, DELETE 및 TRUNCATE
MODIFY	ALL MBEANS	모든 mbean에서 setter 메서드 호출
MODIFY	MBEANS	와일드카드 패턴과 일치하는 모든 mbean에서 setter 메서드 호출
MODIFY	MBEAN	이름이 지정된 mbean에서 setter 메서드 호출
AUTHORIZE	ALL KEYSPACES	모든 테이블에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	KEYSPACE	지정된 키스페이스의 모든 테이블에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	TABLE	지정된 테이블에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	ALL FUNCTIONS	모든 함수에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	ALL FUNCTIONS IN KEYSPACE	지정된 키스페이스에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	FUNCTION	지정된 함수에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	ALL MBEANS	모든 mbean에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	MBEANS	와일드카드 패턴과 일치하는 모든 mbean에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	MBEAN	이름이 지정된 mbean에서 GRANT PERMISSION 및 REVOKE PERMISSION
AUTHORIZE	ALL ROLES	모든 역할에서 GRANT ROLE 및 REVOKE ROLE
AUTHORIZE	ROLES	지정된 역할에서 GRANT ROLE 및 REVOKE ROLE
DESCRIBE	ALL ROLES	모든 역할 또는 다른 지정된 역할에 부여된 역할만에 대한 LIST ROLES
DESCRIBE	ALL MBEANS	플랫폼의 MBeanServer에서 모든 mbean에 대한 메타데이터 검색
DESCRIBE	MBEANS	플랫폼의 MBeanServer에서 와일드카드 패턴과 일치하는 mbean에 대한 메타데이터 검색
DESCRIBE	MBEAN	플랫폼의 MBeanServer에서 이름이 지정된 mbean에 대한 메타데이터 검색
EXECUTE	ALL FUNCTIONS	어떤 함수를 사용한 SELECT, INSERT, UPDATE 및 CREATE AGGREGATE에서 함수 사용
EXECUTE	ALL FUNCTIONS IN KEYSPACE	지정된 키스페이스의 어떤 함수를 사용한 SELECT, INSERT, UPDATE 및 CREATE AGGREGATE에서 함수 사용
EXECUTE	FUNCTION	지정된 함수를 사용한 SELECT, INSERT, UPDATE 및 CREATE AGGREGATE에서 함수 사용
EXECUTE	ALL MBEANS	모든 mbean에서 연산 실행
EXECUTE	MBEANS	와일드카드 패턴과 일치하는 모든 mbean에서 연산 실행
EXECUTE	MBEAN	이름이 지정된 mbean에서 연산 실행
UNMASK	ALL KEYSPACES	모든 테이블에서 마스킹된 컬럼의 명확한 내용 보기
UNMASK	KEYSPACE	키스페이스의 모든 테이블에서 마스킹된 컬럼의 명확한 내용 보기
UNMASK	TABLE	지정된 테이블에서 마스킹된 컬럼의 명확한 내용 보기
SELECT_MASKED	ALL KEYSPACES	모든 테이블에서 마스킹된 컬럼을 제한하는 SELECT
SELECT_MASKED	KEYSPACE	지정된 키스페이스의 모든 테이블에서 마스킹된 컬럼을 제한하는 SELECT
SELECT_MASKED	TABLE	지정된 테이블에서 마스킹된 컬럼을 제한하는 SELECT

GRANT PERMISSION

권한 부여는 GRANT PERMISSION 문을 사용합니다:

grant_permission_statement ::= GRANT permissions ON resource TO role_name
permissions ::= ALL [ PERMISSIONS ] | permission [ PERMISSION ]
permission ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE | EXECUTE | UNMASK | SELECT_MASKED
resource ::=    ALL KEYSPACES
                | KEYSPACE keyspace_name
                | [ TABLE ] table_name
                | ALL ROLES
                | ROLE role_name
                | ALL FUNCTIONS [ IN KEYSPACE keyspace_name ]
                | FUNCTION function_name '(' [ cql_type( ',' cql_type )* ] ')'
                | ALL MBEANS
                | ( MBEAN | MBEANS ) string

예를 들어:

GRANT SELECT ON ALL KEYSPACES TO data_reader;

이 예제는 data_reader 역할을 가진 어떤 사용자에게도 모든 키스페이스의 모든 테이블에서 SELECT 문을 실행할 권한을 부여합니다:

GRANT MODIFY ON KEYSPACE keyspace1 TO data_writer;

data_writer 역할을 가진 어떤 사용자에게도 keyspace1 키스페이스의 모든 테이블에서 UPDATE, INSERT, DELETE, TRUNCATE 쿼리를 수행할 권한을 부여하려면:

GRANT DROP ON keyspace1.table1 TO schema_owner;

schema_owner 역할을 가진 어떤 사용자에게도 특정 keyspace1.table1을 DROP할 권한을 부여하려면:

GRANT EXECUTE ON FUNCTION keyspace1.user_function( int ) TO report_writer;

이 명령은 report_writer 역할을 가진 어떤 사용자에게도 keyspace1.user_function( int ) 함수를 사용하는 SELECT, INSERT, UPDATE 쿼리를 실행할 권한을 부여합니다:

GRANT DESCRIBE ON ALL ROLES TO role_admin;

이것은 role_admin 역할을 가진 어떤 사용자에게도 LIST ROLES 문으로 시스템의 모든 역할을 보는 권한을 부여합니다.

GRANT ALL

GRANT ALL 형식을 사용하면 대상 리소스에 기반해 적절한 권한 집합이 자동으로 결정됩니다.

자동 부여 (Automatic Granting)

CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION, CREATE AGGREGATE, CREATE ROLE 문으로 리소스가 생성되면, 생성자(문을 발행한 데이터베이스 사용자가 식별되는 역할)는 새 리소스에 적용 가능한 모든 권한을 자동으로 부여받습니다.

REVOKE PERMISSION

역할로부터 권한을 취소하는 것은 REVOKE PERMISSION 문을 사용합니다:

revoke_permission_statement ::= REVOKE permissions ON resource FROM role_name

예를 들어:

REVOKE SELECT ON ALL KEYSPACES FROM data_reader;
REVOKE MODIFY ON KEYSPACE keyspace1 FROM data_writer;
REVOKE DROP ON keyspace1.table1 FROM schema_owner;
REVOKE EXECUTE ON FUNCTION keyspace1.user_function( int ) FROM report_writer;
REVOKE DESCRIBE ON ALL ROLES FROM role_admin;

일반 드라이버 연산에서의 역할 때문에 특정 테이블은 SELECT 권한을 취소할 수 없습니다. 다음 테이블은 할당된 역할과 관계없이 모든 권한 있는 사용자에게 사용 가능합니다:

* system_schema.keyspaces
* system_schema.columns
* system_schema.tables
* system.local
* system.peers

LIST PERMISSIONS

부여된 권한 나열은 LIST PERMISSIONS 문을 사용합니다:

list_permissions_statement ::= LIST permissions [ ON resource] [ OF role_name[ NORECURSIVE ] ]

예를 들어:

LIST ALL PERMISSIONS OF alice;

alice에게 부여된 모든 권한을, 다른 역할로부터 전이적으로 획득한 것을 포함해 보여줍니다:

LIST ALL PERMISSIONS ON keyspace1.table1 OF bob;

bob에게 부여된 keyspace1.table1에 대한 모든 권한을, 다른 역할로부터 전이적으로 획득한 것을 포함해 보여줍니다. 이는 keyspace1.table1에 적용될 수 있는 리소스 계층 위쪽의 권한도 포함해요. 예를 들어 bob이 keyspace1에 ALTER 권한이 있으면 그 결과가 포함됩니다. NORECURSIVE 스위치를 추가하면 결과를 bob에게 직접 부여되거나 bob의 역할 중 하나에 직접 부여된 권한으로만 제한합니다:

LIST SELECT PERMISSIONS OF carlos;

carlos에게 부여되거나 carlos에 할당된 역할에 부여된 권한을, 어떤 리소스에서든 SELECT 권한으로 제한해 보여줍니다.

더 알아보기 (Learn more)

• 보안(운영) — 인증·권한 부여 구성
• cassandra.yaml 설정 — role/cidr 관련 설정