connector로 수행할 수 있는 작업
아웃바운드 연결
인바운드 측에서 커넥터는 로컬 상태 확인 및 메트릭 포트와 선택적으로 활성화할 수 있는 세션 gateway만 노출합니다. 그 외에는 수신 대기하지 않으며, ClickHouse Cloud는 사용자 환경에 연결하지 않습니다. troubleshooter의 아웃바운드 WebSocket에만 응답할 수 있습니다.
ClickHouse 권한 부여
SYSTEM FLUSH LOGS 권한입니다. 이 권한은 어떤 데이터도 읽거나 수정하지 않으며, 이미 버퍼링된 항목을 로그 테이블에 영구 저장하도록 강제할 뿐입니다. 사용자는 IDENTIFIED WITH bcrypt_hash로 생성되므로 Provisioning SQL에는 솔트된 bcrypt 해시만 포함되며, 평문 비밀번호는 데몬이 런타임에 읽는 자격 증명 파일에만 저장됩니다. 기본 테이블 Set에 적용되는 권한은 정확히 다음과 같습니다:
clusterAllReplicas()로 감싸므로 READ ON REMOTE 권한이 필요합니다. ClickHouse는 이 권한에 더 좁은 범위를 지정하는 것을 허용하지 않으므로 SYSTEM FLUSH LOGS는 전역 범위에서 부여해야 합니다. 다만 ClickHouse는 이 권한을 *_log 시스템 테이블에 대해서만 적용하므로, 부여 범위가 실제 기능보다 넓습니다.
system.user_directories 권한을 부여하는 이유는 하나의 진단을 위해서입니다. clicklink clctl preflight는 connector 자체 자격 증명으로 실행되며, 인스턴스가 ClickHouse 사용자를 복제된 방식으로 저장하는지 로컬 방식으로 저장하는지 확인합니다. 이 테이블에는 사용자 데이터가 아닌 사용자 스토리지 구성 메타데이터가 저장되며, 스크레이프 집합이나 세션 테이블 허용 목록에 포함되지 않으므로 스크레이프 또는 세션 출력 경로에서 읽히지 않습니다. 이 권한이 없으면 해당 사전 점검은 건너뛴 것으로 보고되지만, 그 외 모든 작업은 계속 진행됩니다.
테이블별 SELECT 권한 외에 부여되는 유일한 시스템 수준 권한은 스크레이퍼의 SYSTEM FLUSH LOGS입니다. 이 권한은 *_log 시스템 테이블의 버퍼링된 항목을 디스크에 영구 저장하여 스크레이프 시 최신 데이터를 볼 수 있게 하며, 그 외의 작업은 수행하지 않습니다. 이 권한은 전역 범위에서만 부여할 수 있지만, ClickHouse는 로그 테이블에 대해서만 이를 적용합니다. INSERT, DDL, 사용자 관리, 설정 또는 프로세스 제어 권한은 없습니다. 두 번째 connector 배포가 인스턴스를 공유하면 해당 사용자는 동일한 권한 세트에 접미사(pcm_scraper_<suffix>)를 추가한 이름을 사용합니다.
Kubernetes RBAC
커넥터가 수행할 수 없는 작업
- ClickHouse 데이터 또는 상태에 쓰기 불가. 위의 권한 부여에는
INSERT, DDL, 사용자 관리, 설정 또는 프로세스 제어 권한이 없습니다. 유일한 시스템 클래스 권한인 스크레이퍼의SYSTEM FLUSH LOGS는 로그 테이블이 이미 버퍼링한 내용을 플러시할 뿐입니다. 커넥터는 데이터, 스키마, 사용자 또는 설정을 수정할 수 없습니다. - exec 불가. RBAC에
pods/exec권한이 없으므로 커넥터는 파드에서 명령어를 실행할 수 없습니다. - 삭제 및 패치 불가. RBAC는 2개의 뮤테이션만 허용합니다. 커넥터 자체 mTLS 시크릿에 대해 정확한 이름으로 수행하는
update와, 커넥터 자체 ServiceAccounts용 단기 토큰을 발급하고 저장된 객체는 수정하지 않는serviceaccounts/token에 대한create입니다. - 클러스터 범위 없음. 모든 역할은 네임스페이스에 바인딩되므로 커넥터는 권한이 부여된 네임스페이스 외부의 리소스를 나열하거나 읽을 수 없습니다.
- 인바운드 없음. ClickHouse Cloud는 사용자 환경으로 연결을 열지 않습니다. 유일한 명령 경로는 troubleshooter의 아웃바운드 WebSocket이며, troubleshooter는 활성화된 지원 세션이 없으면 모든 명령을 거부합니다. 세션 중에도 양쪽 모두에서 범위가 제한됩니다. ClickHouse 쿼리는 테이블 허용 목록으로 제한되며,
query_log와text_log는 구성과 관계없이 검증기가 거부합니다. Kubernetes 액세스도 네임스페이스 범위 역할이 부여하는 읽기 전용 뷰와 파드 로그로 별도로 제한됩니다.
직접 조치해야 하는 사항
- Support 세션. 대화형 문제 해결은 활성화한 세션에서만 가능하며, 기본적으로 4시간, 최대 24시간으로 제한됩니다. 비활성화는 즉시 적용됩니다. Support 세션을 참조하십시오.
- 운영자 허용 목록. 모든 gateway 요청에는 증명된 이메일 주소가 허용 목록에 포함된 OIDC 토큰이 있어야 합니다. 허용 목록이 비어 있으면 모든 접근이 차단됩니다. 목록은 직접 관리합니다. 구성 가이드를 참조하십시오.
- Gateway 노출. 세션 gateway는 활성화하지 않으면 비활성 상태이며, 인그레스를 사용하지 않는 한 포트 포워딩으로만 접근할 수 있습니다. VM에서는 세션 명령어가 gateway와 통신하기 전에 각 운영자가 자체 서명 인증서의 지문을 고정해야 합니다.
- 네트워크 이그레스. 강제 적용 CNI 환경에서는 chart의 NetworkPolicy에서 엔드포인트 CIDR을 허용 목록에 추가하기 전까지 connector에 이그레스가 없습니다.
액세스 주체를 식별하는 방식
- 배포 아이덴티티. mTLS 클라이언트 인증서의 공통 이름은 조직 ID이며, 엔드포인트 호스트에는 단일 DNS 이름이 연결되므로 모든 API 연결의 조직을 식별할 수 있습니다. 인증서 갱신은 데몬 내에서 자동으로 수행되며, 운영자가 키 자료를 처리할 필요가 없습니다.
- 요청 무결성. 모든 API 요청에는 등록 시 발급된 키 쌍을 사용해 메서드, 경로, 타임스탬프 및 본문 해시를 기준으로 계산한 HMAC-SHA256 서명(
Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...)도 포함됩니다. - 운영자 아이덴티티. Gateway 호출은 운영자의 OIDC ID 토큰으로 증명되고 조직의 IdP(Identity Provider) JWKS를 통해 검증된 이메일에 귀속됩니다. 토큰을 사용할 수 있는 경우 자체 신고한 이름은 신뢰하지 않습니다.
- 감사 추적. 허용되거나 차단된 모든 gateway 호출과 모든 문제 해결 명령어는 NDJSON 감사 로그에 추가됩니다. gateway 항목에는 증명된 운영자 이메일이, VM 로컬 세션 변경에는 명령을 실행한 호스트 사용자가, 세션 명령어에는 인증된 채널을 통해 전달된 조직 아이덴티티가 기록됩니다.
clicklink clctl troubleshoot audit tail로 확인할 수 있습니다. CLI 참고를 참조하십시오.
데이터 최소화 기본값
query_log는 기본적으로 스크레이프 대상에서 제외됩니다. 해당 컬럼에는 리터럴 값이 포함된 원시 SQL이 들어 있으며 개인 데이터나 시크릿을 포함할 수 있으므로, 의도적으로 추가하지 않는 한 보안 경계 밖으로 나가지 않습니다.- troubleshooter는 허용 목록에 있는 테이블만 읽고, validator는
query_log와text_log를 무조건 거부하므로 쿼리 이력을 읽을 수 없습니다. 기본 허용 목록에는system.processes(실시간 쿼리 텍스트)가 포함됩니다. 세션 중에도 이를 숨겨야 한다면 세션 테이블 허용 목록을 축소하십시오(Kubernetes에서는troubleshooter.allowedTables, VM에서는troubleshooter.allowed_tables). - 모든 troubleshooter 출력은 마스킹됩니다. IPv4 및 IPv6 주소, Bearer 토큰, AWS 액세스 키, 이메일, JWT, SSH 프라이빗 키, 연결 문자열 자격 증명에 대한 내장 패턴과 정의한 모든 패턴이 적용됩니다. 데몬은 마스킹되지 않은 상태로 실행하는 대신 패턴 파일이 유효하지 않으면 시작을 거부합니다.
- 저장 시 자격 증명 노출을 최소화합니다. Provisioning SQL에는 평문 비밀번호가 아닌 bcrypt 해시가 포함됩니다. 등록 토큰은 명령줄, 디스크 또는 로그에 기록되지 않으며, 키는 Kubernetes Secrets 또는 권한 모드가 0600인 파일에 저장됩니다.