Modelo de privilegios

​

Identidades

• El certificado de cliente mTLS del conector, que lleva el ID de su organización como nombre común, autentica cada demonio ante su endpoint del conector. clicklink clctl instances create utiliza el mismo certificado y la misma clave HMAC cuando llama al endpoint.
• pcm_scraper y pcm_troubleshooter son los usuarios de ClickHouse de solo lectura con los que se conectan el scraper y el solucionador de problemas. El executor no tiene ningún usuario de ClickHouse.
• Los ServiceAccounts del Troubleshooter, uno por cada implementación aprovisionada, disponen de las vistas de Kubernetes de solo lectura que puede utilizar una sesión de soporte.
• pcm-executor es el ServiceAccount de Kubernetes del executor para el ciclo de vida de los servicios gestionados. Una ValidatingAdmissionPolicy limita sus escrituras a los espacios de nombres de los servicios.
• pcm-platform es la identity del executor para las actualizaciones de la plataforma. Su comando clicklink clctl platform approve emite un token válido durante 2 horas y nunca lo renueva; entre aprobaciones, el executor no tiene acceso de escritura a la capa de la plataforma.
• El rol de IAM por servicio (CH-S3-<service>-<region>-00-Role de forma predeterminada) lo crea clicklink clctl executor prepare con sus credenciales. Está acotado a los buckets de datos y de copia de seguridad de ese servicio y solo goza de la confianza del ServiceAccount de Kubernetes de ese servicio, de modo que ni el executor ni ClickHouse pueden asumirlo.
• El perfil de instancia de la VM EC2 del conector asume el rol de pull de ECR de solo lectura de su entorno para el acceso directo a la plataforma, tanto para el inicio de sesión de charts como para las comprobaciones de imágenes. La CLI de aprobación emplea la misma ruta de perfil de instancia; los perfiles de AWS de la estación de trabajo o las credenciales de SSO no lo sustituyen. Otros registries de charts de ECR utilizan credenciales ambiente de AWS. Las descargas de imágenes se realizan en sus nodos con su propio rol de pull. El executor no guarda credenciales para sus buckets ni para IAM, y no realiza llamadas a S3 ni a IAM. Consulte credenciales del registry.
• Sus propias credenciales aplican todos los permisos: el permiso de acceso del executor en init --managed, los buckets y el rol en prepare, la mitad correspondiente a los permisos de cada actualización de plataforma en approve y la limpieza en teardown.

​

Qué puede hacer el conector

​

Conexiones salientes

​

Privilegios de ClickHouse

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

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`;

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

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`;

​

RBAC de Kubernetes

​

Scraper y solucionador de problemas

​

Executor

​

Identity de la plataforma

​

Lo que el conector no puede hacer

• Ninguna escritura sobre los datos o el estado de ClickHouse. Los grants anteriores no contienen ningún INSERT, ninguna DDL ni privilegios de gestión de usuarios, de configuración o de control de procesos. El único grant de clase de sistema, el SYSTEM FLUSH LOGS del scraper, solo hace que las log tables persistan lo que ya tienen en búfer. El executor no tiene ningún ClickHouse user. Ningún componente puede modificar datos, esquemas, usuarios ni configuración a través de ClickHouse.
• Sin exec. Ningún RBAC contiene pods/exec; ningún componente puede ejecutar comandos en tus pods.
• Ninguna escritura fuera de los espacios de nombres del service y de la plataforma. El scraper y el solucionador de problemas no tienen delete ni patch. Sus únicas mutaciones son el update con nombre exacto sobre el propio secreto de mTLS del conector y el create sobre serviceaccounts/token, que emite tokens de corta duración para sus propias ServiceAccounts y no modifica ningún objeto almacenado. La admission deniega las escrituras del executor fuera del prefijo del service, y sus escrituras en la plataforma solo existen mientras sea válido un token emitido por ti.
• Sin permiso para otorgar permisos. Tus credenciales aplican los espacios de nombres, las CRD, las ServiceAccounts, el RBAC, las configuraciones de webhook y de admission, las PriorityClasses y la clase de almacenamiento de la plataforma durante approve. La identidad de plataforma del executor no puede escalar privilegios, vincular ni suplantar. Dentro de un espacio de nombres de service, el executor solo puede crear Roles que otorguen permisos que ya posee.
• Ninguna credencial para tus buckets ni para IAM. clicklink clctl executor prepare crea los buckets y el role por service, y clicklink clctl executor teardown los elimina; ambos comandos se ejecutan con tus credenciales. El role solo puede ser asumido por los pods de ese service. Para el acceso directo a la plataforma, el executor usa el perfil de instancia de la VM EC2 del conector para asumir el role de pull de solo lectura de ECR, tanto para el inicio de sesión del chart como para las comprobaciones de imagen. Otros registros de charts de ECR usan credenciales de AWS ambientales; consulta identities. Sus únicas llamadas a APIs de la nube van a ECR y STS; no puede leer ni eliminar tus datos.
• Ningún conocimiento de la contraseña de tu usuario default. clicklink clctl executor prepare la genera en tu lado y la muestra una sola vez (o lo hace clicklink clctl instances create, cuando pasas las entradas como flags). Solo se envían sus hashes, de modo que ni el conector ni ClickHouse Cloud pueden recuperarla.
• Nada entrante. ClickHouse Cloud nunca abre una connection hacia tu entorno. Las únicas rutas de comandos son los dos WebSockets salientes. El solucionador de problemas rechaza todos los comandos salvo que esté activa una sesión de soporte que hayas habilitado. El executor acepta comandos de ciclo de vida solo para los services cuya gestión hayas solicitado a ClickHouse, dentro de los ámbitos anteriores. Incluso durante una sesión, el solucionador de problemas está limitado por ambos lados. Las consultas a ClickHouse se restringen a la lista de permitidos de tablas, que rechaza query_log y text_log, por lo que nunca se otorgan. El acceso a Kubernetes se limita a las vistas de solo lectura y a los logs de pods que otorgan los Roles acotados al espacio de nombres.

