File-based access control

File-based access control (파일 기반 접근 제어)

직접 구성한 JSON 파일에 정의된 규칙으로 데이터 접근을 제어하는 파일 기반 접근 제어를 설명해요. 시스템 수준과 카탈로그 수준, 두 가지 방식으로 나뉘어요.

출처: 문서

본문

클러스터의 데이터 접근을 보호하려면 수동으로 구성한 JSON 파일에 선언된 규칙으로 데이터와 연산에 대한 접근을 정의하는 파일 기반 접근 제어를 구현할 수 있어요.

파일 기반 접근 제어에는 두 가지 유형이 있어요:

• 시스템 수준 접근 제어 (System-level access control): 전체 클러스터에 대한 인가 규칙을 지정하는 단일 JSON 파일을 사용하는 접근 제어 플러그인.
• 카탈로그 수준 접근 제어 (Catalog-level access control): 각 카탈로그에 개별 JSON 파일을 사용해 그 카탈로그의 데이터를 세밀하게 제어하며, 컬럼 수준 인가를 포함해요.

시스템 수준 접근 제어 파일 (System-level access control files)

접근 제어 플러그인을 사용하면 단일 JSON 파일로 클러스터에 대한 인가 규칙을 지정할 수 있어요.

구성 (Configuration)

접근 제어 플러그인을 사용하려면 access-control.name(file로 설정), security.config-file(구성 파일 위치) 두 필수 속성을 담은 etc/access-control.properties 파일을 추가하세요. 구성 파일 위치는 로컬 디스크나 http 엔드포인트를 가리킬 수 있어요. 예를 들어 rules.json이라는 구성 파일이 etc에 있다면 다음 내용으로 etc/access-control.properties를 추가하세요:

access-control.name=file
security.config-file=etc/rules.json

구성이 http 엔드포인트 http://trino-test/config로 로드되어야 하고 JSON 객체로 감싸져 data 키로 사용 가능하다면 etc/access-control.properties는 다음과 같이 보여야 해요:

access-control.name=file
security.config-file=http://trino-test/config
security.json-pointer=/data

구성 파일은 JSON 형식으로 지정돼요. 어떤 사용자가 어떤 리소스에 접근할 수 있는지 정의하는 규칙을 포함해요. 규칙은 위에서 아래로 읽히고 첫 번째로 일치하는 규칙이 적용돼요. 일치하는 규칙이 없으면 접근이 거부돼요. security.json-pointer 속성을 사용해 JSON 내용 안에서 규칙을 담은 중첩 객체를 지정하는 JSON 포인터(RFC 6901)를 지정할 수 있어요. 기본적으로 파일은 규칙을 정의하는 단일 객체를 포함한다고 가정하므로 그 경우 security.json-pointer 지정은 불필요해요.

새로고침 (Refresh)

기본적으로 JSON 규칙 파일에 변경이 생기면 Trino는 변경 사항을 로드하기 위해 재시작해야 해요. Trino 재시작 없이 속성을 새로고침할 수 있는 선택적 속성이 있어요. 새로고침 주기는 etc/access-control.properties에 지정돼요:

security.refresh-period=1s

카탈로그, 스키마, 테이블 접근 (Catalog, schema, and table access)

카탈로그, 스키마, 테이블, 뷰에 대한 접근은 카탈로그·스키마·테이블 규칙으로 제어돼요. 카탈로그 규칙은 카탈로그에 대한 모든 접근이나 쓰기 접근을 제한하는 데 사용하는 거친(coarse-grained) 규칙이에요. 어떤 특정 스키마나 테이블 권한을 명시적으로 부여하지는 않아요. 테이블·스키마 규칙은 스키마와 테이블에 대해 누가 create, drop, alter, select, insert, delete 등을 할 수 있는지 지정하는 데 사용돼요.

각 규칙 집합에 대해 권한은 구성 파일의 위에서 아래로 읽은 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 접근이 거부돼요.

규칙이 전혀 제공되지 않으면 접근이 허용돼요. 특정 수준에서 빈 규칙 집합으로 섹션을 추가해 접근 허용을 제거할 수 있어요. 예:

{
  "schemas": []
}

카탈로그 수준에서는 접근 가능한 각 카탈로그에 대해 단일 "더미" 규칙을 추가해야 해요.

Note

이 규칙들은 information_schema 스키마의 시스템 정의 테이블에는 적용되지 않아요.

다음 표는 각 SQL 명령에 필요한 권한을 요약해요:

SQL command	Catalog	Schema	Table	Note
SHOW CATALOGS				항상 허용됨
SHOW SCHEMAS	read-only	any*	any*	카탈로그가 보이면 허용됨
SHOW TABLES	read-only	any*	any*	스키마가 보이면 허용됨
CREATE SCHEMA	read-only	owner
DROP SCHEMA	all	owner
SHOW CREATE SCHEMA	all	owner
ALTER SCHEMA … RENAME TO	all	owner*		옛 스키마와 새 스키마 모두에 소유권 필요
ALTER SCHEMA … SET AUTHORIZATION	all	owner
CREATE TABLE	all		owner
DROP TABLE	all		owner
ALTER TABLE … RENAME TO	all		owner*	옛 테이블과 새 테이블 모두에 소유권 필요
ALTER TABLE … SET PROPERTIES	all		owner
CREATE VIEW	all		owner
DROP VIEW	all		owner
ALTER VIEW … RENAME TO	all		owner*	옛 뷰와 새 뷰 모두에 소유권 필요
REFRESH MATERIALIZED VIEW	all		update
COMMENT ON TABLE	all		owner
COMMENT ON COLUMN	all		owner
ALTER TABLE … ADD COLUMN	all		owner
ALTER TABLE … DROP COLUMN	all		owner
ALTER TABLE … RENAME COLUMN	all		owner
SHOW COLUMNS	read-only		any
SELECT FROM table	read-only		select
SELECT FROM view	read-only		select, grant_select
INSERT INTO	all		insert
DELETE FROM	all		delete
UPDATE	all		update

함수 실행에 필요한 권한:

SQL command	Catalog	Function permission	Note
SELECT function()		execute, grant_execute*	SECURITY DEFINER 뷰에서 함수를 사용할 때 grant_execute가 필요해요.
CREATE FUNCTION	all	ownership	모든 커넥터가 카탈로그 사용자 정의 함수를 지원하지는 않아요.
DROP FUNCTION	all	ownership	모든 커넥터가 카탈로그 사용자 정의 함수를 지원하지는 않아요.

가시성 (Visibility)

카탈로그, 스키마, 테이블이 SHOW 명령에 보이려면 사용자는 그 항목이나 중첩 항목에 대해 최소 하나의 권한이 있어야 해요. 중첩 항목이 아직 존재하지 않아도 되는데, 잠재적 권한이 있으면 항목이 보이게 되기 때문이에요. 구체적으로:

• catalog: 사용자가 중첩 스키마의 소유자이거나, 중첩 테이블·함수에 권한이 있거나, 카탈로그에서 세션 속성을 설정할 권한이 있으면 보임.
• schema: 사용자가 스키마의 소유자이거나 중첩 테이블·함수에 권한이 있으면 보임.
• table: 사용자가 테이블에 어떤 권한이 있으면 보임.

카탈로그 규칙 (Catalog rules)

각 카탈로그 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.
• allow (필수): 사용자가 카탈로그에 접근할 수 있는지 나타내는 문자열. 값은 all, read-only, none이며 기본값은 none. read-only로 설정하면 read-only 시스템 접근 제어 플러그인과 같은 동작을 해요.

규칙이 적용되려면 사용자 이름이 user 속성에 지정된 정규식과 일치해야 해요.

롤 이름의 경우 현재 활성화된 롤 중 적어도 하나가 role 정규식과 일치하면 규칙이 적용될 수 있어요.

그룹 이름의 경우 이 사용자의 그룹 이름 중 적어도 하나가 group 정규식과 일치하면 규칙이 적용될 수 있어요.

allow의 all 값은 이 규칙이 어떤 식으로든 접근을 제한하지 않지만, 스키마·테이블 규칙은 접근을 제한할 수 있다는 뜻이에요.

Note

기본적으로 모든 사용자는 system 카탈로그에 접근할 수 있어요. 규칙을 추가해 이 동작을 재정의할 수 있어요.

하위 호환성을 위해 allow의 legacy 값으로 boolean true와 false도 지원돼요. true는 all에, false는 none에 매핑돼요.

예를 들어 admin 롤만 mysql과 system 카탈로그에 접근하게, finance와 human_resources 그룹의 사용자는 postgres 카탈로그에 접근하게, 모든 사용자는 hive 카탈로그에 접근하게 하고 다른 모든 접근은 거부하고 싶다면 다음 규칙을 사용할 수 있어요:

{
  "catalogs": [
    {
      "role": "admin",
      "catalog": "(mysql|system)",
      "allow": "all"
    },
    {
      "group": "finance|human_resources",
      "catalog": "postgres",
      "allow": true
    },
    {
      "catalog": "hive",
      "allow": "all"
    },
    {
      "user": "alice",
      "catalog": "postgresql",
      "allow": "read-only"
    },
    {
      "catalog": "system",
      "allow": "none"
    }
  ]
}

