Autorización Descentralizada: Sidecars, Edge y Multi-Cloud

La pregunta que el artículo de XACML dejó abierta

Hace tres artículos, describiendo dónde puede vivir un PDP, escribimos que puede ser “una biblioteca compilada en la aplicación, un sidecar corriendo junto a cada servicio, o un servicio central que cada app llama por la red… una elección con consecuencias reales para la latencia, la frescura y el radio de impacto que el artículo de autorización descentralizada desarrolla en profundidad.” Este es ese artículo. Todo lo cubierto hasta ahora en este módulo — los componentes de XACML, los lenguajes de políticas como código, los grafos de relaciones de Zanzibar, el espectro de granularidad — ha tratado “dónde corre realmente la decisión” como un detalle a completar más adelante. Es hora de completarlo.

La versión corta de por qué esto es un tema propio y no una nota al pie: la ubicación no es solo una elección de infraestructura, cambia lo que el motor de decisión puede prometer. Un PDP a un salto de red puede ser más consistente pero es un único punto de fallo y latencia añadida en cada solicitud. Un PDP corriendo localmente en un sidecar es rápido y resiliente a particiones de red pero ahora existe en cientos de copias que todas necesitan la misma política. Un PDP corriendo en un borde de CDN, potencialmente a miles de kilómetros de tu base de datos, físicamente no puede ver datos que solo viven en tu región de origen. Ninguno de estos es un bug a eliminar mediante ingeniería — son la forma real del compromiso, y una arquitectura de autorización de producción tiene que elegir deliberadamente entre ellos, a menudo usando más de uno a la vez.

El resto de este artículo recorre ese boceto capa por capa: primero el patrón sidecar, luego el edge, después la capa de portabilidad WASM que permite que la misma política corra en ambos, y por último cómo se distribuyen realmente la política y los datos a cada una de esas copias.

El patrón sidecar

La forma más común de descentralizar un PDP hoy es el sidecar: un segundo proceso desplegado junto a cada instancia de tu aplicación — en Kubernetes, un segundo contenedor en el mismo pod — al que tu aplicación (o, más a menudo, un proxy delante de ella) llama por localhost en lugar de por la red hacia otro servicio.

La forma concreta dominante es Envoy + OPA. Envoy, el proxy sobre el que están construidas la mayoría de las mallas de servicios, tiene un filtro ext_authz que intercepta cada solicitud y pide una decisión a un autorizador externo antes de dejarla pasar hacia la aplicación. Apunta ese filtro a una instancia local de OPA (el opa-envoy-plugin empaqueta OPA específicamente para hablar el protocolo gRPC ext_authz de Envoy) y obtienes autorización aplicada de forma transparente, delante de cada servicio, sin que el código de la aplicación llame nunca directamente a una biblioteca de autorización — el PEP vive en el proxy, no en la app.

sequenceDiagram
  accTitle: Un flujo de autorización sidecar usando el filtro ext_authz de Envoy y una instancia local de OPA
  accDescr: El diagrama muestra una solicitud llegando a Envoy, el proxy que corre como contenedor sidecar en el mismo pod que la aplicación. Envoy llama al filtro ext_authz, que envía la solicitud a un segundo contenedor sidecar en el mismo pod que ejecuta OPA, por localhost, sin ningún salto de red saliendo del pod. OPA evalúa la solicitud contra la política ya cargada en su memoria local y devuelve una decisión de permitir o denegar a Envoy en microsegundos. Si se permite, Envoy reenvía la solicitud original al contenedor de la aplicación en el mismo pod. Si se deniega, Envoy devuelve un error al llamador sin que la aplicación llegue a ver la solicitud.
  Client->>Envoy: solicitud entrante
  Envoy->>OPA: comprobación ext_authz (localhost)
  OPA->>OPA: evalúa política (en memoria)
  OPA-->>Envoy: permite / deniega
  Envoy->>App: reenvía (si se permite)
  Envoy-->>Client: rechaza (si se deniega)

