> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Modelo de privilegios > Qué puede y qué no puede hacer exactamente ClickHouse Connector: conexiones salientes, privilegios de ClickHouse, RBAC de Kubernetes, atribución y minimización de datos 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](/docs/es/products/bring-your-own-cloud/connector/architecture).
## 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. | Destino | Protocolo | Finalidad | | ----------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | El endpoint de la API del conector de su organización | HTTPS con mTLS; cada solicitud se firma con HMAC | `POST /v1/metrics`, `/v1/self-metrics`, `/v1/status`, `/v1/instance/sync`, `/v1/infra/sync`, `/v1/backup/sync`, `/v1/pcm/cert/renew` | | El endpoint de la API del conector de su organización | WebSocket saliente, `/v1/commands/ws` | El canal de comandos del solucionador de problemas, controlado por el estado de la sesión de soporte | | El endpoint de inscripción de su organización | HTTPS (token de inscripción o HMAC; sin mTLS) | Canje de tokens y firma de certificados (`/v1/pcm/cert/sign`) durante la instalación | | Sus instancias de ClickHouse | Protocolo nativo de ClickHouse | Consultas de solo lectura como `pcm_scraper` y `pcm_troubleshooter`, además de la instrucción de vaciado de registros del scraper (consulte [privilegios](#clickhouse-grants)) | | El servidor de la API de Kubernetes | HTTPS | Lecturas con ámbito de Espacio de nombres y solicitudes de tokens de ServiceAccount (en ambos destinos); lectura y actualización por nombre exacto del secreto mTLS del propio conector para persistir certificados renovados (solo en instalaciones de Kubernetes; una VM escribe las renovaciones en sus archivos TLS locales) | | El endpoint JWKS de su proveedor de identidad | HTTPS | Validación de tokens de operador, solo cuando el gateway de sesión está habilitado | 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: ```sql theme={null} CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY ''; 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`; ``` `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. ```sql theme={null} CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY ''; 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`; ``` 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_`) 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. | Recursos | Verbos | Ámbito | | ----------------------------------------------------------------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `secrets` | `get` | Solo nombres exactos: el secreto mTLS, el secreto HMAC y cada secreto de paquete de acceso por instancia | | `secrets` | `update` | Solo el secreto mTLS, por nombre exacto, para que los demonios puedan persistir el certificado de cliente renovado automáticamente | | `serviceaccounts/token` | `create` | Solo nombres exactos: la propia ServiceAccount del componente y cada ServiceAccount de paquete de acceso por instancia | | `pods`, `pods/log`, `pods/status`, `services`, `configmaps`, `events`, `persistentvolumeclaims` | `get`, `list`, `watch` | Solo para el solucionador de problemas | | `deployments`, `statefulsets`, `replicasets` (`apps`) | `get`, `list`, `watch` | Solo para el solucionador de problemas |
## 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](/docs/es/products/bring-your-own-cloud/connector/support-sessions). * **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](/docs/es/products/bring-your-own-cloud/connector/configuration). * **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](/docs/es/products/bring-your-own-cloud/connector/reference/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.