그룹 기반 규칙이 일치하려면 사용자가 Group provider에 의해 그룹에 할당되어야 해요.

스키마 규칙 (Schema rules)

각 스키마 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.
• schema (선택): 스키마 이름과 대조할 정규식. 기본값은 .*.
• owner (필수): 사용자가 스키마의 소유자로 간주되는지 여부를 나타내는 불리언. 기본값은 false.

예를 들어 모든 스키마의 소유권을 admin 롤에, default.default 스키마의 소유자를 모든 사용자에게, guest 사용자가 어떤 스키마도 소유하지 못하게 하려면 다음 규칙을 사용할 수 있어요:

{
  "schemas": [
    {
      "role": "admin",
      "schema": ".*",
      "owner": true
    },
    {
      "user": "guest",
      "owner": false
    },
    {
      "catalog": "default",
      "schema": "default",
      "owner": true
    }
  ]
}

테이블 규칙 (Table rules)

각 테이블 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.
• schema (선택): 스키마 이름과 대조할 정규식. 기본값은 .*.
• table (선택): 테이블 이름과 대조할 정규식. 기본값은 .*.
• privileges (필수): SELECT, INSERT, DELETE, UPDATE, OWNERSHIP, GRANT_SELECT 중 0개 이상.
• columns (선택): 컬럼 제약 목록.
• filter (선택): 테이블에 대한 boolean 필터 표현식.
• filter_environment (선택): 필터 평가 중 사용되는 환경.

컬럼 제약 (Column constraint)

이 제약들은 컬럼 데이터에 대한 접근을 제한하는 데 사용할 수 있어요.

• name: 컬럼 이름.
• allow (선택): false이면 컬럼에 접근할 수 없음.
• mask (선택): 컬럼에 적용하는 마스크 표현식.
• mask_environment (선택): 마스크 평가 중 사용되는 환경.

필터 및 마스크 환경 (Filter and mask environment)

• user (선택): 마스크의 서브쿼리 권한을 확인하는 사용자 이름.

Note

이 규칙들은 information_schema에는 적용되지 않아요.

mask는 IF나 CASE 같은 조건 표현식을 포함할 수 있으며, 이로써 조건부 마스킹을 달성해요.

아래 예시는 다음 테이블 접근 정책을 정의해요:

• admin 롤은 모든 테이블·스키마에 걸쳐 모든 권한을 가짐
• banned_user 사용자는 권한이 없음
• 모든 사용자는 default.hr.employees에 대해 SELECT 권한을 가지지만, 테이블은 현재 사용자의 행으로만 필터링됨
• 모든 사용자는 default.default 스키마의 모든 테이블에 대해 SELECT 권한을 가지지만, 차단된 address 컬럼과 마스킹된 ssn 컬럼은 예외

{
  "tables": [
    {
      "role": "admin",
      "privileges": ["SELECT", "INSERT", "DELETE", "UPDATE", "OWNERSHIP"]
    },
    {
      "user": "banned_user",
      "privileges": []
    },
    {
      "catalog": "default",
      "schema": "hr",
      "table": "employee",
      "privileges": ["SELECT"],
      "filter": "user = current_user",
      "filter_environment": {
        "user": "system_user"
      }
    },
    {
      "catalog": "default",
      "schema": "default",
      "table": ".*",
      "privileges": ["SELECT"],
      "columns" : [
         {
            "name": "address",
            "allow": false
         },
         {
            "name": "SSN",
            "mask": "'XXX-XX-' + substring(credit_card, -4)",
            "mask_environment": {
              "user": "system_user"
            }
         }
      ]
    }
  ]
}

함수 규칙 (Function rules)

이 규칙들은 사용자가 함수를 생성·삭제·실행할 수 있는 능력을 제어해요.

이 규칙들이 존재하면 인가는 위에서 아래로 처리되는 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 인가가 거부돼요. 함수 규칙이 존재하지 않으면 system.builtin의 함수만 실행할 수 있어요.

Note

사용자는 항상 system.builtin 스키마의 함수에 접근할 수 있으며, 규칙을 추가해 이 동작을 재정의할 수 없어요.

각 함수 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.
• schema (선택): 스키마 이름과 대조할 정규식. 기본값은 .*.
• function (선택): 함수 이름과 대조할 정규식. 기본값은 .*.
• privileges (필수): EXECUTE, GRANT_EXECUTE, OWNERSHIP 중 0개 이상.

카탈로그의 system 스키마는 Trino가 query 같은 테이블 함수에 사용하는 스키마이므로 이 스키마에 권한을 부여할 때는 주의해야 해요. 이런 테이블 함수는 카탈로그의 기본 데이터에 접근하거나 수정하는 데 사용될 수 있어요.