Esto vuelve concreta exactamente la pregunta de ubicación “biblioteca vs sidecar vs servicio central”: un sidecar conserva casi todo el beneficio de latencia de la ubicación de biblioteca (sin salto de red real, solo una llamada a localhost) mientras mantiene la política fuera del propio proceso y lenguaje de la aplicación — no necesitas un SDK cliente de OPA en cada lenguaje en el que resulten estar escritos tus servicios, necesitas Envoy delante de cada uno, lo cual normalmente ya es cierto si estás corriendo una malla de servicios.

Políticas de autorización de la malla de servicios

Istio y Linkerd, las dos mallas de servicios dominantes, integran la autorización directamente en el plano de control de la malla en lugar de exigir que cada equipo conecte ext_authz a mano. El recurso personalizado AuthorizationPolicy de Istio permite a los equipos de plataforma declarar reglas gruesas, de capa perímetro y módulo — qué servicios pueden llamar a qué otros servicios, sobre qué rutas y métodos — aplicadas por los mismos sidecars de Envoy que la malla ya inyecta para mTLS y gestión de tráfico. Esto es deliberadamente el extremo grueso del espectro de granularidad: decisiones de servicio a servicio y con forma de rol, no por recurso. Una AuthorizationPolicy de malla respondiendo “¿puede el servicio de facturación siquiera llamar al endpoint /write del servicio de libro mayor?” y un sidecar de OPA respondiendo “¿puede esta solicitud específica escribir en esta entrada específica del libro mayor?” son dos capas de granularidad distintas, ambas descentralizadas, ambas corriendo en la misma infraestructura sidecar — el propio motor de política de la malla típicamente maneja la capa gruesa, con OPA (o un equivalente) conectado vía ext_authz para lo que necesite ir más fino.

Autorización en el edge

Lleva la idea del sidecar un paso más allá, pasando por completo el límite de tu propia infraestructura, y obtienes la autorización en el edge: correr una decisión dentro del propio entorno de manejo de solicitudes de una CDN — Cloudflare Workers, AWS CloudFront Functions o Lambda@Edge, Fastly Compute — antes de que la solicitud haya viajado más allá del punto de presencia más cercano al usuario.

El atractivo es una latencia a una escala que los sidecars no pueden tocar: un usuario en Singapur que llega a una ubicación de edge en Singapur obtiene una decisión de rechazo en milisegundos de un solo dígito, sin que su solicitud llegue a cruzar un océano para alcanzar tu región de origen en absoluto, para tráfico que nunca iba a ser permitido de todas formas (un token expirado, una solicitud mal formada, un rango de IP bloqueado). Esto importa desproporcionadamente para la capa de perímetro del espectro de granularidad — precisamente la capa que se supone debe rechazar de forma barata y rápida, y no hay lugar más rápido para rechazar que antes de que la solicitud siquiera haya salido del continente del usuario.

Los límites son igual de reales, y son estructurales, no una brecha de madurez que se cerrará con el tiempo. Los entornos de edge están deliberadamente limitados: presupuestos de tiempo de CPU cortos (están facturados y programados para miles de invocaciones pequeñas y baratas, no una costosa), acceso limitado o nulo directo a tus bases de datos internas, y ninguna forma razonable de mantener una copia activa y sincronizada de un gran grafo de relaciones. Un worker de edge puede verificar la firma de un JWT y comprobar sus claims — eso es una operación autocontenida, rápida, de capa perímetro. En general no puede ejecutar un Check al estilo Zanzibar que necesite recorrer un grafo de relaciones que vive en la base de datos de tu región de origen; la ida y vuelta para obtener esos datos borraría la ventaja de latencia que hizo que correr en el edge valiera la pena en primer lugar.

WASM: la capa de portabilidad debajo de todo esto

Un sidecar, un worker de edge y un proceso de aplicación que embebe una biblioteca de política son tres entornos casi sin nada en común — distintos lenguajes, distintas restricciones de CPU y memoria, distintos mecanismos de despliegue. Lo que permite que la misma política corra correctamente en los tres sin ser reescrita tres veces es WebAssembly (WASM): un formato de bytecode portable y aislado que cada uno de estos entornos puede ejecutar.

