⭐ El catálogo como ORIGEN del grafo — por qué OpenFGA es la pieza, no un rodeo

1 · La tesis de producto, y qué exige de la infraestructura

Eso último no es un eslogan: es un requisito técnico con una consecuencia dura.

Si el grafo hereda en vez de re-declarar, entonces el sustrato de permisos tiene que ser transitable por relaciones — porque «¿puede este agente ver este Pod?» se responde recorriendo Pod → Table → Namespace → Warehouse → Workspace. Un modelo de permisos plano (una fila por principal × privilegio × objeto) no responde eso sin programarlo a mano.

⇒ El sustrato tiene que ser un grafo. Y eso es exactamente lo que es OpenFGA.

2 · Por qué OpenFGA encaja — verificado, no supuesto

① Es ReBAC (Zanzibar): las preguntas de autorización son preguntas de grafo

Tuplas (objeto, relación, usuario) — la misma forma que una arista. La topología del permiso y la topología del conocimiento son el mismo tipo de estructura.

② El modelo de Lakekeeper ya es jerárquico y bidireccional

Tipos: Server · Project · Warehouse · Namespace · Table · View · Generic Table · Role · Tag. Relaciones: ownership · grants · describe · select · create · modify · manage_tags.

③ El bridge OPA es OSS — la lección de Cedar no se repite

Son ficheros Rego en el repo público, no un binario de la edición comercial. Es una instancia de OPA cargando esas políticas; Trino apunta a opa.policy.uri=…/v1/data/trino/allow y opa.policy.batched-uri=…/v1/data/trino/batch.

⚠️ Y es la diferencia con Cedar, que sí era comercial y arrancaba fingiendo estar activo. Aquí hay código que se puede leer antes de desplegar.

④ Y el propio proyecto enuncia el argumento del usuario

⑤ En OSS, OpenFGA no es una opción: es la única

crates/authz-openfga es el único backend del build Apache-2.0 (Cedar es comercial). ⇒ si queremos que el catálogo autorice, es OpenFGA o nada.

3 · La cuña frente a Stardog — y es mayor de lo que parece

Medido en su documentación:

4 · La arquitectura resultante

   agentes · LLMs · humanos                    BI · notebooks · JDBC
            │                                            │
            ▼                                            ▼
   ┌─────────────────┐                          ┌─────────────────┐
   │  GRAFO SEMÁNTICO│                          │      TRINO      │
   │  Pods · ontología│                         └────────┬────────┘
   └────────┬────────┘                                   │ nativo
            │  hereda por RELACIÓN                       ▼
            │                                    ┌───────────────┐
            │                                    │      OPA      │  ← bridge (Rego, OSS)
            │                                    └───────┬───────┘
            └───────────────┬────────────────────────────┘
                            ▼
                  ┌─────────────────────┐
                  │      OPENFGA        │   ReBAC · el GRAFO de permisos
                  └──────────┬──────────┘
                             │
                  ┌─────────────────────┐
                  │  LAKEKEEPER (cat.)  │  +  INDEX (lo que el catálogo no sabe:
                  └─────────────────────┘      linaje, calidad, tier, ontología)

El punto que hay que retener: Trino no habla con OpenFGA. Habla con OPA, que es su mecanismo nativo, y el bridge traduce. Nadie escribe políticas de negocio en Rego.

5 · Las cinco tensiones — dichas antes de comprometerse

🔴 T1 · ¿Quién es la SSOT de permisos: Index u OpenFGA?

Hoy principal_grants de Index decide y la cara aplica — probado en F2 (403 por schema, CREATE TABLE denegado). Meter OpenFGA sin decidir esto crea dos sistemas afirmando autoridad sobre el mismo hecho, que es literalmente el error del espejo de nombres que N·1 corrigió.

La respuesta coherente con la tesis:

⇒ principal_grants migra a OpenFGA y la cara pasa a consultarlo. No es cableado: es mover la autoridad. Y hay que decidirlo antes de escribir una línea.

🟠 T2 · El modelo de Index es MÁS RICO que el de Lakekeeper

Index: CATALOG_* · SCHEMA_* · TABLE_* · VIEW_* · POLICY_* · WORKSPACE_* (con TABLE_READ_PROPERTIES ≠ TABLE_READ_DATA, que es la distinción que hace posible el vending). Lakekeeper: ownership · grants · describe · select · create · modify · manage_tags.

⇒ [confirmar] el mapeo, privilegio a privilegio. Si algo de Index no tiene equivalente —sospecha principal: la separación metadata vs datos— o se modela con tipos propios, o se queda en Index y hay dos planos por razón, no por descuido.

🟠 T3 · ⚠️ ¿Podemos añadir NUESTROS tipos al modelo? — la incógnita que decide la jugada

Para que un Pod herede permisos por relación, tiene que ser un objeto en el grafo de OpenFGA, con una relación hacia su Table.

• OpenFGA soporta modular models: «types can be defined across different modules and files», para que cada equipo evolucione lo suyo.
• Pero Lakekeeper gestiona SU store y escribe su modelo, y los modelos de OpenFGA son inmutables (versionados).

⇒ [confirmar] con OpenFGA desplegado: ¿se puede extender el modelo de Lakekeeper con un módulo propio, o hacen falta dos stores y una relación entre ellos? De esto depende que la herencia sea nativa o haya que puentearla — y es la única pregunta de este documento que no se puede responder leyendo.

🟡 T4 · Sigue siendo UNA capa, no dos

La propia doc avisa: «ensure that no users have root access to trino or OPA as those contain credentials to Lakekeeper with very high permissions». Es el mismo modelo de confianza que el runbook ya tiene escrito (compute enforces permissions) y la misma raíz que trino#27917. OpenFGA no lo cambia. El aislamiento duro se sigue comprando con cluster por inquilino.

🟡 T5 · Un servicio más

OpenFGA v1.11+, con su datastore. Coste operativo real, y hay que presupuestarlo.

6 · Lo que esto cambia en F4

El reconocimiento recomendaba B (OPA alimentado por Index). Queda sustituido por A, con un motivo que no es de autorización sino de producto: B no da herencia topológica —habría que programarla— y la herencia es el mecanismo de la tesis, no un detalle.

7 · Lo que sigue sin resolver

• Row filters y column masks siguen sin salir de aquí: OpenFGA responde «¿puede ver esta tabla?», no «qué filas». Eso sigue siendo F4·b y sigue exigiendo un modelo de políticas de fila que Index hoy no tiene.
• El orden frente a H1 (namespace plano). La herencia de OpenFGA es sobre namespaces jerárquicos; conviene decidir H1 antes de poblar tuplas, o se poblarán dos veces.

Cruza con: f4-opa-reconocimiento.md (el terreno medido, cuya recomendación esto corrige) · trino-first-viraje.md · agentic-data-cloud.md (la tesis de producto) · warehouse-index.md (qué se queda en Index) · infra/lakekeeper/policies/README.md.