다음 예시는 admin 사용자가 어떤 카탈로그에서도 system.query 테이블 함수를 실행할 수 있게 하고, 모든 사용자가 hive.function 스키마에서 함수를 생성·삭제·실행(SECURITY DEFINER 뷰 포함)할 수 있게 해요:

{
  "functions": [
    {
      "user": "admin",
      "schema": "system",
      "function": "query",
      "privileges": [
        "EXECUTE"
      ]
    },
    {
      "catalog": "hive",
      "schema": "function",
      "privileges": [
        "EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"
      ]
    }
  ]
}

프로시저 규칙 (Procedure rules)

이 규칙들은 사용자가 CALL 문장으로 프로시저를 실행할 수 있는 능력을 제어해요.

프로시저는 외부 테이블 등록이나 커넥터의 캐시 flush 같은 특정 카탈로그에 대한 관리 연산에 사용돼요. 사용 가능한 프로시저는 커넥터 문서 페이지에 자세히 설명돼 있어요.

프로시저 규칙이 존재하면 인가는 위에서 아래로 처리되는 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 인가가 거부돼요. 프로시저 규칙이 존재하지 않으면 system.builtin의 프로시저만 실행할 수 있어요.

각 프로시저 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.
• schema (선택): 스키마 이름과 대조할 정규식. 기본값은 .*.
• procedure (선택): 프로시저 이름과 대조할 정규식. 기본값은 .*.
• privileges (필수): EXECUTE, GRANT_EXECUTE 중 0개 이상.

다음 예시는 admin 사용자가 Delta Lake 커넥터를 사용하는 delta라는 카탈로그의 system 스키마에서 register_table과 unregister_table을 호출하고 실행 권한을 부여할 수 있게 해요. 모든 사용자가 delta.sytem.vacuum 프로시저를 실행할 수 있게 해요.

{
  "procedures": [
    {
      "user": "admin",
      "catalog": "delta",
      "schema": "system",
      "procedure": "register_table|unregister_table",
      "privileges": [
        "EXECUTE",
        "GRANT_EXECUTE"
      ]
    },
    {
      "catalog": "delta",
      "schema": "system",
      "procedure": "vacuum",
      "privileges": [
        "EXECUTE"
      ]
    }
  ]
}

테이블 프로시저 규칙 (Table procedure rules)

테이블 프로시저는 ALTER TABLE … EXECUTE 구문으로 실행돼요.

파일 기반 접근 제어는 테이블 프로시저에 대한 권한을 지원하지 않으므로 실질적으로 모두 허용돼요.

구성 확인 (Verify configuration)

시스템 접근 제어 파일이 제대로 구성되었는지 확인하려면 규칙을 시스템의 모든 사용자 접근을 완전히 차단하도록 설정해 보세요:

{
  "catalogs": [
    {
      "catalog": "system",
      "allow": "none"
    }
  ]
}

규칙을 활성화하려면 클러스터를 재시작하세요. Trino CLI로 인가를 테스트하는 쿼리를 실행해 보세요:

trino> SELECT * FROM system.runtime.nodes;

Query 20200824_183358_00000_c62aw failed: Access Denied: Cannot access catalog system

이 규칙들을 제거하고 Trino 클러스터를 재시작하세요.

세션 속성 규칙 (Session property rules)

이 규칙들은 사용자가 시스템·카탈로그 세션 속성을 설정할 수 있는 능력을 제어해요. 사용자는 위에서 아래로 읽은 첫 번째 일치 규칙에 기반해 접근이 허용되거나 거부돼요. 규칙이 지정되지 않으면 모든 사용자가 어떤 세션 속성이든 설정할 수 있어요. 일치하는 규칙이 없으면 세션 속성 설정이 거부돼요. 시스템 세션 속성 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• property (선택): 속성 이름과 대조할 정규식. 기본값은 .*.
• allow (필수): 세션 속성 설정이 허용되어야 하는지 여부를 나타내는 불리언.

카탈로그 세션 속성 규칙에는 추가 필드가 있어요:

• catalog (선택): 카탈로그 이름과 대조할 정규식. 기본값은 .*.

아래 예시는 다음 접근 정책을 정의해요:

• admin 롤은 모든 세션 속성을 설정할 수 있음
• banned_user 사용자는 어떤 세션 속성도 설정할 수 없음
• 모든 사용자는 resource_overcommit 시스템 세션 속성과 hive 카탈로그의 bucket_execution_enabled 세션 속성을 설정할 수 있음