OPA compila una política de Rego en un módulo .wasm (opa build -t wasm), y ese artefacto único es lo que se carga en el proceso de OPA de un sidecar, se embebe directamente en una aplicación a través de los SDKs WASM de OPA (Go, JavaScript, y otros), o corre dentro de un worker de edge — Cloudflare Workers, en particular, tiene soporte de WASM de primera clase específicamente porque su entorno ya necesitaba un modelo de ejecución rápido y aislado para código no confiable y medido por CPU, y una política compilada encaja de forma natural en esa forma. Cedar se ha movido en la misma dirección, con su propia implementación de referencia diseñada para ser embebible, y la tendencia más amplia en cada motor de este módulo es la misma: compila la política una vez, corre el artefacto compilado en cualquier lugar, en lugar de enviar un entorno de ejecución de lenguaje completo (un intérprete de Rego, por ejemplo) a cada entorno que necesite una decisión.

Esto importa para la descentralización específicamente porque convierte “correr política en el edge” de “portar tu motor de política a un nuevo entorno restringido” en “cargar el mismo artefacto que ya construyes para tus sidecars en un host WASM que la CDN ya provee” — la portabilidad es lo que hace que la autorización en el edge más allá de comprobaciones de token escritas a mano sea siquiera práctica.

Distribución de política: mantenerse consistente sin un decisor central

Cada patrón de este artículo comparte un problema que el callout del sidecar nombró arriba: si ningún proceso único toma cada decisión, ¿cómo se ponen de acuerdo potencialmente miles de decisores independientes — sidecars a lo largo de una flota, workers de edge en decenas de puntos de presencia — sobre cuál es la política actual?

La respuesta a la que convergen las arquitecturas descentralizadas es separar la autoría de la evaluación, que en realidad es la separación PAP-de-PDP que estableció el artículo de XACML, ahora estirada a través de un número mucho mayor de copias del PDP. Un Punto de Administración de Política sigue siendo la única fuente de verdad — el lugar donde la política se escribe, se revisa, se prueba y se versiona — pero en lugar de que cada decisión lo llame en vivo, publica paquetes inmutables y versionados, y cada sidecar y worker de edge extrae independientemente (sondeando en un intervalo) o recibe (vía push, para un despliegue de menor latencia) el último paquete y evalúa por completo contra su copia local.

flowchart LR
  accTitle: Distribución de paquetes de política desde un PAP central hacia una flota descentralizada de sidecars y workers de edge
  accDescr: El diagrama muestra a un autor de política haciendo un commit de un cambio, que pasa por CI y es publicado por el punto de administración de política como un nuevo paquete firmado hacia un registro de paquetes. Desde el registro, dos grupos separados extraen el paquete de forma independiente y asíncrona, fuera de la ruta de la solicitud. El primer grupo es una flota de sidecars, cada uno sondeando el registro en su propio intervalo y cargando el nuevo paquete en memoria local. El segundo grupo es un conjunto de workers de edge en distintos puntos de presencia, cada uno también extrayendo y cargando el paquete de forma independiente. Una nota indica que la evaluación en el momento de la solicitud en cada sidecar y worker de edge usa únicamente el paquete cargado en local, sin llamar nunca en vivo al registro ni al punto de administración de política.
  Author[Autor de política] --> CI[CI: prueba y firma]
  CI --> PAP[PAP publica paquete]
  PAP --> Registry[(Registro de paquetes)]
  Registry -.extrae.-> S1[Flota de sidecars<br/>sondea por intervalo]
  Registry -.extrae.-> S2[Workers de edge<br/>sondea por intervalo]
  S1 --> Local1[paquete local,<br/>evaluado sin conexión]
  S2 --> Local2[paquete local,<br/>evaluado sin conexión]

