권한 모델

​

아이덴티티

• 커넥터의 mTLS 클라이언트 인증서는 조직 ID를 공통 이름(common name)으로 사용하며, 모든 데몬을 커넥터 엔드포인트에 인증합니다. clicklink clctl instances create도 엔드포인트를 호출할 때 동일한 인증서와 HMAC 키를 사용합니다.
• **pcm_scraper와 pcm_troubleshooter**는 스크레이퍼와 Troubleshooter가 접속할 때 사용하는 읽기 전용 ClickHouse 사용자입니다. 실행기에는 ClickHouse 사용자가 없습니다.
• Troubleshooter ServiceAccount는 프로비저닝된 배포마다 하나씩 존재하며, 지원 세션에서 사용할 수 있는 읽기 전용 Kubernetes 뷰를 제공합니다.
• **pcm-executor**는 관리형 서비스의 수명 주기를 담당하는 실행기의 Kubernetes ServiceAccount입니다. ValidatingAdmissionPolicy가 이 계정의 쓰기 작업을 서비스 네임스페이스로 제한합니다.
• **pcm-platform**은 플랫폼 업데이트에 사용되는 실행기의 아이덴티티입니다. clicklink clctl platform approve를 실행하면 2시간 동안만 유효한 토큰이 발급되며 갱신되지 않습니다. 승인과 승인 사이에는 실행기가 플랫폼 계층에 대한 쓰기 액세스를 갖지 않습니다.
• 서비스별 IAM role(기본값 CH-S3-<service>-<region>-00-Role)은 사용자의 자격 증명을 사용해 clicklink clctl executor prepare가 생성합니다. 이 역할은 해당 서비스의 데이터 및 Backup 버킷으로 범위가 한정되고 해당 서비스의 Kubernetes ServiceAccount만 신뢰하므로, 실행기도 ClickHouse도 이 역할을 assume할 수 없습니다.
• 커넥터 EC2 VM의 인스턴스 프로필은 차트 로그인과 이미지 검사 모두에서 직접 플랫폼 액세스를 위해 환경의 읽기 전용 ECR puller 역할을 assume합니다. 승인 CLI도 동일한 인스턴스 프로필 경로를 사용하며, workstation의 AWS 프로필이나 SSO 자격 증명이 이를 대체하지 않습니다. 다른 ECR 차트 레지스트리는 주변 AWS 자격 증명을 사용합니다. 이미지 pull은 사용자의 노드에서 해당 노드의 pull 역할로 수행됩니다. 실행기는 사용자의 버킷이나 IAM에 대한 자격 증명을 보유하지 않으며 S3나 IAM 호출도 하지 않습니다. 레지스트리 자격 증명을 참조하십시오.
• 사용자 본인의 자격 증명으로 모든 권한이 부여됩니다. init --managed 시점의 실행기 액세스 권한 부여, prepare 시점의 버킷 및 역할 생성, approve 시점의 모든 플랫폼 업데이트에 대한 권한 부여, 그리고 teardown 시점의 정리 작업이 여기에 해당합니다.

​

connector로 수행할 수 있는 작업

​

아웃바운드 연결

​

ClickHouse 권한 부여

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

​

Kubernetes RBAC

​

Scraper와 troubleshooter

​

실행기

​

플랫폼 아이덴티티

​

커넥터가 할 수 없는 일