{
    "system_session_properties": [
        {
            "role": "admin",
            "allow": true
        },
        {
            "user": "banned_user",
            "allow": false
        },
        {
            "property": "resource_overcommit",
            "allow": true
        }
    ],
    "catalog_session_properties": [
        {
            "role": "admin",
            "allow": true
        },
        {
            "user": "banned_user",
            "allow": false
        },
        {
            "catalog": "hive",
            "property": "bucket_execution_enabled",
            "allow": true
        }
    ]
}

쿼리 규칙 (Query rules)

이 규칙들은 사용자가 쿼리를 실행·조회·종료할 수 있는 능력을 제어해요. 사용자는 위에서 아래로 읽은 첫 번째 일치 규칙에 기반해 접근이 허용되거나 거부돼요. 규칙이 지정되지 않으면 모든 사용자가 쿼리를 실행하고 어떤 사용자가 소유한 쿼리든 조회·종료할 수 있어요. 일치하는 규칙이 없으면 쿼리 관리가 거부돼요. 각 규칙은 다음 필드로 구성돼요:

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• role (선택): 롤 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• queryOwner (선택): 쿼리 소유자 이름과 대조할 정규식. 기본값은 .*.
• allow (필수): 사용자에게 부여된 쿼리 권한 집합. 값: execute, view, kill.

Note

사용자는 항상 자신의 쿼리를 조회·종료할 권한이 있어요.

queryOwner를 포함하는 규칙은 execute 접근 모드를 포함할 수 없어요. 쿼리는 실행이 시작된 후에만 사용자가 소유해요.

예를 들어 admin 롤에 전체 쿼리 접근을 허용하고, alice 사용자에게 쿼리 실행·종료를 허용하며, contractors 그룹 멤버가 alice나 dave가 소유한 쿼리를 조회하도록 하고, 어떤 사용자든 쿼리를 실행하도록 하며 다른 모든 접근을 거부하고 싶다면 다음 규칙을 사용할 수 있어요:

{
  "queries": [
    {
      "role": "admin",
      "allow": ["execute", "kill", "view"]
    },
    {
      "user": "alice",
      "allow": ["execute", "kill"]
    },
    {
      "group": "contractors",
      "queryOwner": "alice|dave",
      "allow": ["view"]
    },
    {
      "allow": ["execute"]
    }
  ]
}

가장 규칙 (Impersonation rules)

이 규칙들은 한 사용자가 다른 사용자를 가장(impersonate)할 수 있는 능력을 제어해요. 어떤 환경에서는 관리자(또는 관리 시스템)가 다른 사용자를 대신해 쿼리를 실행하는 것이 바람직해요. 이런 경우 관리자는 자신의 자격 증명으로 인증하고 다른 사용자로 쿼리를 제출해요. 사용자 컨텍스트가 바뀌면 Trino는 관리자가 대상 사용자로 쿼리를 실행할 권한이 있는지 확인해요.

이 규칙들이 존재하면 인가는 위에서 아래로 처리되는 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 인가가 거부돼요. 가장 규칙이 존재하지 않지만 레거시 principal 규칙이 지정되어 있으면 가장 접근 제어가 principal 규칙으로 처리된다고 가정해 가장이 허용돼요. 가장 규칙도 principal 규칙도 정의되지 않으면 가장이 허용되지 않아요.

각 가장 규칙은 다음 필드로 구성돼요:

• original_user (선택): 가장을 요청하는 사용자와 대조할 정규식. 기본값은 .*.
• original_role (선택): 가장을 요청하는 롤 이름과 대조할 정규식. 기본값은 .*.
• new_user (필수): 가장할 사용자와 대조할 정규식. original_user와의 일치 중 캡처된 부분 시퀀스에 대한 참조를 포함할 수 있으며, 각 참조는 해당하는 그룹을 평가한 결과로 대체돼요.
• allow (선택): 인증이 허용되어야 하는지 여부를 나타내는 불리언. 기본값은 true.

가장 규칙은 다른 규칙과 조금 달라요: 의도보다 더 많은 접근을 실수로 막지 않도록 new_user 속성이 필수예요. 그렇게 함으로써 allow 속성을 선택적으로 만들 수 있었어요.

다음 예시는 admin 롤이 bob을 제외한 모든 사용자를 가장할 수 있게 해요. 어떤 사용자든 test 사용자를 가장할 수 있게 해요. team_backend 형태의 사용자가 team_backend_sandbox 사용자를 가장할 수 있게 하지만, 임의의 사용자는 못 하게 해요:

{
    "impersonation": [
        {
            "original_role": "admin",
            "new_user": "bob",
            "allow": false
        },
        {
            "original_role": "admin",
            "new_user": ".*"
        },
        {
            "original_user": ".*",
            "new_user": "test"
        },
        {
            "original_user": "team_(.*)",
            "new_user": "team_$1_sandbox",
            "allow": true
        }
    ]
}

