Skip to main content
Una sesión de soporte otorga a ClickHouse acceso temporal con fines de diagnóstico mediante ClickHouse Connector. Esta página explica qué es una sesión, cómo activarla y desactivarla, qué pueden hacer los ingenieros de soporte de ClickHouse durante una sesión y cómo auditarla.

​
Qué es una sesión de soporte

Una sesión de soporte es una ventana de tiempo acotada en la cual el solucionador de problemas acepta comandos de los ingenieros de soporte de ClickHouse. Fuera de una sesión, rechaza todos los comandos, incluso mientras su WebSocket saliente permanece conectado. No existe ninguna otra vía de ejecución, y ClickHouse no puede abrir una sesión en su nombre. ClickHouse Cloud nunca se conecta a su entorno; solo recibe lo que el solucionador de problemas envía por su canal saliente. Las sesiones rigen únicamente los diagnósticos. Los comandos de ciclo de vida de los servicios en modo Managed viajan por el canal independiente del executor, que una sesión de soporte ni abre ni controla; consulte servicios administrados. Usted controla las sesiones a través de dos superficies:
  • El gateway de sesión, una API autenticada integrada en el solucionador de problemas. Expone POST /v1/clctl/session/enable, POST /v1/clctl/session/disable y GET /v1/clctl/session/status. Cada llamada requiere un token de ID OIDC de corta duración cuyo correo electrónico figure en su lista de permitidos de operadores.
  • El archivo de sesión local, en las instalaciones en VM Linux, escrito en el host con acceso root.
El transporte del gateway depende del destino. Un gateway en VM expone TLS autofirmado cuya huella digital fija cada operador. Un gateway en Kubernetes escucha de forma local en el pod de Kubernetes sobre HTTP; se accede a él mediante kubectl port-forward (el túnel viaja sobre el TLS del API server) o mediante un Ingreso que termina TLS con un certificado emitido por una CA. Usted define su postura de sesión, incluida la lista de permitidos de operadores, durante clicklink clctl init.

​
Activación y desactivación de sesiones

El gateway escucha en el puerto 8443 del pod de Kubernetes del solucionador de problemas. Con acceso al clúster, acceda a él mediante un reenvío de puertos:
A continuación, en otra terminal, active una sesión:
Compruebe o finalice la sesión del mismo modo:
La identidad OIDC del llamador debe estar en la lista de permitidos de operadores. Los llamadores no autenticados o que no figuren en la lista recibirán un 401 o un 403, y el gateway registrará el intento. Para que los operadores puedan trabajar sin credenciales del clúster, exponga el gateway mediante el Ingreso opcional del chart, que termina TLS con un certificado emitido por una CA; consulte la configuración.

​
Caducidad de la sesión

Las sesiones caducan automáticamente. La duración predeterminada es de 4 horas; session enable --duration acepta hasta 24 horas. Al caducar, o en cuanto ejecuta session disable, el solucionador de problemas deja de aceptar comandos. Deshabilitarla revoca el acceso de inmediato: no requiere reiniciar ni coordinarse con ClickHouse.

​
Lista de permitidos de operadores

Cada llamada al gateway se autoriza conforme a una lista de permitidos de correos electrónicos de operadores. El cotejo utiliza el correo electrónico acreditado por el token OIDC validado, nunca un valor que proporcione el client.
  • Kubernetes: configure clctl.gateway.allowedOperators en su superposición de values. El chart procesa la lista en un ConfigMap, por lo que un cambio en values junto con helm upgrade rota la lista de permitidos sin reiniciar el pod de Kubernetes.
  • VM Linux: la lista de permitidos se encuentra en /etc/clicklink/allowed-operators.txt y clicklink clctl init la escribe a partir de los correos electrónicos de operadores que proporcione.
En ambos targets, el gateway vuelve a leer el archivo en la siguiente request una vez transcurridos 30 segundos desde la última lectura. Las modificaciones surten efecto sin reiniciar.

​
Qué pueden hacer los operadores durante una sesión

