Skip to main content
Esta página es la referencia de seguridad de ClickHouse Connector: el conjunto completo de conexiones que establece, los privilegios exactos de los que dispone, lo que estructuralmente no puede hacer y cómo se atribuye cada acción. Para ver cómo encajan las piezas, consulte la arquitectura.

Qué puede hacer el conector

Conexiones salientes

Esta es la lista completa de conexiones que abre el conector. Todas se originan dentro de su entorno. En sentido entrante, el conector expone únicamente puertos locales de comprobación de estado y métricas, además del gateway de sesión opcional. No hay ningún otro servicio en escucha, y ClickHouse Cloud nunca se conecta a su entorno: solo puede responder al WebSocket saliente del solucionador de problemas.

Privilegios de ClickHouse

El aprovisionamiento crea un usuario de solo lectura por componente. La única excepción a las operaciones exclusivamente de lectura es el privilegio SYSTEM FLUSH LOGS del scraper que se indica a continuación, que no permite leer ni modificar nada; solo fuerza a las tablas de logs a persistir las entradas que ya tienen en búfer. Los usuarios se crean con IDENTIFIED WITH bcrypt_hash, por lo que en el SQL de aprovisionamiento solo existe un hash bcrypt con sal; la contraseña en texto plano solo se encuentra en el archivo de credenciales que el demonio lee en tiempo de ejecución. Los privilegios son exactamente los siguientes, con los conjuntos de tablas predeterminados:
READ ON REMOTE es necesario porque las consultas de scrape encapsulan cada tabla del sistema en clusterAllReplicas(). SYSTEM FLUSH LOGS debe concederse con alcance global porque ClickHouse rechaza alcances más restringidos para ese privilegio; ClickHouse solo lo aplica a las tablas del sistema *_log, por lo que el privilegio concedido es más amplio que la capacidad real.
El privilegio system.user_directories para ambos usuarios es necesario únicamente para un diagnóstico: clicklink clctl preflight se ejecuta con las credenciales del propio conector y comprueba cómo la instancia almacena sus usuarios de ClickHouse (de forma replicada o local). La tabla contiene metadatos de configuración del almacenamiento de usuarios, no datos de usuario, y no está incluida ni en el conjunto de scrape ni en la lista de permitidos de la tabla de sesión, por lo que ninguna ruta de salida de scrape o sesión la lee; sin este privilegio, esa única comprobación preflight se marca como omitida y todo lo demás continúa. Además de SELECT por tabla, el único privilegio de sistema del scraper es SYSTEM FLUSH LOGS: fuerza a las tablas del sistema *_log a persistir en disco las entradas almacenadas en el búfer para que los scrapes vean los datos actualizados, y no hace nada más; ClickHouse solo lo admite para las tablas de logs, aunque el privilegio solo puede concederse en el ámbito global. No hay privilegios de INSERT, DDL, administración de usuarios, configuración ni control de procesos. Cuando una segunda implementación del conector comparte una instancia, sus usuarios llevan un sufijo (pcm_scraper_<suffix>) con los mismos conjuntos de privilegios.

RBAC de Kubernetes

El chart crea únicamente Roles con ámbito de espacio de nombres; no hay ningún Rol de clúster ni ClusterRoleBinding.

Lo que el conector no puede hacer

  • No escribe datos ni estado en ClickHouse. Los privilegios anteriores no incluyen INSERT, DDL ni privilegios de administración de usuarios, configuración o control de procesos; el único privilegio de clase SYSTEM, SYSTEM FLUSH LOGS del scraper, únicamente hace que las tablas de logs persistan lo que ya tienen en búfer. El conector no puede modificar datos, esquemas, usuarios ni configuración.
  • Sin exec. RBAC no incluye pods/exec; el conector no puede ejecutar comandos en tus pods.
  • Sin delete ni patch. RBAC permite dos mutaciones: el update con nombre exacto del secreto mTLS del propio conector y create en serviceaccounts/token, que genera tokens de corta duración para las propias ServiceAccounts del conector y no modifica ningún objeto almacenado.
  • Sin alcance de cluster. Cada Role está vinculado a un espacio de nombres; el conector no puede enumerar ni leer recursos fuera de los espacios de nombres que le hayas concedido.
  • Nada entrante. ClickHouse Cloud nunca abre una conexión hacia tu entorno. La única vía para ejecutar comandos es el WebSocket saliente del solucionador de problemas, que rechaza cualquier comando a menos que esté activa una sesión de soporte que hayas habilitado. Incluso durante una sesión, el alcance está limitado por ambos lados: las consultas de ClickHouse se restringen a la lista de permitidos de tablas, y el validador deniega query_log y text_log independientemente de la configuración, mientras que el acceso a Kubernetes se limita por separado a las vistas de solo lectura y los logs de los pods que conceden los Roles con alcance de espacio de nombres.