principal 규칙 (Principal rules)

Warning

principal 규칙은 더 이상 사용되지 않아요(deprecated). 대신 복잡한 인증 사용자 이름이 Trino의 단순 사용자 이름으로 어떻게 매핑되는지 지정하는 User mapping과 위에서 정의한 가장 규칙을 사용하세요.

이 규칙들은 principal과 지정된 사용자 이름 사이의 특정 매칭을 강제하기 위해 사용돼요. principal은 위에서 아래로 읽은 첫 번째 일치 규칙에 기반해 사용자로 인가돼요. 규칙이 지정되지 않으면 어떤 검사도 수행되지 않아요. 일치하는 규칙이 없으면 사용자 인가가 거부돼요. 각 규칙은 다음 필드로 구성돼요:

• principal (필수): principal과 대조·그룹화할 정규식.
• user (선택): 사용자 이름과 대조할 정규식. 일치하면 allow 값에 기반해 인가를 허용·거부해요.
• principal_to_user (선택): principal에 대체할 치환 문자열. 치환 결과가 사용자 이름과 같으면 allow 값에 기반해 인가를 허용·거부해요.
• allow (필수): principal이 사용자로 인가될 수 있는지 여부를 나타내는 불리언.

Note

principal 규칙에 적어도 하나의 기준은 지정해야 해요. 둘 다 지정하면 두 기준 중 하나가 충족될 때 원하는 결론을 반환해요.

다음은 LDAP와 Kerberos 인증에 대해 전체 principal 이름을 정확히 매칭하는 구현이에요:

{
  "principals": [
    {
      "principal": "(.*)",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "([^/]+)(/.*)?@.*",
      "principal_to_user": "$1",
      "allow": true
    }
  ]
}

사용자가 Kerberos principal 이름과 정확히 같은 이름을 사용하도록 하고, alice와 bob이 [email protected]라는 그룹 principal을 사용할 수 있게 하려면 다음 규칙을 사용할 수 있어요:

{
  "principals": [
    {
      "principal": "([^/]+)/?.*@example.net",
      "principal_to_user": "$1",
      "allow": true
    },
    {
      "principal": "[email protected]",
      "user": "alice|bob",
      "allow": true
    }
  ]
}

시스템 정보 규칙 (System information rules)

이 규칙들은 시스템 정보 관리 인터페이스에 접근할 수 있는 사용자를 지정해요. 시스템 정보 접근에는 다음 측면이 포함돼요:

• /v1/node, /v1/thread 같은 REST 엔드포인트의 민감한 정보에 대한 읽기 접근
• 시스템 정보 함수로의 읽기 접근
• System 커넥터로의 읽기 접근
• Graceful shutdown 트리거에 대한 쓰기 접근

다음 REST 엔드포인트는 항상 공개이며 이 규칙들의 영향을 받지 않아요:

• GET /v1/info
• GET /v1/info/state
• GET /v1/status

사용자는 위에서 아래로 읽은 첫 번째 일치 규칙에 기반해 접근이 허용되거나 거부돼요. 규칙이 지정되지 않으면 시스템 정보에 대한 모든 접근이 거부돼요. 일치하는 규칙이 없으면 시스템 접근이 거부돼요. 각 규칙은 다음 필드로 구성돼요:

• role (선택): 롤과 대조할 정규식. 일치하면 allow 값에 기반해 인가를 허용·거부해요.
• user (선택): 사용자 이름과 대조할 정규식. 일치하면 allow 값에 기반해 인가를 허용·거부해요.
• allow (필수): 사용자에게 부여된 접근 권한 집합. 값: read, write.

다음 구성이 예시를 제공해요:

{
  "system_information": [
    {
      "role": "admin",
      "allow": ["read", "write"]
    },
    {
      "user": "alice",
      "allow": ["read"]
    }
  ]
}

admin 롤을 가진 모든 사용자는 시스템 정보에 대한 읽기·쓰기 접근 권한이 있어요. 여기에는 Graceful shutdown을 트리거하는 능력이 포함돼요.

alice 사용자는 시스템 정보를 읽을 수 있어요.

다른 모든 사용자와 롤은 시스템 정보 접근이 거부돼요.

management.user 구성 속성을 사용해 관리 인터페이스에 고정 사용자를 설정할 수 있어요. 이것이 구성되면 시스템 정보 규칙이 여전히 이 사용자가 관리 정보를 읽거나 쓰도록 인가해야 해요. 고정 관리 사용자는 기본적으로 HTTP에만 적용돼요. HTTPS에서 고정 사용자를 활성화하려면 management.user.https-enabled 구성 속성을 설정하세요.