• ClickHouse 데이터나 상태에 대한 쓰기 불가. 위의 권한에는 INSERT, DDL, 사용자 관리, 설정, 프로세스 제어 권한이 전혀 포함되어 있지 않습니다. 유일한 시스템 계열 권한인 스크레이퍼의 SYSTEM FLUSH LOGS는 로그 테이블이 이미 버퍼에 담고 있는 내용을 영속화하는 것뿐입니다. 실행기에는 ClickHouse 사용자가 없습니다. 어떤 구성 요소도 ClickHouse를 통해 데이터, 스키마, 사용자, 설정을 변경할 수 없습니다.
• exec 불가. 어떤 RBAC에도 pods/exec가 포함되어 있지 않으므로, 어떤 구성 요소도 사용자의 파드에서 명령어를 실행할 수 없습니다.
• 서비스 및 플랫폼 네임스페이스 외부에 대한 쓰기 불가. 스크레이퍼와 troubleshooter에는 delete나 patch 권한이 없습니다. 이들의 유일한 뮤테이션은 커넥터 자체의 mTLS 시크릿에 대한 정확한 이름 기반 update와 serviceaccounts/token에 대한 create뿐이며, 후자는 자체 ServiceAccount용 단기 토큰을 발급할 뿐 저장된 객체는 변경하지 않습니다. admission은 서비스 접두사 외부에 대한 실행기의 쓰기를 거부하며, 플랫폼 쓰기는 사용자가 발급한 토큰이 유효한 동안에만 가능합니다.
• 권한을 부여할 권한 없음. 플랫폼의 네임스페이스, CRD, ServiceAccount, RBAC, 웹훅 및 admission 구성, PriorityClass, StorageClass는 approve 과정에서 사용자의 자격 증명으로 적용됩니다. 실행기의 플랫폼 아이덴티티는 권한을 상승시키거나, 바인딩하거나, 가장할 수 없습니다. 서비스 네임스페이스 내부에서 실행기는 이미 보유한 권한을 부여하는 역할만 생성할 수 있습니다.
• 사용자의 버킷이나 IAM에 대한 자격 증명 없음. clicklink clctl executor prepare는 버킷과 서비스별 역할을 생성하고, clicklink clctl executor teardown은 이를 제거하며, 두 작업 모두 사용자의 자격 증명으로 수행됩니다. 해당 역할은 그 서비스의 파드만 assume할 수 있습니다. 직접적인 플랫폼 액세스의 경우, 실행기는 커넥터 EC2 VM의 인스턴스 프로필을 사용해 차트 로그인과 이미지 확인 모두에 쓰이는 읽기 전용 ECR puller 역할을 assume합니다. 그 외의 ECR 차트 레지스트리는 주변 AWS 자격 증명을 사용합니다. 아이덴티티를 참조하십시오. 클라우드 API 호출은 ECR과 STS로만 이루어지며, 사용자의 데이터를 읽거나 삭제할 수는 없습니다.
• default user 비밀번호에 대한 정보 없음. clicklink clctl executor prepare가 사용자 측에서 이를 생성하고 한 번만 표시합니다(플래그로 입력값을 전달하는 경우에는 clicklink clctl instances create가 이 역할을 합니다). 해시만 전송되므로 커넥터도 ClickHouse Cloud도 이를 복원할 수 없습니다.
• 인바운드 연결 없음. ClickHouse Cloud는 사용자 환경으로 연결을 여는 일이 결코 없습니다. 유일한 명령 경로는 두 개의 아웃바운드 WebSocket입니다. troubleshooter는 사용자가 활성화한 지원 세션이 진행 중이지 않으면 모든 명령을 거부합니다. 실행기는 사용자가 ClickHouse에 관리를 요청한 서비스에 대해서만, 그리고 위의 범위 내에서만 수명 주기 명령을 수락합니다. 세션 중이라 하더라도 troubleshooter는 양쪽 모두에서 제한됩니다. ClickHouse 쿼리는 테이블 허용 목록으로 제한되며, 이 허용 목록은 query_log와 text_log를 거부하므로 해당 권한은 결코 부여되지 않습니다. Kubernetes 접근은 네임스페이스 범위의 역할이 부여하는 읽기 전용 뷰와 파드 로그로 제한됩니다.

​

직접 조치해야 하는 사항

• 관리형 모드 활성화. 실행기는 init 단계에서 관리형 모드를 활성화한 후에만 실행되며, 해당 Kubernetes 권한 부여도 그때 생성됩니다. 권한 부여는 cluster admin 권한으로 적용됩니다. managed services를 참조하십시오.
• service 생성. clicklink clctl executor prepare는 사용자의 AWS 자격 증명으로 실행되어 버킷과 IAM role을 생성하고, clicklink clctl instances create는 정의를 제출합니다. 이 두 가지가 모두 없으면 ClickHouse Cloud는 사용자의 클러스터에 service를 생성할 수 없습니다. create a service를 참조하십시오.
• 플랫폼 업데이트. 플랫폼 구성 요소에 대한 각 업데이트는 해당 bundle에 대해 clicklink clctl platform approve를 실행한 후에만 적용됩니다. 이때 발급되는 토큰은 2시간 후 만료되며 갱신되지 않습니다. platform updates를 참조하십시오.
• 삭제 후 정리. service를 삭제하면 해당 Kubernetes resources만 제거됩니다. 사용자의 자격 증명으로 실행하는 clicklink clctl executor teardown은 IAM role을 제거하며, 명시적인 플래그를 지정한 경우에만 데이터와 Backup도 제거합니다. delete a service를 참조하십시오.
• 지원 세션. 대화형 문제 해결은 활성화한 세션에서만 가능하며, 기본적으로 4시간, 최대 24시간으로 제한됩니다. 비활성화는 즉시 적용됩니다. 지원 세션을 참조하십시오.
• 운영자 허용 목록. 모든 gateway 요청에는 증명된 이메일 주소가 허용 목록에 포함된 OIDC 토큰이 있어야 합니다. 허용 목록이 비어 있으면 모든 접근이 차단됩니다. 목록은 직접 관리합니다. 구성 가이드를 참조하십시오.
• Gateway 노출. 세션 gateway는 활성화하지 않으면 비활성 상태이며, 인그레스를 사용하지 않는 한 포트 포워딩으로만 접근할 수 있습니다. VM에서는 세션 명령어가 gateway와 통신하기 전에 각 운영자가 자체 서명 인증서의 지문을 고정하거나, --gateway-ca로 전달한 CA bundle로 인증서를 검증해야 합니다.
• 네트워크 이그레스. 강제 적용 CNI 환경에서는 networkPolicy.allowEgressCIDRs에 connector 엔드포인트의 CIDR을 등록하기 전까지 어떤 데몬도 해당 엔드포인트에 연결할 수 없습니다. 실행기에는 Kubernetes API server CIDR(networkPolicy.apiserverCIDRs)도 필요하며, 이 값은 init --managed가 클러스터의 VPC에서 도출합니다. 플랫폼 차트를 Amazon ECR에서 가져오는 경우 ECR과 STS 범위도 추가하십시오.