Mientras una sesión está activa, los ingenieros de soporte de ClickHouse pueden ejecutar dos tipos de comandos. SQL de solo lectura se ejecuta sobre sus clusters con el usuario pcm_troubleshooter, cuyos grants se limitan a la lista de permitidos de tablas de la sesión. El solucionador de problemas también rechaza cualquier sentencia que no comience por SELECT, WITH, SHOW, DESCRIBE o EXPLAIN. El usuario solo dispone de grants de SELECT por tabla, sin privilegios de escritura, DDL ni de administración. La lista de permitidos predeterminada abarca tablas de system como system.parts, system.merges, system.replicas, system.metrics y system.settings. system.query_log y system.text_log no pueden añadirse a ella: el daemon rechaza cualquier configuración que las incluya, por lo que nunca se aprovisiona un grant sobre ellas. La lista de permitidos predeterminada sí incluye system.processes, cuya columna query muestra el texto de las sentencias en ejecución. Elimínela de troubleshooter.allowedTables (overlay de Helm) o de troubleshooter.allowed_tables (archivo de configuración de la VM) si el texto de las consultas en vivo nunca debe ser visible en una sesión. Las vistas de Kubernetes de solo lectura son get, list y watch sobre pods, estado de pods, logs de pods, services, configmaps, eventos, PersistentVolumeClaims, deployments, statefulsets y replicasets en los espacios de nombres concedidos. Los access bundles están vinculados a ServiceAccounts de Kubernetes en ambos destinos de instalación. Sin un paquete aprovisionado, el solucionador de problemas rechaza de plano los comandos de tipo kubectl. El executor aprovisiona el scraper para un managed service, pero no el solucionador de problemas; consulte sesiones de soporte para un managed service. El RBAC del solucionador de problemas no contiene ningún permiso exec, delete ni patch, de modo que los operadores no pueden abrir una shell en sus pods ni modificar nada a través de una sesión. La enumeración completa de grants y RBAC se encuentra en la referencia del modelo de privilegios.

​
Log de auditoría

Cada comando ejecutado durante una sesión se añade a /var/log/clicklink/troubleshoot-audit.log como un objeto JSON por línea (NDJSON). Los comandos bloqueados también se registran, indicando en blocked_by el motivo (por ejemplo, session inactive). submitted_by es el Organization ID del canal de comandos: el ID de su propia organización. El ingeniero de ClickHouse concreto queda registrado del lado de ClickHouse Cloud, no en este archivo. Una entrada de comando de sesión tiene este aspecto:
status indica el resultado del comando: completed, error o rejected. Las llamadas al gateway se registran por separado. Cada llamada, incluidas las rechazadas, se emite como una línea estructurada clctl.gateway en el log propio del solucionador de problemas: el journal en una VM o el log del contenedor en Kubernetes. La línea contiene submitted_by (el correo electrónico acreditado por el token validado, nunca un valor proporcionado por el client) y command_type (clctl.session.enable, clctl.session.disable o clctl.session.status). También contiene reason (el --reason de la habilitación), remote_addr y status. status puede ser ok, unauthorized, forbidden, rate_limited, bad_request, conflict o error, de modo que los accesos denegados también quedan reflejados en el log. Los cambios de sesión locales en una VM no son entradas del log de auditoría. El usuario del host que invoca el comando se registra como enabled_by en /var/lib/clicklink/session.json y se muestra mediante session status. En una VM, consulta el log de auditoría con clicklink clctl troubleshoot audit tail. En Kubernetes, el log reside dentro del pod de Kubernetes del solucionador de problemas y la imagen del contenedor no incluye shell, así que invoca el reader propio del binary mediante kubectl exec:
El log de auditoría es un archivo plano dentro de su entorno; envíelo a su propio SIEM como cualquier otro log de host o de contenedor.

​
Redacción

Todo lo que devuelve el solucionador de problemas se censura antes de salir de su entorno. Los patrones integrados cubren direcciones IPv4 e IPv6, tokens Bearer, claves de acceso de AWS, direcciones de correo electrónico, JWT, claves privadas SSH y credenciales incluidas en cadenas de conexión. Puede ampliarlos o sobrescribirlos en /etc/clicklink/redaction-patterns.yaml; una entrada con el mismo nombre que un patrón integrado lo reemplaza. El daemon no se inicia si el archivo de patrones no es válido, y clicklink clctl preflight lo valida, de modo que una configuración de redacción incorrecta falla de forma explícita.
  • Arquitectura: todas las conexiones que realiza el conector y el flujo de datos en las sesiones.
  • Configuración: configuración de gateway, allowlist y redacción.
  • FAQ: respuestas breves a preguntas sobre revocación, auditoría y salida de datos.