OpenFGA v1.21.0 es un patrón para la pregunta que el inicio de sesión nunca responde: ¿puede este técnico tocar el objeto de este cliente?

OpenFGA v1.21.0 es un patrón para la pregunta que el inicio de sesión nunca responde: ¿puede este técnico tocar el objeto de este cliente?

La realidad de un MSP son muchos tenants de clientes, técnicos con delegaciones distintas para cada cliente e integraciones de máquina que actúan por su cuenta. Tras la autenticación, la verdadera pregunta es: «¿puede este sujeto realizar esta acción sobre este objeto en este tenant?». Un token, un claim de grupo o un evento de cierre de sesión no la responden; un punto de decisión, sí. El proyecto del que se habla aquí es un patrón de referencia, no una recomendación: OpenFGA, repositorio openfga/openfga, Apache-2.0, proyecto CNCF Incubating desde el 28 de octubre de 2025 (aceptado el 14 de septiembre de 2022), descrito por sus mantenedores como un motor de autorización y permisos de alto rendimiento inspirado en Google Zanzibar.

El 5 de octubre de 2026, el repositorio de GitHub mostraba 5920 estrellas y un último push el 2 de octubre de 2026. La versión v1.21.0, publicada el 20 de septiembre de 2026, recoge una sola novedad, Dynamic Conditions, que el proyecto marca como experimental. Una versión más reciente, la v1.22.0, llegó el 6 de octubre de 2026. Este artículo no afirma que ningún producto de Altovar use OpenFGA.

El resto del texto explica cómo la autorización basada en relaciones se aplica a la multitenencia de un MSP, qué pruebas de fijación de versión y de cadena de suministro ofrecen las versiones, qué no es OpenFGA (política de admisión, overlay de red, escáneres) y seis controles para operar cualquier punto de decisión central. El inicio y el cierre de sesión y la validez del token son entradas; el derecho de acceso es una decisión que se toma en cada solicitud.

Según la descripción y los topics del repositorio, OpenFGA es un motor de autorización y permisos inspirado en Google Zanzibar. Los topics mencionan el control de acceso basado en relaciones junto a RBAC, ABAC y el acceso basado en políticas, además de «entitlements». Este artículo se ciñe a esas fuentes: no ofrece una matriz de funciones, ni cifras de rendimiento o latencia, ni una lista de usuarios.

El ReBAC al estilo de Zanzibar significa, en lenguaje de comprador, que los permisos se derivan de las relaciones entre sujetos y objetos (quién es miembro de qué tenant, qué sede pertenece a qué tenant, qué técnico tiene delegación sobre qué sede) en lugar de una larga lista de roles copiada en cada token. La decisión recorre el grafo de relaciones. No pega un catálogo de roles en cada JWT.

Gobernanza, según la página del proyecto en la CNCF consultada el 5 de octubre de 2026: aceptado en la CNCF el 14 de septiembre de 2022, Incubating desde el 28 de octubre de 2025. Incubating es un nivel de madurez dentro de un proceso de fundación. No es una certificación de seguridad ni un contrato de soporte. Un MSP que trata «CNCF Incubating» como «auditado para nuestros clientes» está leyendo una etiqueta de fundación como una garantía para el cliente que no ofrece.

El 5 de octubre de 2026, el repositorio tenía 5920 estrellas en GitHub y 511 forks. Las estrellas son una señal de popularidad, no una evaluación. La página de la CNCF muestra métricas de LFX aparte con otra cifra de estrellas; este artículo usa la cifra de GitHub y no mezcla ambas. La licencia declarada en el repositorio es Apache-2.0.

Las versiones recientes: v1.22.0 el 6 de octubre de 2026, v1.21.0 el 20 de septiembre de 2026, v1.20.0 el 8 de septiembre de 2026 y v1.19.0 el 25 de agosto de 2026. Ninguna está marcada como versión preliminar. La regla de fijación que conviene repetir: ejecutar la v1.21.0 o posterior y nada anterior, con la v1.22.0 como mejor objetivo para los nuevos despliegues porque añade una actualización de seguridad de una dependencia. No siga una imagen latest flotante en un entorno de cliente sin un ticket de cambio que nombre la etiqueta.

El mínimo no es simplemente «la más reciente». La v1.20.0 incluía una sección Security: la corrección de una CVE de la cadena de herramientas, una dependencia de la sonda de salud recompilada y la corrección de un aviso de seguridad de OpenFGA en la ruta ListUsers. Todo lo anterior a la v1.20.0 carece de esas correcciones; la v1.21.0 se apoya en ellas. La v1.22.0 añade otra entrada Security: una biblioteca gRPC actualizada que resuelve GO-2026-6443. La frase que un MSP puede poner en un ticket es: «la v1.20.0 trajo correcciones de seguridad, entre ellas un aviso de OpenFGA en la ruta ListUsers; ejecutar ≥ v1.21.0, preferiblemente v1.22.0».

Dynamic Conditions exige una redacción precisa. Las notas de la v1.21.0 la presentan como «una nueva función experimental» (traducción nuestra): experimental, no de disponibilidad general. La lógica de derechos de los clientes no debería depender de una función experimental, salvo que el cliente acepte expresamente ese riesgo por escrito.