Este es un intercambio deliberado: la evaluación en el momento de la solicitud ya no depende de que el registro o el PAP sean alcanzables en absoluto — un sidecar o worker de edge con un paquete cargado localmente sigue tomando decisiones correctas contra esa versión de la política incluso durante una partición de red, lo cual es una ganancia real de resiliencia. Lo que se sacrifica es la consistencia instantánea: ahora existe una ventana de propagación inevitable entre “la política cambió en el PAP” y “cada decisor de la flota la está usando,” acotada por el intervalo de cada sondeo (o la latencia del push), durante la cual distintos decisores pueden estar correcta y simultáneamente evaluando dos versiones distintas de la política. Los registros de decisión — cada sidecar y worker de edge enviando sus decisiones individuales de vuelta a un almacén de registros central aunque la decisión misma se tomara en local — son cómo la mayoría de los despliegues recuperan la visibilidad de un único lugar para auditar que un PDP central daría de forma gratuita: la decisión está descentralizada, pero el rastro de auditoría deliberadamente no lo está.

Multi-región y multi-nube: cuando los datos tampoco están en un solo lugar

La distribución de paquetes resuelve la consistencia de la política — las reglas. No resuelve la consistencia de los datos contra los que evalúan esas reglas, y ese problema se vuelve marcadamente más difícil una vez que los propios datos de relaciones o atributos se replican entre regiones o nubes en lugar de vivir en una sola base de datos.

Revisita el problema del nuevo enemigo del artículo de autorización de grano fino con esta lente. Un despliegue al estilo Zanzibar en una sola región puede fijar un Check a un zookie porque la escritura que revocó el acceso y el check que lee esos datos comparten, de forma realista, un único almacén consistente. Una vez que esos datos de relaciones se replican, digamos, entre una región de EE. UU. y una región de la UE — por latencia (servir a usuarios de la UE desde infraestructura de la UE) o por requisitos de residencia de datos (obligaciones impulsadas por el GDPR de mantener los datos personales de la UE, que las tuplas de relaciones sobre usuarios de la UE típicamente son, dentro de la UE) — una revocación escrita en una región tiene que propagarse físicamente hacia la otra antes de que una comprobación servida allí pueda verla. Esa propagación tiene un piso fijado por la velocidad de la luz y la topología de red, no por mejor software, y ninguna cantidad de ingeniería la hace instantánea.

sequenceDiagram
  accTitle: El problema del nuevo enemigo entre regiones, donde la revocación debe propagarse físicamente por un enlace más largo
  accDescr: El diagrama muestra a un administrador revocando el acceso de Sara en el almacén de datos de la región de la UE en el momento T. Ese cambio comienza a replicarse hacia el almacén de datos de la región de EE. UU. a través de un enlace entre regiones, lo cual toma un tiempo medible acotado por la topología de red. Poco después del momento T, una comprobación del acceso de Sara llega a la región de EE. UU., que está más cerca del solicitante, y lee de la réplica de la región de EE. UU. Como la revocación de la UE aún no ha llegado por el enlace entre regiones, la réplica de EE. UU. todavía muestra a Sara con acceso, y la comprobación incorrectamente devuelve Permitir, ilustrando que el problema del nuevo enemigo persiste entre regiones con un retraso de propagación fijado por la distancia física en lugar del retraso de replicación dentro del mismo centro de datos.
  Admin->>EU_DB: revoca el acceso de Sara (T)
  EU_DB-->>US_DB: replicación en tránsito
  Client->>US_Engine: Check(sara, viewer, doc)
  US_Engine->>US_DB: lee réplica local
  US_DB-->>US_Engine: aún con acceso (obsoleto)
  US_Engine-->>Client: Permite (incorrecto)

No hay ningún truco de ingeniería que haga desaparecer este compromiso — solo una elección deliberada, hecha por región y por clase de decisión, sobre qué lado de él aceptas. Tres opciones reales: pagar la latencia de escritura entre regiones en cada cambio sensible exigiendo que las revocaciones sean confirmadas en cada región antes de que la solicitud iniciadora se complete (consistencia más fuerte, peor latencia de escritura); aceptar una ventana de obsolescencia acotada y documentarla como un SLA explícito (la elección al estilo at_least_as_fresh versus minimize_latency de SpiceDB del artículo de autorización de grano fino, ahora hecha por región en lugar de por solicitud); o particionar los datos para que las relaciones sensibles nunca necesiten lecturas entre regiones en absoluto — el acceso de un usuario de la UE a recursos alojados en la UE se decide por completo dentro de la región de la UE, y el caso entre regiones simplemente no surge para esa clase de datos. La mayoría de los despliegues multi-región reales usan una mezcla de la tercera y la segunda opción: particionar lo que se pueda particionar, y aceptar una ventana de obsolescencia pequeña, monitoreada y explícitamente documentada para el resto.