인가 규칙 (Authorization rules)

이 규칙들은 스키마·테이블·뷰의 소유자를 어떻게 변경할 수 있는지 제어해요. 다음 같은 명령에 적용 가능해요:

ALTER SCHEMA name SET AUTHORIZATION ( user | USER user | ROLE role )
ALTER TABLE name SET AUTHORIZATION ( user | USER user | ROLE role )
ALTER VIEW name SET AUTHORIZATION ( user | USER user | ROLE role )

이 규칙들이 존재하면 인가는 위에서 아래로 처리되는 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 인가가 거부돼요.

스키마, 테이블, 뷰에 ALTER 명령을 실행하려면 사용자에게 OWNERSHIP 권한이 필요해요.

각 인가 규칙은 다음 필드로 구성돼요:

• original_user (선택): 인가를 요청하는 사용자와 대조할 정규식. 기본값은 .*.
• original_group (선택): 인가를 요청하는 그룹 이름과 대조할 정규식. 기본값은 .*.
• original_role (선택): 인가를 요청하는 롤 이름과 대조할 정규식. 기본값은 .*.
• new_user (선택): 스키마·테이블·뷰의 새 소유자 사용자와 대조할 정규식. 기본적으로 일치하지 않아요.
• new_role (선택): 스키마·테이블·뷰의 새 소유자 롤과 대조할 정규식. 기본적으로 일치하지 않아요.
• allow (선택): 인증이 허용되어야 하는지 여부를 나타내는 불리언. 기본값은 true.

new_user와 new_role은 선택적이지만, 적어도 하나는 제공해야 한다는 점에 주의하세요.

다음 예시는 admin 롤이 bob을 제외한 어떤 사용자로든 스키마·테이블·뷰의 소유자를 변경할 수 있게 해요:

{
  "authorization": [
    {
      "original_role": "admin",
      "new_user": "bob",
      "allow": false
    },
    {
      "original_role": "admin",
      "new_user": ".*",
      "new_role": ".*"
    }
  ],
  "schemas": [
    {
      "role": "admin",
      "owner": true
    }
  ],
  "tables": [
    {
      "role": "admin",
      "privileges": ["OWNERSHIP"]
    }
  ]
}

카탈로그 수준 접근 제어 파일 (Catalog-level access control files)

그 카탈로그에 특정한 인가 규칙을 정의하는 개별 카탈로그용 JSON 파일을 만들 수 있어요. 카탈로그 수준 접근 제어 파일을 활성화하려면 인가 타입을 FILE로 설정하는 커넥터별 카탈로그 구성 속성과 JSON 규칙 파일을 지정하는 security.config-file 카탈로그 구성 속성을 추가하세요.

예를 들어 다음 Iceberg 카탈로그 구성 속성은 카탈로그 수준 접근 제어에 rules.json 파일을 사용해요:

iceberg.security=FILE
security.config-file=etc/catalog/rules.json

카탈로그 수준 접근 제어 파일은 커넥터별로 지원되므로 자세한 내용은 커넥터 문서를 참고하세요.

Note

이 규칙들은 information_schema 스키마의 시스템 정의 테이블에는 적용되지 않아요.

카탈로그 규칙 파일 구성 (Configure a catalog rules file)

구성 파일은 JSON 형식으로 지정돼요. 이 파일은 각각 위에서 아래로 순서대로 처리되는 규칙 목록인 다음 섹션으로 구성돼요:

• schemas
• tables
• session_properties

사용자는 첫 번째 일치 규칙에서 권한을 부여받아요. 모든 정규식은 지정하지 않으면 기본값이 .*이에요.

스키마 규칙 (Schema rules)

이 규칙들은 누가 스키마의 소유자로 간주되는지 관장해요.

• user (선택): 사용자 이름과 대조할 정규식.
• group (선택): 사용자가 속한 모든 사용자 그룹과 대조할 정규식.
• schema (선택): 스키마 이름과 대조할 정규식.
• owner (필수): 소유권을 나타내는 불리언.

테이블 규칙 (Table rules)

이 규칙들은 특정 테이블에 부여된 권한을 관장해요.

• user (선택): 사용자 이름과 대조할 정규식.
• group (선택): 사용자가 속한 모든 사용자 그룹과 대조할 정규식.
• schema (선택): 스키마 이름과 대조할 정규식.
• table (선택): 테이블 이름과 대조할 정규식.
• privileges (필수): SELECT, INSERT, DELETE, UPDATE, OWNERSHIP, GRANT_SELECT 중 0개 이상.
• columns (선택): 컬럼 제약 목록.
• filter (선택): 테이블에 대한 boolean 필터 표현식.
• filter_environment (선택): 필터 평가 중 사용되는 환경.

