사용자 인증 및 권한 부여(User authentication and authorization)
사용자 인증 및 권한 부여(User authentication and authorization)
이 문서는 확장이 Druid에 사용자 인증 및 권한 부여 서비스를 활성화하는 데 사용하는 Druid 보안 모델을 설명해요. 이 문서에서는 리소스(resource)와 액션(action)의 개념, 리소스 타입별 권한 정의, 기본 사용자 계정, SQL 권한을 설명드릴게요.
출처: 문서
본문
이 문서는 확장이 Druid에 사용자 인증 및 권한 부여 서비스를 활성화하는 데 사용하는 Druid 보안 모델을 설명합니다.
인증 및 권한 부여 모델
Druid 사용자 인증 및 권한 부여 모델의 중심에는 *리소스(resources)*와 *액션(actions)*이 있어요. 리소스는 인증된 사용자가 접근하거나 수정하려고 하는 것입니다. 액션은 사용자가 하려고 하는 것입니다.
리소스 타입
Druid는 다음 리소스 타입을 사용합니다:
- DATASOURCE – 각 Druid 테이블(즉, SQL의
druid스키마에 있는tables)이 하나의 리소스입니다. - CONFIG – 클러스터 컴포넌트가 노출하는 구성 리소스.
- EXTERNAL – SQL의 EXTERN 함수를 통해 읽는 외부 데이터.
- STATE – 클러스터 전체 상태 리소스.
- SYSTEM_TABLE – Broker 속성
druid.sql.planner.authorizeSystemTablesDirectly가 true일 때, Druid는 이 리소스 타입을 사용해 SQL의sys스키마에 있는 시스템 테이블을 권한 부여합니다.
리소스 타입과 연결된 특정 리소스에 대해서는 Defining permissions와 API reference의 해당 엔드포인트 설명을 참고하세요.
액션
사용자는 리소스에 대해 다음 액션 중 하나를 수행합니다:
- READ – 읽기 전용 작업에 사용.
- WRITE – 읽기 전용이 아닌 작업에 사용.
리소스에 대한 WRITE 권한에는 READ 권한이 포함되지 않아요. 사용자가 리소스에 대해 READ와 WRITE 권한을 모두 필요로 한다면 둘 다 명시적으로 부여해야 합니다. 예를 들어 DATASOURCE READ 권한만 있는 사용자는 DATASOURCE WRITE 권한이 있는 사용자가 접근할 수 없는 API나 시스템 스키마 레코드에 접근할 수 있을 수 있어요.
사용자 유형
실제로 대부분의 배포에서 사용자는 두 부류로 정의하면 충분합니다:
- 관리자(Administrators): 모든 리소스 타입에 대해 WRITE 액션 권한을 가집니다. 이 사용자들은 데이터소스를 추가하고 시스템을 관리합니다.
- 데이터 사용자(Data users): DATASTORE에 대한 READ 접근만 필요로 합니다. 이 사용자들은 Query API에만 API 게이트웨이를 통해 접근해야 합니다. 다른 API와 권한에는 서버 관리자에게만 제한되어야 하는 기능이 포함됩니다.
DATASOURCE에 대한 WRITE 접근이 사용자에게 광범위한 접근을 부여한다는 점에 주목하는 것이 중요해요. 예를 들어 그런 사용자는 Druid 파일 시스템, S3 버킷, 자격 증명(credentials) 등에 접근할 수 있습니다. 따라서 데이터소스를 추가하고 관리하는 능력은 관리자에게 선택적으로 할당해야 해요.
기본 사용자 계정
인증자(Authenticator)
druid.auth.authenticator.<authenticator-name>.initialAdminPassword가 설정되면, 지정된 초기 패스워드로 "admin"이라는 기본 관리자 사용자가 생성됩니다. 이 구성이 생략되면 "admin" 사용자는 생성되지 않습니다.
druid.auth.authenticator.<authenticator-name>.initialInternalClientPassword가 설정되면, 지정된 초기 패스워드로 "druid_system"이라는 기본 내부 시스템 사용자가 생성됩니다. 이 구성이 생략되면 "druid_system" 사용자는 생성되지 않습니다.
Authorizer
각 Authorizer는 항상 완전한 권한을 가진 기본 "admin"과 "druid_system" 사용자를 가지게 됩니다.
권한 정의
사용자 그룹에 부여하는 권한을 정의합니다. 권한은 리소스 타입, 액션, 리소스 이름으로 정의됩니다. 이 섹션에서는 각 리소스 타입에 사용 가능한 리소스 이름을 설명해요.
DATASOURCE
이 타입의 리소스 이름은 데이터소스 이름입니다. 데이터소스 권한을 지정하면 관리자가 특정 데이터소스에 대한 접근을 사용자에게 부여할 수 있어요.
CONFIG
"CONFIG" 리소스 타입에는 "CONFIG"와 "security" 두 가지 가능한 리소스 이름이 있습니다. CONFIG 리소스에 대한 접근을 사용자에게 부여하면 다음 엔드포인트에 접근할 수 있게 됩니다.
"CONFIG" 리소스 이름은 다음 엔드포인트를 포함합니다:
| Endpoint | Process Type |
|---|---|
/druid/coordinator/v1/config |
coordinator |
/druid/indexer/v1/worker |
overlord |
/druid/indexer/v1/worker/history |
overlord |
/druid/worker/v1/disable |
middleManager |
/druid/worker/v1/enable |
middleManager |
"security" 리소스 이름은 다음 엔드포인트를 포함합니다:
| Endpoint | Process Type |
|---|---|
/druid-ext/basic-security/authentication |
coordinator |
/druid-ext/basic-security/authorization |
coordinator |
EXTERNAL
EXTERNAL 리소스 타입은 "EXTERNAL" 리소스 이름만 허용합니다. EXTERNAL 리소스에 대한 접근을 사용자에게 부여하면, SQL에서 EXTERN 함수를 포함해 외부 데이터를 읽는 쿼리를 실행할 수 있게 됩니다.
STATE
"STATE" 리소스 타입에는 "STATE" 하나뿐인 리소스 이름이 있습니다. STATE 리소스에 대한 접근을 사용자에게 부여하면 다음 엔드포인트에 접근할 수 있게 됩니다.
"STATE" 리소스 이름은 다음 엔드포인트를 포함합니다:
| Endpoint | Process Type |
|---|---|
/druid/coordinator/v1 |
coordinator |
/druid/coordinator/v1/rules |
coordinator |
/druid/coordinator/v1/rules/history |
coordinator |
/druid/coordinator/v1/servers |
coordinator |
/druid/coordinator/v1/tiers |
coordinator |
/druid/broker/v1 |
broker |
/druid/v2/candidates |
broker |
/druid/indexer/v1/leader |
overlord |
/druid/indexer/v1/isLeader |
overlord |
/druid/indexer/v1/action |
overlord |
/druid/indexer/v1/workers |
overlord |
/druid/indexer/v1/scaling |
overlord |
/druid/worker/v1/enabled |
middleManager |
/druid/worker/v1/tasks |
middleManager |
/druid/worker/v1/task/{taskid}/shutdown |
middleManager |
/druid/worker/v1/task/{taskid}/log |
middleManager |
/druid/historical/v1 |
historical |
/druid-internal/v1/segments/ |
historical |
/druid-internal/v1/segments/ |
peon |
/druid-internal/v1/segments/ |
realtime |
/status |
all process types |
SYSTEM_TABLE
이 타입의 리소스 이름은 SQL의 sys 스키마에 있는 시스템 스키마 테이블 이름으로, 예를 들어 sys.segments, sys.server_segments가 있어요. Druid는 Broker 속성 druid.sql.planner.authorizeSystemTablesDirectly가 true일 때만 SYSTEM_TABLE 리소스에 대한 권한 부여를 시행합니다.
HTTP 메서드
특정 요청 엔드포인트에서 지원되는 HTTP 메서드에 대한 정보는 API reference를 참고하세요. GET 요청은 READ 권한이 필요하고, POST와 DELETE 요청은 WRITE 권한이 필요합니다.
SQL 권한
Druid 데이터소스에 대한 쿼리는 지정된 데이터소스에 대한 DATASOURCE READ 권한이 필요합니다. EXTERN 함수를 통해 외부 데이터에 접근하는 쿼리는 EXTERNAL READ 권한이 필요해요. INFORMATION_SCHEMA 테이블에 대한 쿼리는 호출자가 DATASOURCE READ 접근 권한이 있는 데이터소스에 대한 정보를 반환합니다. 다른 데이터소스는 생략됩니다.
시스템 스키마 테이블에 대한 쿼리는 다음 권한이 필요합니다:
segments: Druid는 DATASOURCE READ 권한에 따라 세그먼트를 필터링합니다.servers: 사용자에게 STATE READ 권한이 필요합니다.server_segments: 사용자에게 STATE READ 권한이 필요합니다. Druid는 DATASOURCE READ 권한에 따라 세그먼트를 필터링합니다.tasks: Druid는 DATASOURCE READ 권한에 따라 태스크를 필터링합니다.supervisors: Druid는 DATASOURCE READ 권한에 따라 수퍼바이저를 필터링합니다.
Broker 속성 druid.sql.planner.authorizeSystemTablesDirectly가 true일 때, 사용자는 시스템 스키마 테이블을 쿼리하려면 그 테이블에 대한 SYSTEM_TABLE 권한도 필요합니다.
구성 전파
Coordinator에 대한 과도한 부하를 방지하기 위해, Authenticator와 Authorizer의 사용자/역할 Druid 메타데이터 저장소 상태가 각 Druid 프로세스에 캐시됩니다. 각 프로세스는 주기적으로 Coordinator를 폴링해 최신 Druid 메타데이터 저장소 상태를 가져오며, 이는 druid.auth.basic.common.pollingPeriod와 druid.auth.basic.common.maxRandomDelay 속성으로 제어됩니다.
구성 업데이트가 발생하면 Coordinator는 선택적으로 각 프로세스에 업데이트된 Druid 메타데이터 저장소 상태를 알릴 수 있어요. 이 동작은 Authenticator와 Authorizer의 enableCacheNotifications와 cacheNotificationTimeout 속성으로 제어됩니다. 캐싱 때문에 사용자/역할 Druid 메타데이터 저장소에 대한 변경 사항이 각 Druid 프로세스에 즉시 반영되지 않을 수 있다는 점에 주의하세요.