Ejemplo trabajado: una app de cashback, desplegada globalmente

La empresa de cashback de artículos anteriores se expande a la UE y necesita decidir, de forma concreta, dónde corre cada una de sus decisiones de autorización. Las comprobaciones de perímetro — ¿es válido en absoluto el token de esta solicitud? — corren en el edge, globalmente, en Cloudflare Workers compilados desde el mismo paquete WASM de OPA que la empresa ya construye para sus sidecars; un token inválido o expirado se rechaza en el punto de presencia más cercano al usuario, en milisegundos, sin llegar nunca a ninguna región de origen. Las comprobaciones de capa módulo — ¿el rol de este usuario permite siquiera abrir la funcionalidad del panel de comerciante? — corren en reglas AuthorizationPolicy de Istio aplicadas por los propios sidecars de Envoy de la malla, con forma de servicio a servicio y de rol, descentralizadas en cada pod de ambas regiones de forma idéntica porque la propia configuración de la malla se distribuye por paquetes de la misma forma que la política de OPA. Las comprobaciones de capa recurso — ¿puede este comerciante específico editar este registro de transacción específico? — corren en un sidecar de OPA por servicio, evaluando contra datos de atributos replicados por región, con los datos de comerciantes de la UE particionados para quedarse enteramente dentro de la región de la UE de modo que nunca se necesite una lectura entre regiones para esta clase de decisión. Las comprobaciones de capa relación — ¿puede el compañero de equipo de un comerciante ver un informe de cashback compartido con su equipo? — corren contra un despliegue de OpenFGA consciente de la región: las tuplas de relaciones de los equipos de la UE viven en el almacén de la región de la UE, las de los equipos de EE. UU. en el almacén de EE. UU., y el raro caso de compartición entre regiones (una cuenta de administrador global, por ejemplo) acepta explícitamente el costo de latencia de at_least_as_fresh en lugar del de fully_consistent, documentado como una excepción conocida y acotada en lugar de una brecha silenciosa.

Cuatro capas de granularidad del artículo anterior, ahora cada una ubicada deliberadamente en la capa de topología que le corresponde — edge para perímetro, sidecars de malla para módulo, sidecars locales al servicio para recurso, un almacén de relaciones consciente de la región para relación — que es exactamente el punto hacia el que ha estado construyendo este artículo: la granularidad y la ubicación son dos decisiones separadas, y una arquitectura de autorización madura toma ambas, para cada funcionalidad, en lugar de asumir que una sola ubicación sirve a todas las capas.

Probar y operar un despliegue descentralizado

Probar un sistema de autorización descentralizado necesita una comprobación que la historia de pruebas de PDP único de los artículos anteriores no tenía: verificación de despliegue de paquetes — desplegar un nuevo paquete de política a una porción canaria de sidecars o ubicaciones de edge primero, confirmar que las decisiones cumplen las expectativas ahí, antes de que llegue a toda la flota, precisamente porque un paquete de política defectuoso empujado a todas partes simultáneamente no tiene ningún punto único donde podrías haberlo detectado antes de que surtiera efecto ampliamente. La mayoría de los despliegues de OPA combinan esto con registro de decisiones enviado de forma centralizada desde cada sidecar y worker de edge, que es cómo una flota descentralizada recupera la propiedad de un único lugar para auditar que un PDP central tiene por defecto.

Operativamente, la métrica que vale la pena vigilar es la obsolescencia del paquete: qué tan atrás de la última versión publicada está corriendo realmente, en este momento, cada sidecar y worker de edge de la flota — porque esa brecha es exactamente la ventana de propagación durante la cual distintos decisores pueden estar correcta y simultáneamente evaluando versiones distintas de política. Una flota donde esa brecha es consistentemente pequeña y monitoreada es un sistema descentralizado comportándose como fue diseñado; una flota donde crece en silencio (un sondeo atascado, un mecanismo de push fallando para una región de CDN) es un sistema descentralizado desincronizándose en silencio consigo mismo, que es el modo de fallo específico que todo este patrón de arquitectura necesita vigilar y que un único PDP central nunca tuvo que enfrentar.