​

액세스 귀속 방식

• 배포 아이덴티티. mTLS 클라이언트 인증서의 common name은 org ID이며, 단일 DNS name이 엔드포인트 host에 바인딩됩니다. 따라서 모든 API 연결은 해당 org로 귀속됩니다. 갱신은 데몬 내부에서 자동으로 이루어지며, 운영자가 키 자료를 직접 다루는 일은 없습니다.
• 요청 무결성. 모든 API 요청에는 등록 시 발급된 키 쌍을 사용해 메서드, 경로, timestamp, body 해시에 대해 생성한 HMAC-SHA256 서명(Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...)이 함께 포함됩니다.
• 운영자 아이덴티티. Gateway 호출은 운영자의 OIDC ID token이 증명하는 이메일로 귀속되며, 해당 토큰은 IdP(Identity Provider)의 JWKS로 검증됩니다. 토큰을 사용할 수 있는 경우 스스로 신고한 이름은 신뢰하지 않습니다.
• 수명 주기 명령어. 실행기는 수신한 모든 명령어를 해당 명령의 출처(ClickHouse Cloud 또는 로컬 clicklink clctl 호출), 단계, 결과와 함께 로컬 저장소에 기록하고, 명령 채널을 통해 그 결과를 다시 보고합니다. 기록은 clicklink clctl commands list 및 clicklink clctl commands get으로 확인하십시오. CLI reference를 참조하십시오.
• 플랫폼 승인. 승인한 bundle의 다이제스트는 pcm-platform ServiceAccount에 기록됩니다. 자격 증명으로 적용한 모든 객체에는 콘텐츠 해시가 포함되며, 실행기는 쓰기 작업 전에 이를 검증합니다. 다이제스트가 일치하지 않는 bundle은 거부됩니다.
• 감사 추적. 수락 여부와 관계없이 모든 session 명령어는 명령 채널에서 가져온 org 아이덴티티와 함께 NDJSON 감사 로그에 추가됩니다. Gateway 호출은 증명된 운영자 이메일과 함께 구조화된 clctl.gateway 라인 형태로 troubleshooter 로그에 기록됩니다. VM 로컬 session 변경 사항은 host 사용자를 session.json에 기록합니다. 감사 로그는 clicklink clctl troubleshoot audit tail로 확인하십시오. CLI reference를 참조하십시오.

​

데이터 최소화 기본값

• query_log는 기본적으로 스크레이프 대상에서 제외됩니다. 이 테이블의 컬럼에는 리터럴 값이 그대로 포함된 원본 SQL이 담기며, 여기에 개인 데이터나 시크릿이 포함될 수 있습니다. 직접 추가하지 않는 한 경계 밖으로 나가지 않습니다.
• troubleshooter는 허용 목록에 등록된 테이블만 읽습니다. query_log와 text_log는 허용 목록 구성 자체에서 거부되므로 절대 허용되지 않으며, 쿼리 이력도 읽을 수 없습니다. 다만 기본 허용 목록에는 system.processes(실행 중인 쿼리 텍스트)가 포함되어 있으므로, 세션 중에도 이를 노출하지 않아야 한다면 해당 항목을 제거하십시오(Kubernetes에서는 troubleshooter.allowedTables, VM에서는 troubleshooter.allowed_tables).
• troubleshooter의 모든 출력은 내장 패턴과 사용자가 정의한 패턴에 따라 마스킹됩니다. 내장 패턴은 IPv4 및 IPv6 주소, bearer 토큰, AWS 액세스 키, 이메일, JWT, SSH 개인 키, 연결 문자열 자격 증명을 다룹니다. 패턴 파일이 유효하지 않으면 데몬은 마스킹 없이 실행하는 대신 시작 자체를 거부합니다.
• 관리형 서비스 상태는 메타데이터만 다룹니다. 실행기는 서비스의 상태, 레플리카 수, 버전, 명령 실행 결과를 보고할 뿐, 서비스의 테이블이나 버킷은 절대 읽지 않습니다.
• 자격 증명은 저장 시 최소화됩니다. 프로비저닝 SQL에는 평문 비밀번호가 아니라 bcrypt 해시가 포함됩니다. 관리형 서비스의 default 사용자 비밀번호는 한 번만 표시되며, 이후에는 해시 형태로만 외부로 전달됩니다. 등록 토큰은 명령줄, 디스크, 로그 어디에도 기록되지 않습니다. 키는 Kubernetes Secrets 또는 모드 0600의 파일에 저장됩니다.