Qué requiere su intervención

  • Sesiones de soporte. La resolución interactiva de problemas solo se realiza dentro de una sesión que habilite, con una duración predeterminada de 4 horas y máxima de 24 horas. Deshabilitarla surte efecto de inmediato. Consulte las sesiones de soporte.
  • La lista de permitidos de operadores. Cada solicitud al gateway debe incluir un token OIDC cuyo correo electrónico certificado figure en su lista de permitidos. Una lista de permitidos vacía no permite el acceso. Usted administra la lista; consulte la guía de configuración.
  • Exposición del gateway. El gateway de sesión está desactivado salvo que lo habilite y solo es accesible mediante reenvío de puertos, a menos que opte por un Ingreso. En una VM, cada operador debe fijar la huella digital de su certificado autofirmado antes de que los comandos de sesión puedan comunicarse con él.
  • Salida de red. Con un CNI que aplica las políticas de red, el conector no tiene salida hasta que incluya los CIDR del endpoint en la lista de permitidos de la NetworkPolicy del chart.

Cómo se atribuye el acceso

  • Identidad de la implementación. El nombre común del certificado de cliente mTLS es el ID de su org, con un único nombre DNS asociado al host de su endpoint, por lo que cada conexión a la API puede atribuirse a su org. La renovación es automática y se realiza dentro del demonio; ningún operador manipula el material de claves.
  • Integridad de las solicitudes. Cada solicitud a la API también incluye una firma HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) calculada a partir del método, la ruta, la marca de tiempo y el hash del cuerpo, mediante el par de claves emitido durante el registro.
  • Identidad del operador. Las llamadas al gateway se atribuyen al correo electrónico certificado por el token de ID OIDC del operador, que se verifica con los JWKS de su proveedor de identidad; nunca se confía en un nombre declarado por el propio usuario cuando hay un token disponible.
  • Registro de auditoría. Cada llamada al gateway y cada comando de diagnóstico, aceptado o bloqueado, se añade al registro de auditoría NDJSON: las entradas del gateway incluyen el correo electrónico certificado del operador, los cambios de sesión local de la VM incluyen el usuario host que los invoca y los comandos de sesión incluyen la identidad de la org transmitida por el canal autenticado. Consúltelo con clicklink clctl troubleshoot audit tail; consulte la referencia de la CLI.

Valores predeterminados de minimización de datos

  • query_log se excluye de los scrapes de forma predeterminada. Sus columnas contienen SQL sin procesar con valores literales, que pueden incluir datos personales o secretos, por lo que no sale de su perímetro a menos que lo añada deliberadamente.
  • El solucionador de problemas solo lee tablas incluidas en la lista de permitidas, y el validador deniega query_log y text_log incondicionalmente, por lo que el historial de consultas nunca puede leerse. La lista de permitidas predeterminada incluye system.processes (texto de consultas activas); restrinja la lista de permitidas de tablas de sesión (troubleshooter.allowedTables en Kubernetes, troubleshooter.allowed_tables en una VM) si debe permanecer oculto durante las sesiones.
  • Toda la salida del solucionador de problemas se redacta con patrones integrados para direcciones IPv4 e IPv6, tokens Bearer, claves de acceso de AWS, direcciones de correo electrónico, JWT, claves privadas SSH y credenciales de cadenas de conexión, además de cualquier patrón que defina. El demonio se niega a iniciarse si el archivo de patrones no es válido, en lugar de ejecutarse sin redactar.
  • Las credenciales se minimizan en reposo. El SQL de aprovisionamiento contiene hashes bcrypt, nunca contraseñas en texto sin formato; el token de inscripción nunca se escribe en la línea de comandos, el disco ni los registros; las claves se almacenan en secretos de Kubernetes o archivos con modo 0600.
Última modificación el 26 de agosto de 2026