Las pruebas de versión que un MSP puede adjuntar a un ticket de cambio, tal como aparecen en las versiones v1.21.0 y v1.22.0: ambas están marcadas como inmutables y cada una incluye archivos de sumas de comprobación firmados, una atestación in-toto y un SBOM por archivo binario. Esas pruebas respaldan que el artefacto desplegado coincide con lo que publicó el proyecto y que dispone de una lista de componentes. No son una auditoría del código ni de su modelo de autorización.

La pregunta, escrita una vez y reutilizada: sujeto · acción · objeto · tenant. Un técnico, una cuenta de partner, un usuario del cliente y una integración de máquina son cuatro tipos de sujeto. «Leer», «modificar», «exportar» y «eliminar» son acciones distintas. Un dispositivo, un buzón y un conjunto de copias de seguridad son objetos. Cada objeto pertenece exactamente a un tenant de cliente. Esa pregunta en cuatro partes es la que un evento de inicio de sesión nunca responde por sí solo.

Relaciones en lugar de roles copiados: un tenant contiene sedes u organizaciones; los recursos pertenecen a una sede; un técnico se vincula a una sede mediante una delegación que puede tener un plazo; un administrador del cliente solo se vincula a su propio tenant. El punto de decisión deduce «¿puede este técnico modificar este buzón?» recorriendo esas relaciones.

Por qué ayuda al MSP: el derecho de acceso sale del token y de los miles de comprobaciones if dispersas en el código de las aplicaciones y pasa a ser un único lugar que se puede inspeccionar, probar y registrar. Revocar la delegación de un técnico sobre un cliente es eliminar una relación, no reemitir tokens en cada aplicación. El cambio tiene un responsable y un registro de auditoría en un único almacén.

El marco defensivo: denegar por defecto, mínimo privilegio y una comprobación en cada solicitud (OWASP Authorization Cheat Sheet). El control de acceso roto (broken access control), incluido el acceso a objetos de otro tenant, es la clase de fallo que este patrón pretende reducir. Un cierre de sesión o una señal de revocación puede desencadenar una nueva comprobación; el punto de decisión es donde esa comprobación ocurre. Por eso, además, un cierre de sesión por sí solo no es una revocación a nivel de tenant.

Gatekeeper y Kyverno son políticas de admisión de Kubernetes para objetos de infraestructura. Deciden si un manifiesto puede entrar en un clúster, no si un técnico puede leer el buzón de un cliente. Ninguno sustituye al otro. Un MSP que confunde política de admisión con derechos de aplicación pondrá el control equivocado en la capa equivocada.

OpenZiti es un overlay de red zero trust. Decide qué identidades pueden llegar a qué servicios en la red; no decide los derechos de aplicación objeto por objeto. La accesibilidad de red y el permiso sobre un objeto son puertas distintas.

Trivy, Syft y DefectDojo son escáneres, generadores de SBOM y herramientas de agregación de hallazgos. Describen qué hay en su software y qué falla en él. No autorizan solicitudes.

Este artículo no dice que Auris, ni ningún otro producto de Altovar, use, incorpore o integre OpenFGA. OpenFGA se cita como patrón de referencia de código abierto para la autorización centralizada.

Seis controles defensivos para operar cualquier punto de decisión central, cada uno con lo que cuenta como prueba y lo que no.

Primero, inventario: qué almacenes y modelos de autorización existen, por cliente o compartidos, y quién puede modificarlos. La prueba es una lista exportada y un responsable por modelo. «Usamos ReBAC» no es una prueba. Segundo, fijación de versión: ≥ v1.21.0 registrada en el ticket de cambio, con el resultado de la verificación de sumas de comprobación y atestación adjunto. Un número de estrellas o una etiqueta latest no son prueba.

Tercero, proteger la propia API de decisión: solo llamantes autenticados, accesible solo desde la capa de aplicación, operaciones de administración limitadas a operadores identificados con MFA. Cuarto, los cambios en el modelo son cambios de código: revisados, versionados y probados antes del despliegue con casos explícitos de denegación entre tenants. La prueba es una ejecución de test que muestra que el tenant B no puede llegar al objeto del tenant A. «El modelo compila» no es una prueba.

Quinto, hacer copia de seguridad y restaurar los datos de relaciones; ensayar una restauración. Un punto de decisión que pierde sus relaciones falla abierto o cerrado, y ambos casos son caídas del servicio. Sexto, registrar las decisiones y los cambios del modelo en el SIEM como señales operativas, por ejemplo cambios inesperados en el modelo o picos de denegaciones tras una versión. Por último, mantener las funciones experimentales fuera de las rutas de derechos de los clientes hasta que el proyecto las clasifique de otra manera.

En resumen: Apache-2.0; CNCF Incubating desde el 28 de octubre de 2025; 5920 estrellas en GitHub el 5 de octubre de 2026; versión mínima v1.21.0 (20 de septiembre de 2026), con la v1.22.0 (6 de octubre de 2026) como mejor objetivo; por debajo quedan las correcciones de seguridad de la v1.20.0; Dynamic Conditions es experimental. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft y DefectDojo no sustituyen a un punto de decisión central en la aplicación. El inicio y el cierre de sesión y la validez del token son entradas; el derecho de acceso es una decisión que se toma en cada solicitud.

Este artículo no afirma que Auris use OpenFGA. El patrón es una arquitectura de referencia de código abierto para la pregunta del MSP que la autenticación, por sí sola, nunca responde.