​

Qué requiere su intervención

• Habilitar el modo gestionado. El executor se ejecuta, y su grant de Kubernetes existe, solo después de que habilite el modo gestionado en init; el grant se aplica con permisos de administrador del cluster. Consulte servicios gestionados.
• Crear un servicio. clicklink clctl executor prepare se ejecuta con sus credenciales de AWS para crear los buckets y el rol de IAM, y clicklink clctl instances create envía la definición. ClickHouse Cloud no puede crear un servicio en su cluster sin ambos. Consulte crear un servicio.
• Actualizaciones de la plataforma. Cada actualización de los componentes de la plataforma se aplica solo después de que ejecute clicklink clctl platform approve para ese paquete exacto; el token que genera expira a las 2 horas y nunca se renueva. Consulte actualizaciones de la plataforma.
• Limpieza tras una eliminación. Eliminar un servicio elimina únicamente sus recursos de Kubernetes. clicklink clctl executor teardown, ejecutado con sus credenciales, elimina el rol de IAM y, solo con indicadores explícitos, los datos y los backups. Consulte eliminar un servicio.
• 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, o verificarlo con un CA bundle pasado como --gateway-ca, antes de que los comandos de sesión se comuniquen con él.
• Salida de red. Con un CNI que aplica las políticas de red, ningún demonio alcanza el endpoint del conector hasta que indique sus CIDR en networkPolicy.allowEgressCIDRs. El executor también necesita los CIDR del Kubernetes API server (networkPolicy.apiserverCIDRs), que init --managed deriva de la VPC del cluster. Si los charts de la plataforma provienen de Amazon ECR, añada también los rangos de ECR y STS.

​

Cómo se atribuye el acceso

• Identity de la implementación. El common name del certificado de client mTLS es el ID de tu org, y su único DNS name está vinculado al host de tu endpoint. Eso hace que toda connection a la API sea atribuible a tu org. La renewal es automática y se realiza dentro del demonio; ningún operador manipula el material de la clave.
• Integridad de las solicitudes. Cada API request incluye además una firma HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) sobre el method, el path, la marca de tiempo y el hash del cuerpo, usando el par de claves emitido durante la inscripción.
• Identidad del operador. Las llamadas al gateway se atribuyen al correo electrónico atestiguado por el OIDC ID token del operador, verificado frente al JWKS de tu identity provider. Nunca se confía en un nombre autodeclarado cuando hay un token disponible.
• Comandos de ciclo de vida. El executor registra en su almacén local cada comando que recibe, junto con su origin (ClickHouse Cloud o una llamada local a clicklink clctl), su stage y su resultado, e informa del resultado por el canal de comandos. Consulta el registro con clicklink clctl commands list y clicklink clctl commands get; véase la CLI reference.
• Aprobaciones de plataforma. El digest del paquete que aprobaste queda registrado en el ServiceAccount pcm-platform. Cada object aplicado con tus credenciales lleva un hash de contenido, que el executor verifica antes de escribir nada. Cualquier paquete con un digest distinto se rechaza.
• Registro de auditoría. Cada comando de sesión, aceptado o bloqueado, se añade al audit log NDJSON con la identity de la org obtenida del canal de comandos. Las llamadas al gateway se registran como líneas clctl.gateway estructuradas en el log del solucionador de problemas, con el correo electrónico atestiguado del operador. Los cambios de sesión locales en la VM registran el usuario del host en session.json. Consulta el audit log con clicklink clctl troubleshoot audit tail; véase la CLI reference.

​

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. No sale de tu perímetro a menos que lo añadas explícitamente.
• El solucionador de problemas solo lee tablas incluidas en la lista de permitidos. query_log y text_log se rechazan en la propia configuración de la lista de permitidos, de modo que nunca se conceden y el historial de consultas nunca es legible. La lista de permitidos predeterminada sí incluye system.processes (texto de las consultas en ejecución); recórtala (troubleshooter.allowedTables en Kubernetes, troubleshooter.allowed_tables en una VM) si eso debe permanecer oculto durante las sesiones.
• Toda la salida del solucionador de problemas se redacta con patrones integrados y con los que tú definas. Los integrados cubren direcciones IPv4 e IPv6, tokens bearer, claves de acceso de AWS, correos electrónicos, JWT, claves privadas SSH y credenciales de cadenas de conexión. Si el archivo de patrones es inválido, el demonio se niega a iniciarse en lugar de ejecutarse sin redactar.
• El estado del servicio gestionado son solo metadatos. El executor informa del estado de un servicio, el recuento de réplicas, las versiones y los resultados de los comandos. Nunca lee las tablas ni los buckets del servicio.
• Las credenciales se minimizan en reposo. El SQL de aprovisionamiento contiene hash bcrypt, nunca contraseñas en texto plano. La contraseña del usuario default de un servicio gestionado se muestra una sola vez y solo sale en forma de hash. El token de inscripción nunca se escribe en la línea de comandos, el disco ni los logs. Las claves residen en Kubernetes Secrets o en archivos con modo 0600.