3 min de lectura

Helicone permite a los usuarios consultar ClickHouse compartido de forma segura

Helicone añadió acceso SQL directo a una tabla compartida de ClickHouse y luego usó políticas de fila y ajustes por consulta para mantener aislados a los inquilinos.

Imagen: Hacker News

Helicone ha añadido un editor SQL llamado HQL que permite a los clientes ejecutar consultas SELECT directamente contra su clúster compartido de ClickHouse. Esa configuración coloca los datos de las peticiones de todas las organizaciones en la misma tabla, request_response_rmt, separados únicamente por una columna organization_id — lo que convierte el aislamiento entre inquilinos en el problema central.

En lugar de reescribir las consultas de los clientes en la aplicación, Helicone trasladó el límite de seguridad a la propia base de datos. La empresa usa en conjunto dos funciones menos conocidas de ClickHouse: políticas de fila y ajustes personalizados.

Se crea un usuario de base de datos dedicado, hql_user, exclusivamente para el tráfico de HQL. Helicone luego adjunta una política de fila a ese usuario para que cada SELECT sobre request_response_rmt se filtre automáticamente como si incluyera:

  • WHERE organization_id = getSetting('SQL_helicone_organization_id')

Esto es importante porque los clientes consultan todos la misma tabla subyacente, pero la base de datos aplica el aislamiento independientemente del SQL que escriban.

En ClickHouse Cloud, los ajustes personalizados deben usar el prefijo SQL_, así que Helicone pasa el ID del inquilino en cada solicitud como SQL_helicone_organization_id=<org>. En su cliente de Node, también establece protecciones como:

Recomendado

Z.AI impulsa un centro de IA de 1 GW sin chips de Nvidia

  • readonly: “1”
  • allow_ddl: 0
  • max_execution_time: 30
  • max_memory_usage: “4000000000”
  • max_result_rows: “10000”

La configuración readonly = 1 cierra un agujero obvio: ClickHouse permite que un SELECT termine con una cláusula SETTINGS, lo que de otro modo podría permitir a un cliente intentar anular el ID del inquilino. Helicone también rechaza cualquier texto de consulta que mencione el nombre de la opción reservada, aunque ClickHouse es la capa que realmente lo aplica.

Permisos de ClickHouse y límites del analizador

Helicone también redujo los privilegios de hql_user a una única permiso útil. Revoca el acceso a *system., information_schema. y default., y luego otorga solo SELECT sobre default.request_response_rmt. Esto importa porque tablas como system.query_log** podrían, de otro modo, exponer el historial de SQL de todos los inquilinos.

La aplicación todavía analiza SQL, pero solo para funciones de conveniencia como insertar o ajustar el LIMIT. Helicone usa node-sql-parser en modo PostgreSQL porque la librería no tiene dialecto de ClickHouse. Cuando el análisis falla con sintaxis específica de ClickHouse, recurre al manejo del LIMIT basado en expresiones regulares.

Crucialmente, ese analizador no es responsable de la multi-tenencia. Helicone sostiene que reescribir consultas en la aplicación es demasiado frágil, sobre todo con subqueries, CTEs, ramas UNION, self-joins, arrayJoin y subíndices de mapas como properties['user_id']. Un caso límite pasado por alto podría filtrar datos.

Pruebas con subconsultas, CTEs y consultas hostiles

Esa preocupación moldeó las pruebas de la compañía. Helicone dice que hqlSecurityTests.test.ts ejecuta 843 líneas de consultas adversarias contra una instancia real de ClickHouse con la política de fila real activada. El conjunto cubre anulación de ajustes, acceso a tablas del sistema, file(), url(), s3(), mysql(), ataques UNION, escalada de permisos y casos límite de parsing.

Una de las pruebas más simples es también la más clara: una consulta que pide a ClickHouse contar las filas de todas las demás organizaciones. El resultado es 0. La consulta se ejecuta normalmente; las filas simplemente no son visibles.

Helicone dice que la propiedad más importante del diseño es que falla en modo cerrado. Si la app olvida enviar SQL_helicone_organization_id, getSetting lanza un error y la consulta muere en lugar de devolver los datos de otra persona. Para SQL dirigido a clientes en ClickHouse, esa es la diferencia entre un fallo del parser que causa inconvenientes y uno que provoca una filtración.

Marcus Vance

Enterprise Editor

Marcus follows the money. He covers enterprise software, cloud architecture, and the tectonic shifts in Big Tech strategy. He translates dense earnings calls and complex M&A activity into actionable insights about where the industry is actually heading. If a tech giant makes a silent pivot, Marcus is usually the first to notice.

vía Hacker News

// Sigue leyendo