쿼리 권한

쿼리 권한 (Permissions for queries)

ClickHouse의 쿼리는 여러 유형으로 나눌 수 있고, 설정을 통해 쿼리 유형별로 사용자 권한을 규제할 수 있어요. 여기서는 readonly와 allow_ddl이 어떤 쿼리 클래스를 허용/차단하는지 자세히 설명해 드릴게요.

출처: 문서

본문

ClickHouse의 쿼리는 여러 유형으로 나눌 수 있어요:

  1. 데이터 읽기 쿼리: SELECT, SHOW, DESCRIBE, EXISTS.
  2. 데이터 쓰기 쿼리: INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE.
  3. 설정 변경 쿼리: SET, USE.
  4. DDL 쿼리: CREATE, ALTER, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE.
  5. 접근 관리 쿼리: GRANT, REVOKE, 그리고 사용자, 역할, 행 정책(Row Policies), 마스킹 정책(Masking Policies), 할당량(Quotas), 설정 프로필(Settings Profiles)의 CREATE, ALTER, DROP. 자세한 내용은 접근 제어 및 계정 관리를 참고해요.
  6. KILL QUERY.

ALTER TABLE ... DELETE와 ALTER TABLE ... UPDATE는 테이블 메타데이터가 아니라 데이터를 변경하기 때문에 위에서 쓰기 데이터 쿼리로 분류했어요. 이들은 ALTER DELETE와 ALTER UPDATE 권한이 필요한데, 이는 독립형 DELETE와 UPDATE 문도 요구하는 권한이에요. 이 권한들은 ALTER TABLE 권한 그룹에 속하므로, allow_ddl = 0이면 영구 테이블에 대한 네 가지 문을 모두 거부해요.

다음 설정들이 쿼리 유형별로 사용자 권한을 규제해요:

readonly

세션이 실행할 수 있는 쿼리를 제한해요. 설정값, 기본값, 그리고 각 값에서 변경할 수 있는 설정은 설정 레퍼런스에 설명되어 있어요. 여기서는 각 값이 어떤 쿼리 클래스를 허용하는지 설명할게요.

1로 설정하면 다음과 같은 쿼리를 허용해요:

  • 읽기 쿼리(SELECT 및 이와 동등한 쿼리).
  • 세션 컨텍스트만 수정하는 쿼리(USE).

2로 설정하면 위에 더해 SET, CREATE TEMPORARY TABLE, RESTORE를 허용해요. RESTORE는 테이블을 만들고 그 안에 데이터를 로드할 수 있으므로, readonly = 2는 세션이 쓰기 작업을 하지 못하게 막지는 못해요. readonly = 1은 이를 거부해요.

BACKUP은 어떤 값에서도 readonly의 제한을 받지 않아요. 테이블을 백업할 권한이 있는 세션은 readonly = 1에서도 백업을 쓸 수 있어요. 백업을 막기 위해 readonly에 의존하지 마세요.

대부분의 테이블 함수는 CREATE TEMPORARY TABLE 권한이 필요하므로, 그중 하나에서 읽는 SELECT는 readonly = 1에서 거부되지만 readonly = 2에서는 거부되지 않아요. numbers 같은 일부 함수는 읽기 전용 모드에서 허용돼요.

0보다 큰 어떤 값에서도 영구 테이블에 대해 다음 중 어느 것도 허용되지 않아요: 쓰기 데이터 쿼리(INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE) 또는 DDL 쿼리(CREATE, ALTER TABLE, ALTER VIEW, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE TABLE). SYSTEM 그룹에서 권한이 필요한 SYSTEM 문, 그리고 사용자, 역할, 행 정책, 마스킹 정책, 할당량, 설정 프로필의 CREATE, ALTER, DROP도 허용되지 않아요. 명명된 컬렉션(Named Collection) 관리는 예외예요. readonly는 CREATE NAMED COLLECTION, ALTER NAMED COLLECTION, DROP NAMED COLLECTION를 제한하지 않아요.

GRANT로 권한을 부여하는 것도 거부되지만, 모든 접근 관리 문이 그런 건 아니에요. 로컬 REVOKE와 GRANT CURRENT GRANTS는 readonly의 제한을 받지 않으므로, 읽기 전용 세션도 grant option으로 보유한 권한을 회수하고 자신의 권한을 다른 사용자에게 전파할 수 있어요. ON CLUSTER로 권한을 회수하는 것은 거부돼요.

임시 테이블은 두 설정 모두에서 제외돼요. 임시 테이블을 만들 수 있는 세션은 그것을 ALTER하고, insert하고, drop할 수도 있어요.

