Runbook · Abrir Trino a clientes externos (Stardog, BI, notebooks)

Por qué existe. Hoy Trino no publica ningún puerto: quien le habla es el
contenedor de ingesta de OpenMetadata, por la red interna de Docker. Eso no es
una omisión, es una decisión — el propio docker-compose.trino.yml la explica:
publicarlo pondría en internet un motor SQL sin autenticación con lectura
sobre todo el Warehouse.

Este runbook es lo que hay que hacer para abrirlo sin que eso ocurra.

⚠️ Son cuatro piezas, y van las cuatro o ninguna. Tres de cuatro deja el
motor abierto sin autenticar, que es peor que no abrirlo.

0 · Antes de nada: ¿de verdad hace falta abrirlo?

Léase esto antes de tocar la VM. Si el cliente externo es Stardog —o cualquier cosa que consulte el Warehouse— hay un orden que cambia el resultado:

	Camino	Qué pasa
❌	Stardog → Trino → Lakekeeper	Entra por fuera de Index Catalog. Sin grants, sin registro, sin políticas. Es exactamente el agujero que C5 cierra
✅	Stardog → Trino → Index Catalog → Lakekeeper	Hereda la gobernanza sin configurar nada: autorizado por los grants de `lakekeeper-trino`, registrado en `access_events`, sujeto a las políticas

⇒ Haz primero el paso ④ de index-catalog-rest-face.md —repuntar Trino a /api/iceberg— y después esto. El orden inverso funciona igual de bien el primer día y deja una puerta trasera para siempre.

📌 Consecuencia visible, para que no sorprenda: con los grants actuales,
lakekeeper-trino sólo lee el schema default. main.test se dejó sin
conceder a propósito como control negativo del canario, así que un cliente
externo verá 91 tablas y no 112. Es correcto.

1 · Las cuatro piezas

	Pieza	Fichero	Estado
1	Autenticador de contraseña	`trino/password-authenticator.properties`	✅ escrito
2	El htpasswd	se genera en la VM — no va en git	⬜
3	Vhost con TLS	`Caddyfile`, al final	✅ escrito, comentado
4	Las dos líneas de Trino	`trino/config.properties`, al final	✅ escrito, comentado

2 · Ejecución

① El htpasswd, en la VM

mkdir -p ~/openmetadata/trino/auth
docker run --rm httpd:2.4-alpine htpasswd -nbB stardog '<contraseña-larga>' \
  > ~/openmetadata/trino/auth/password.db
chmod 600 ~/openmetadata/trino/auth/password.db

-B es bcrypt y no es opcional: Trino rechaza MD5 y SHA-1. Y una cuenta por cliente —stardog, bi, …— porque revocar una sin tocar a las demás es la única forma de que la revocación llegue a hacerse.

② Montarlo, en `docker-compose.trino.yml`

    volumes:
      - ./trino/config.properties:/etc/trino/config.properties:ro
      - ./trino/access-control.properties:/etc/trino/access-control.properties:ro
      - ./trino/password-authenticator.properties:/etc/trino/password-authenticator.properties:ro   # ← nuevo
      - ./trino/auth:/etc/trino/auth:ro                                                             # ← nuevo
      - ./trino/catalog:/etc/trino/catalog:ro

⚠️ expose se queda como está. No lo cambies a ports. Que el 8080 no salga
de la red de Docker es lo que hace seguro el process-forwarded=true del paso ④:
si el puerto quedara publicado, un cliente podría poner X-Forwarded-Proto a mano
y saltarse la exigencia de TLS.

③ Descomentar el vhost en el `Caddyfile`

Y antes, el registro DNS: A trino.<dominio> → <IP de la VM>. Caddy pide el certificado al arrancar y necesita el 80 abierto y el DNS ya propagado — en ese orden, no al revés.

sudo caddy validate --config /etc/caddy/Caddyfile   # valida ANTES de recargar
sudo systemctl reload caddy

④ Descomentar las dos líneas de `config.properties` y reiniciar Trino

docker compose -f docker-compose-postgres.yml \
               -f docker-compose.override.yml \
               -f docker-compose.trino.yml up -d --force-recreate trino

3 · El gate. Y el que importa es el negativo

# ① sin credenciales → 401
curl -s -o /dev/null -w '%{http_code}\n' https://trino.<dominio>/v1/info
# esperado: 401.  ⚠️ Un 200 aquí significa que el motor está ABIERTO.

# ② con credenciales → 200
curl -s -u stardog:'<contraseña>' https://trino.<dominio>/v1/info | head -c 120

# ③ la ingesta de OpenMetadata SIGUE funcionando
#    (habla por la red interna y NO se autentica — si se rompe, es que
#     `http-server.authentication.type` también aplica al camino interno)
docker compose logs --tail 50 openmetadata_ingestion | grep -i trino

El ③ es el que se olvida. Añadir autenticación a Trino afecta a todos sus
clientes, incluido el que ya funcionaba. Si la ingesta empieza a fallar, la
salida no es quitar la autenticación: es darle a OM su propia cuenta en el
htpasswd y ponerla en su conector.

4 · Los campos de Stardog, una vez hecho

Campo	Valor
Connection name	`carbon-warehouse`
Endpoint	`jdbc:trino://trino.<dominio>:443/lakehouse/main.default`
Username	`stardog`
Password	la del htpasswd

lakehouse es el catálogo (trino/catalog/lakehouse.properties).
Los schemas son de dos niveles (main.default, main.test) — por eso Trino lleva iceberg.rest-catalog.nested-namespace-enabled=true. Si Stardog tropieza con el punto del schema, déjalo fuera de la URL y califica las tablas en la consulta.
Puerto 443, no 8080: se habla con Caddy, no con Trino.

⚠️ El error Driver:org.postgresql.Driver … returned null for URL:5432 que aparece
al probar no es de esta conexión: viene de un data source Postgres anterior al
que se le pasó 5432 como URL entera. Bórralo antes para no perseguir un fantasma.

5 · Rollback

Cada pieza se deshace sola y en orden inverso: comentar las dos líneas de config.properties y recrear el contenedor · comentar el vhost y recargar Caddy · borrar el registro DNS. El htpasswd puede quedarse: sin authentication.type, Trino ni lo mira.

6 · Lo que este runbook NO hace

No añade autorización por usuario. Trino sigue con access-control.name=read-only para todos. Quién ve qué tabla lo decide Index Catalog, un nivel por debajo — que es donde debe decidirse.
No abre la UI de Trino. El vhost sirve el protocolo; la consola web sigue siendo cosa de docker compose exec trino trino.
Ya NO toca el perímetro de R2 (2026-08-04). Trino dejó de llevar llave estática: la pide en cada loadTable y se la acuña la puerta, acotada a esa tabla y con caducidad, sólo si tiene TABLE_READ_DATA. Ver storage-tenancy-approach.