FAQ
내 환경 외부로 전송되는 데이터는 무엇입니까?
metric_log, asynchronous_metric_log, tables, warnings, server_settings)의 결과, 상태 및 상태 정보 하트비트, 인스턴스 및 백업 상태, 그리고 connector 자체 메트릭을 전송합니다. 기본 스크레이프 집합에서는 의도적으로 system.query_log를 제외하므로, 원시 SQL 텍스트와 그 안의 리터럴 또는 개인 데이터는 명시적으로 추가하지 않는 한 스크레이프 경로를 통해 외부로 전송되지 않습니다. 세션 중에는 기본 테이블 허용 목록에 실시간 쿼리 텍스트를 표시하는 system.processes가 포함됩니다. 이를 숨겨야 한다면 허용 목록에서 제거하십시오.
활성 지원 세션 중 troubleshooter는 허용 목록에 있는 ClickHouse 테이블 및 파드 로그를 포함한 읽기 전용 Kubernetes 뷰로 범위가 제한된 명령 출력도 반환합니다. 이 출력은 전송 전에 IP, 자격 증명, 토큰, 키에 대한 기본 제공 패턴과 직접 추가한 패턴을 통해 민감 정보가 마스킹됩니다. 테이블 데이터, 백업, 쿼리 이력(system.query_log, system.text_log)은 예외 없이 환경 내부에 유지됩니다. 문서화된 예외는 다음과 같습니다. 허용 목록에 있는 메트릭 이력 테이블(system.metric_log, system.asynchronous_metric_log)의 행은 모든 스크레이프와 함께 전송되고, 실시간 쿼리 텍스트는 허용 목록에서 제거하지 않는 한 system.processes를 통해 세션에서 표시되며, Kubernetes 지원 세션 중 읽은 파드 로그는 민감 정보가 마스킹된 후 외부로 전송됩니다. 전체 아웃바운드 연결 목록은 권한 모델 페이지에서 확인할 수 있습니다.
ClickHouse의 액세스 권한을 어떻게 철회합니까?
- 대화형 액세스를 종료합니다. VM 호스트에서
sudo clicklink clctl troubleshoot session disable명령어로 세션을 비활성화하거나, Kubernetes에서는 포트 포워딩을 통해--gateway-url을 추가하여 동일한 명령어를 실행합니다(정확한 명령어는 지원 세션 페이지 참조). 활성 세션이 없으면 troubleshooter는 연결된 상태에서도 모든 명령어 실행을 거부합니다. - 향후 세션을 차단합니다. 연산자 허용 목록을 비우거나(허용 목록가 비어 있으면 gateway가 닫힘) gateway를 비활성화합니다. VM에서는 호스트의 root 사용자가 로컬 세션 관리를 계속 사용할 수 있습니다. 구성 가이드를 참조하십시오.
- ClickHouse Cloud 연결을 차단합니다. 네트워크 계층에서 connector endpoint로의 egress를 차단하거나, 강제 적용되는 CNI에서
networkPolicy.allowEgressCIDRs를 비웁니다. connector는 아웃바운드 전용이므로 ClickHouse Cloud에는 연결을 복원할 인바운드 경로가 없습니다. 워크로드를 중지하거나 제거할 때까지 ClickHouse에 대한 로컬 읽기는 계속됩니다. 이를 중지하거나 제거하는 것이 완전한 차단 방법입니다. - 자격 증명을 철회합니다.
pcm_scraper및pcm_troubleshooterClickHouse 사용자를 삭제하고 connector의 시크릿(Kubernetes) 또는/etc/clicklink아래의 파일(VM)을 삭제합니다. - connector를 완전히 제거합니다. 운영을 참조하십시오.
에어갭 환경에서 실행하거나 자체 미러를 사용할 수 있습니까?
releases.clicklink.clickhouse.com 및 공개 레지스트리의 CLI tarball과 컨테이너 image를 미러링하고, image.repository를 미러로 지정한 다음, oci:// 참조, URL 또는 로컬 아카이브와 함께 --chart를 전달하십시오(--chart-version을 사용하며, 기본값은 CLI 자체 버전입니다). 커넥터 API endpoint가 사설 CA 뒤의 보안 경계 내부에서 제공되는 경우, --api-private-ca(Kubernetes) 또는 api.tls.ca_file(VM)는 등록 번들의 체인에 대해 이를 검증합니다. 직접 연결 없이 등록하려면 init --handoff에서 대역 외로 확보한 번들을 사용하고, --no-auto-sign과 init --signed-cert를 함께 사용하여 인증서 서명을 대역 외로 완료할 수 있습니다. 사설 미러 및 온보딩의 에어갭 섹션을 참조하십시오. 커넥터는 런타임에도 조직의 커넥터 API endpoint에 연결할 경로가 필요합니다. 경로가 없으면 ClickHouse Cloud는 telemetry를 수신하지 못합니다.
connector가 중단되면 어떻게 되나요?
/var/lib/clicklink/buffer에 스풀링합니다(기본값: 최대 168시간 또는 1024MB). 연결이 복구되면 해당 데이터를 전송하므로 endpoint 장애로 telemetry가 손실되지는 않습니다. daemon이 크래시하면 systemd가 다시 시작하고, Kubernetes에서는 큐블릿이 다시 시작합니다. 문제를 진단하려면 각 component의 /livez endpoint를 확인하고(HTTP 코드가 아니라 JSON status field를 확인), clicklink clctl preflight를 실행하십시오(VM 호스트에서는 sudo 사용). 이 명령은 구성, 연결 상태, ClickHouse 연결 가능 여부, 액세스 및 디스크를 한 번에 확인합니다. operations를 참조하십시오. connector가 계속 비정상 상태이면 ClickHouse 지원팀에 문의하십시오.
지원 세션은 어떻게 감사되나요?
/var/log/clicklink/troubleshoot-audit.log의 감사 로그에 추가됩니다. gateway 호출에는 토큰으로 검증된 연산자 이메일(자체 입력한 이름은 사용하지 않음)이 기록되고, VM 로컬 세션 변경에는 이를 호출한 host 사용자가 기록되며, 세션 중 실행된 명령어에는 인증된 채널의 org 아이덴티티가 기록됩니다. 세션 자체에는 시간 제한이 적용되며(기본 4시간, 최대 24시간), 활성화할 때마다 활성화한 주체, 만료 시점, 선택적 사유가 기록됩니다. 이 정보는 clicklink clctl troubleshoot session status에서 표시됩니다.
clicklink clctl troubleshoot audit tail 명령어로 로그를 읽으십시오. Kubernetes에서는 이 명령어가 지원되는 reader입니다(런타임 image에는 셸이 없음). 기본값인 persistence.enabled: true를 사용하면 로그는 troubleshooter의 영구 volume에 저장되므로 파드가 재스케줄링된 후에도 감사 추적이 유지됩니다. persistence를 비활성화하면 감사 로그와 세션 state는 파드 수명 동안에만 유지되며, chart 자체에서도 이를 로컬 개발에만 적합한 것으로 표시합니다. 기본적으로 교체는 최대 128 MB 크기의 파일 5개를 168시간 동안 유지합니다. 조정 방법은 구성 참고를, 전체 신뢰 모델은 지원 세션을 참조하십시오.