참고: HTTP 인터페이스에서 메서드가 POST가 아닌 요청은, 유효값이 그렇지 않으면 0일 때 readonly = 2로 실행돼요. 사용자의 설정이나 설정 프로필로 이미 더 엄격한 값이 설정된 경우 그 값이 유지돼요. PUT과 DELETE는 SQL로 정의된 핸들러에 도달해서 허용되면 예외적으로, 유효 readonly가 0일 때 데이터를 수정할 수 있어요. 그렇지 않으면 데이터를 수정하려면 POST 메서드를 사용해야 해요. 이렇게 올려진 요청에서 쿼리 문자열의 readonly 파라미터는, 요청이 이미 가진 값과 같은 값을 명명하지 않는 한 Cannot modify 'readonly' setting in readonly mode로 거부돼요. 특정 설정만 변경하지 못하게 하는 방법과, readonly = 1 제한 아래에서 특정 설정만 변경할 수 있게 하는 방법이 있어요. 자세한 내용은 설정에 대한 제약(constraints on settings)을 참고하며, 여기서는 읽기 전용 모드에서 readonly 설정 자체를 변경 가능하게 만들지 말 것을 권고해요.

allow_ddl

데이터베이스, 테이블, 뷰, 딕셔너리, 사용자 정의 함수, 워크로드, 리소스 및 SQL로 정의된 핸들러에 대한 DDL 쿼리를 허용하거나 거부해요.

가능한 값:

  • 0 — 다음 권한 중 하나라도 필요로 하는 영구 객체에 대한 쿼리 실행이 차단돼요: CREATE DATABASE, DROP DATABASE, CREATE TABLE, CREATE VIEW, ALTER TABLE, ALTER VIEW, DROP TABLE, DROP VIEW, TRUNCATE, CREATE DICTIONARY, DROP DICTIONARY, CREATE FUNCTION, DROP FUNCTION, CREATE WORKLOAD, DROP WORKLOAD, CREATE RESOURCE, DROP RESOURCE, CREATE HANDLER, ALTER HANDLER, DROP HANDLER. RENAME, EXCHANGE, ATTACH, DETACH도 이 권한들이 필요하므로 함께 차단되지만, ALTER TABLE ... ATTACH PARTITION과 ATTACH PART는 INSERT만 필요하고 이 설정에 의해 차단되지 않아요(단, readonly는 영구 테이블에서 이들을 차단해요). ATTACH PARTITION ... FROM은 ALTER DELETE도 필요하므로 차단돼요. 이 권한들의 부여(grant)와 회수(revoke)는 차단되지 않아요.
  • 1 — 이 설정으로는 아무것도 차단되지 않아요.

기본값: 1

참고: 현재 세션에서 allow_ddl = 0일 때 SET allow_ddl = 1을 실행할 수 없어요. allow_ddl은 접근 관리 쿼리를 제한하지 않아요. GRANT, REVOKE 및 사용자, 역할, 행 정책, 마스킹 정책, 할당량, 설정 프로필의 CREATE, ALTER, DROP에는 영향을 주지 않아요. CREATE TEMPORARY TABLE과 명명된 컬렉션 관리, 그리고 readonly도 제한하지 않는 ALTER DATABASE ... MODIFY SETTING, ALTER DATABASE ... MODIFY COMMENT, UNDROP TABLE도 영향을 받지 않아요. 사용자, 역할 또는 설정 프로필의 CREATE 또는 ALTER 내부에서, 현재 세션의 allow_ddl = 0이면 SETTINGS allow_ddl = 1 절은 거부되고 SETTINGS allow_ddl = 0 절은 허용돼요. 임베디드 설정은 세션 자신의 설정 제약과 대조해 검사되며, 이것이 SET allow_ddl = 1도 거부되는 이유예요.

정보: KILL QUERY — 자신의 쿼리를 종료하는 것은 KILL QUERY 권한이 필요 없으므로 readonly와 allow_ddl의 어떤 조합에서도 동작해요. 단, system.processes에 대한 SELECT가 필요해요. KILL QUERY WHERE query_id = '<id>'는 그 테이블을 읽지 않고 그 id를 가진 자신의 쿼리를 취소하므로 예외예요. 다른 사용자에게 속한 쿼리를 종료하거나 KILL QUERY ... ON CLUSTER를 실행하는 것은 KILL QUERY 권한이 필요하며, readonly = 1과 readonly = 2는 이를 거부해요.

기타 관련 설정 (Other relevant settings)

  • allow_introspection_functions은 readonly와 allow_ddl과 함께 권한 결정 자체에 참여하는 세 번째 설정이에요. 비활성화되면 인트로스펙션(introspection) 함수 실행이 차단돼요. INTROSPECTION 권한 부여는 차단되지 않아요.
  • allow_non_metadata_alters는 권한 설정은 아니지만 ALTER TABLE을 더 제한해요. 비활성화되면, 테이블 정의를 변경하는 명령을 적용했을 때 디스크의 데이터를 다시 쓰게 된다면(DROP COLUMN, RENAME COLUMN, MODIFY COLUMN 타입 변경, MODIFY TTL) MergeTree 계열 테이블에서 그 명령이 거부돼요. CLEAR COLUMN, CLEAR INDEX, CLEAR PROJECTION도 정의를 변경하지 않지만 거부돼요. ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE, ALTER TABLE ... MATERIALIZE INDEX처럼 그 자체가 뮤테이션(mutation)인 문은 영향을 받지 않아요.

더 알아보기 (Learn more)