Recapitulación

La ubicación es la capa por encima de toda otra decisión de autorización de este módulo:

1. La ubicación del PDP cambia lo que puede prometer, no solo qué tan rápido responde — biblioteca, sidecar, servicio central, edge y multi-región cada uno intercambia latencia, consistencia y radio de impacto de forma distinta.
2. Los sidecars descentralizan la evaluación hacia cada instancia de servicio, típicamente vía el ext_authz de Envoy llamando a un OPA local, conservando la mayor parte del beneficio de latencia de una biblioteca sin acoplar la política al código de la aplicación — a costa de un problema de distribución de política entre cada copia.
3. La autorización en el edge empuja la capa de perímetro tan cerca del usuario como sea físicamente posible, pero está estructuralmente limitada a lo que un entorno restringido y pobre en datos puede decidir — es un filtro delante de tu verdadera pila de autorización, no un reemplazo de ella.
4. WASM es la capa de portabilidad que permite que un único artefacto de política compilado corra en un sidecar, un worker de edge y una biblioteca embebida sin ser reescrito por entorno.
5. La distribución de política resuelve la consistencia de las reglas mediante paquetes versionados, intercambiando propagación instantánea por disponibilidad — la misma separación PAP/PDP del artículo de XACML, ahora estirada a través de miles de copias del PDP.
6. Multi-región y multi-nube vuelven estructural el problema del nuevo enemigo, acotado por el retraso de propagación física en lugar de por la calidad del software — resuelto mediante una política de consistencia deliberada y documentada por región, no eliminado con ingeniería.

Tres preguntas para ponerte a prueba

1. Explica por qué el perfil de latencia de un sidecar es cercano al de una biblioteca aunque involucre un segundo proceso — ¿qué específicamente hace diferente a una llamada localhost a un sidecar ext_authz de una llamada a un servicio de PDP central por la red?
2. Un equipo quiere correr su Check completo de grafo de relaciones al estilo Zanzibar directamente dentro de un worker de edge de una CDN, para obtener la menor latencia posible. Explica, usando las restricciones de este artículo sobre los entornos de edge, por qué esto generalmente no funciona y qué debería correr en el edge en su lugar.
3. Describe, con tus propias palabras, por qué la distribución de paquetes de política es en realidad la misma separación PAP/PDP del artículo de XACML en lugar de una idea nueva — y explica qué se sacrifica específicamente (comparado con un único PDP central) para ganar la resiliencia de una flota descentralizada.

Ejercicios prácticos

1. Diseña un despliegue sidecar. Para un servicio que conozcas (o uno hipotético), esboza cómo sería un despliegue sidecar de Envoy + OPA: qué comprueba la llamada ext_authz, qué política necesita cargada la instancia local de OPA, y qué pasa con una solicitud si el propio sidecar no está disponible momentáneamente.
2. Clasifica una ruta de solicitud por topología. Toma una acción de cara al usuario en una aplicación que conozcas (hacer un pedido, ver un panel, editar un documento compartido) y, usando las cuatro capas de topología de este artículo (edge, sidecar de malla, sidecar de servicio, almacén de datos consciente de la región), asigna cada decisión de autorización en la ruta de esa solicitud a la capa donde realmente debería correr, y justifica cada elección.
3. Diseña una política de consistencia para un caso entre regiones. Elige una decisión de autorización sensible que plausiblemente necesitara funcionar correctamente entre dos regiones (una cuenta revocada, un rol de administrador entre regiones). Elige una de las tres opciones que describe este artículo (pagar la latencia de escritura entre regiones, aceptar y documentar una ventana de obsolescencia acotada, o particionar los datos para evitar por completo el caso entre regiones) y justifica la elección frente a la sensibilidad real de la decisión.