컬럼 제약 (Column constraints)

이 제약들은 컬럼 데이터에 대한 접근을 제한하는 데 사용할 수 있어요.

• name: 컬럼 이름.
• allow (선택): false이면 컬럼에 접근할 수 없음.
• mask (선택): 컬럼에 적용하는 마스크 표현식.
• mask_environment (선택): 마스크 평가 중 사용되는 환경.

필터 환경과 마스크 환경 (Filter environment and mask environment)

이 규칙들은 filter_environment와 mask_environment에 적용돼요.

• user (선택): 마스크의 서브쿼리 권한을 확인하는 사용자 이름.

Note

mask는 IF나 CASE 같은 조건 표현식을 포함할 수 있으며, 이로써 조건부 마스킹을 달성해요.

함수 규칙 (Function rules)

이 규칙들은 사용자가 함수를 생성·삭제·실행할 수 있는 능력을 제어해요.

이 규칙들이 존재하면 인가는 위에서 아래로 처리되는 첫 번째 일치 규칙에 기반해요. 일치하는 규칙이 없으면 인가가 거부돼요. 함수 규칙이 존재하지 않으면 접근이 허용되지 않아요.

• user (선택): 사용자 이름과 대조할 정규식. 기본값은 .*.
• group (선택): 그룹 이름과 대조할 정규식. 기본값은 .*.
• schema (선택): 스키마 이름과 대조할 정규식. 기본값은 .*.
• function (선택): 함수 이름과 대조할 정규식. 기본값은 .*.
• privileges (필수): EXECUTE, GRANT_EXECUTE, OWNERSHIP 중 0개 이상.

카탈로그의 system 스키마는 Trino가 query 같은 테이블 함수에 사용하는 스키마이므로 이 스키마에 권한을 부여할 때는 주의해야 해요. 이런 테이블 함수는 카탈로그의 기본 데이터에 접근하거나 수정하는 데 사용될 수 있어요.

다음 예시는 admin 사용자가 이 카탈로그에서 system.query 테이블 함수를 실행하고, 모든 사용자가 이 카탈로그의 function 스키마에서 함수(뷰에서 포함)를 생성·삭제·실행할 수 있게 해요:

{
  "functions": [
    {
      "user": "admin",
      "schema": "system",
      "function": "query",
      "privileges": [
        "EXECUTE"
      ]
    },
    {
      "schema": "function",
      "privileges": [
        "EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"
      ]
    }
  ]
}

세션 속성 규칙 (Session property rules)

이 규칙들은 누가 세션 속성을 설정할 수 있는지 관장해요.

• user (선택): 사용자 이름과 대조할 정규식.
• group (선택): 사용자가 속한 모든 사용자 그룹과 대조할 정규식.
• property (선택): 세션 속성 이름과 대조할 정규식.
• allow (필수): 이 세션 속성이 설정될 수 있는지 여부를 나타내는 불리언.

예시 (Example)

{
  "schemas": [
    {
      "user": "admin",
      "schema": ".*",
      "owner": true
    },
    {
      "group": "finance|human_resources",
      "schema": "employees",
      "owner": true
    },
    {
      "user": "guest",
      "owner": false
    },
    {
      "schema": "default",
      "owner": true
    }
  ],
  "tables": [
    {
      "user": "admin",
      "privileges": ["SELECT", "INSERT", "DELETE", "UPDATE", "OWNERSHIP"]
    },
    {
      "user": "banned_user",
      "privileges": []
    },
    {
      "schema": "hr",
      "table": "employee",
      "privileges": ["SELECT"],
      "filter": "user = current_user"
    },
    {
      "schema": "default",
      "table": ".*",
      "privileges": ["SELECT"],
      "columns" : [
         {
            "name": "address",
            "allow": false
         },
         {
            "name": "ssn",
            "mask": "'XXX-XX-' + substring(credit_card, -4)",
            "mask_environment": {
              "user": "admin"
            }
         }
      ]
    }
  ],
  "session_properties": [
    {
      "property": "force_local_scheduling",
      "allow": true
    },
    {
      "user": "admin",
      "property": "max_split_size",
      "allow": true
    }
  ]
}

더 알아보기 (Learn more)

파일 기반 접근 제어는 System access control의 여러 접근 제어 시스템 결합 방법과 함께 이해하면 좋아요. 컬럼 마스킹·행 필터링을 더 고급스럽게 다루려면 Open Policy Agent access control도 참고해 보세요.