En la mayoría de las organizaciones donde he trabajado, la infraestructura ya es código: los despliegues pasan por pipelines, los cambios se revisan en pull requests y las políticas empiezan a versionarse. Hemos invertido años en conseguir que nadie toque producción a mano.

Sin embargo, los accesos siguen funcionando como hace una década: cuando un usuario necesita entrar a una herramienta, a un grupo o a un entorno, se abre un ticket, alguien valora si tiene sentido, otra persona sabe qué grupo hay que tocar y otra recuerda cómo se hizo la última vez. A veces queda documentado, pero la mayoría de las veces no.

Los accesos se conceden, aunque rara vez queda claro por qué, durante cuánto tiempo, quién lo aprobó, qué permisos reales implica o si seis meses después sigue haciendo falta.

El coste de esto no es teórico, aparece el día que un auditor pregunta quién aprobó el acceso de un usuario a producción y la respuesta tarda dos semanas en reconstruirse a partir de tickets, capturas y conversaciones de Slack. Aparece cuando la única persona que entendía el modelo de grupos se va de la empresa, o cuando descubres decenas de accesos huérfanos que nadie revoca porque ya nadie sabe para qué existían. Y aparece, cada vez más, en forma de identidades de servicio que se multiplican sin que nadie las gobierne.

El problema no surge de golpe, sino que se acumula. Al principio hay pocos usuarios y pocos grupos, pero luego llegan más equipos, más aplicaciones, más entornos, más proveedores cloud, más SaaS, más automatizaciones y más identidades no humanas, hasta que lo que antes se gestionaba «a mano» pasa a depender de conocimiento tribal y de personas concretas.

En el fondo, hemos modernizado cómo desplegamos sistemas, pero no cómo gobernamos quién accede a ellos. Entitlements as Code es el intento de cerrar esa brecha.

1. Qué es un entitlement

Un entitlement es una concesión de acceso. No se trata de «un usuario», «un grupo» o «un rol», sino de la relación que define que una identidad tiene derecho a acceder a algo bajo unas condiciones determinadas.

Son entitlements un usuario que pertenece a un grupo de Entra ID, un equipo con acceso a una aplicación interna, un grupo que puede operar sobre un entorno de desarrollo, una identidad de servicio que consume una API o un rol que habilita ciertas acciones sobre un recurso.

En muchas organizaciones estos accesos existen, pero están dispersos: una parte en el proveedor de identidad, otra en herramientas SaaS, otra en plataformas cloud, otra en documentación y otra más en la cabeza de quien lleva años operando el entorno. Por eso el problema no es que falten accesos, sino que no existe un modelo claro, versionado y gobernado de esos accesos.

2. Dónde se rompe la gestión tradicional

La gestión clásica se apoya en tres pilares: tickets, aprobaciones manuales y cambios aplicados directamente en la plataforma o vía scripts. Funciona bien al principio, pero empieza a romperse al escalar, y lo hace por cinco motivos que conviene mirar de cerca.

El primero es la falta de trazabilidad real, porque un ticket dice que se pidió un acceso, pero no siempre refleja qué cambio técnico se aplicó, qué grupo se modificó, qué permisos implicaba ni si se revocó después.

El segundo es la dependencia de personas clave. En casi todas las empresas hay una o dos personas que «saben cómo va esto» (qué grupo usar, qué nombre tiene sentido, qué excepción se hizo en su día y qué no conviene tocar), lo que en realidad es riesgo operativo disfrazado de eficiencia.

El tercero es la deriva. Igual que ocurre en infraestructura, el estado real de los accesos se desvía poco a poco del esperado, y así se acumulan permisos temporales que nunca caducan, grupos duplicados, accesos de proyectos muertos y excepciones que se sedimentan.

El cuarto es que auditar se convierte en un ejercicio arqueológico. Cuando llega la auditoría (interna o de cumplimiento bajo marcos como ISO 27001, SOX o el ENS), la organización tiene que reconstruir decisiones pasadas a partir de fragmentos, y aunque la respuesta suele existir, está repartida en cinco sitios distintos.

Y el quinto es que, en ese contexto, el autoservicio se vuelve peligroso, porque sin un modelo gobernado dar más autonomía a los equipos equivale a dar más descontrol.

Por todo ello, el reto no es «automatizar accesos», sino construir un modelo de gobierno que permita saber quién tiene acceso a qué, por qué, quién lo aprobó, cómo se aplica y cómo se revisa.

3. Qué propone Entitlements as Code

La idea consiste en aplicar a los accesos los mismos principios que ya damos por sentados en infraestructura moderna: estado deseado declarativo, Git como fuente de verdad, cambios revisados por pull request, aprobaciones explícitas, validaciones automáticas, reconciliación del estado real contra el deseado, historial auditable y separación entre intención, revisión y ejecución.

Así, donde antes alguien modificaba un grupo a mano en Entra ID, ahora el acceso se define en un repositorio; donde el conocimiento vivía en una persona, ahora queda expresado en un modelo; y donde el cambio ocurría directamente en producción, ahora pasa por revisión y deja un historial versionado en lugar de depender de capturas y memoria.

De este modo, Git deja de ser solo un repositorio técnico y se convierte en el motor de gobierno, porque una definición declarativa puede indicar que cierta identidad pertenece a un grupo concreto, con su owner, su justificación, su categoría, su caducidad y la referencia a la petición que lo aprobó.

El modelo se estructura en cinco capas (fuente de verdad, modelo declarativo, flujo de cambio, hub de identidad y reconciliación), que conviene ver una a una.

Fuente de verdad

En un modelo GitOps, el estado deseado vive en Git, de modo que el repositorio contiene usuarios, grupos, memberships, owners y reglas, y cada cambio arrastra su contexto: quién lo propuso, quién lo revisó, cuándo se aprobó y qué se modificó.

La condición es que el repositorio exprese intención de gobierno y no solo configuración, porque «añade este usuario a este grupo» no basta, también interesa saber por qué existe ese acceso, quién lo mantiene y qué ciclo de vida tiene.

Modelo declarativo

En esta capa se define cómo representamos los entitlements. El formato (YAML, JSON o HCL) es secundario, ya que lo importante es que sea comprensible, versionable y validable. Un entitlement bien modelado responde por sí solo a quién recibe el acceso, a qué recurso, con qué nivel de permiso, quién es el owner, cuál es la justificación, si caduca, qué proceso lo aprobó y a qué equipo o dominio pertenece. En definitiva, es la diferencia entre automatizar acciones sueltas y construir una plataforma de gobernanza.

Flujo de cambio

Un cambio de acceso debería parecerse a un cambio de infraestructura, de modo que alguien propone la modificación, se validan formato y reglas de forma automática, las personas responsables revisan, se aprueba por pull request, se aplica de forma automatizada, se reconcilia el estado real contra el deseado y todo queda registrado.

Y bien diseñado, esto no añade fricción sino que la reduce, porque los equipos saben dónde pedir cambios, cómo se revisan y qué pasa después.

Hub de identidad

El proveedor de identidad es donde se materializa el acceso. En muchas organizaciones Entra ID actúa como hub principal (usuarios, grupos, aplicaciones empresariales, service principals, roles y asignaciones), mientras que en otras será Okta o Google Workspace. La clave es que el modelo declarativo no dependa de una interfaz gráfica, porque la plataforma de identidad es donde se aplica el acceso, pero no necesariamente donde se gobierna.

Reconciliación

Es la lógica que compara estado deseado y estado real y aplica los cambios necesarios. Puede implementarse con scripts, pipelines, operadores, controladores o herramientas como Crossplane, según la madurez y el ecosistema de cada organización. El cambio de mentalidad es el fondo del asunto: dejamos de gestionar accesos como acciones puntuales y empezamos a gestionarlos como estado continuo.

4. No es todo o nada: es un camino de madurez

Un error frecuente al presentar modelos declarativos es plantearlos como si desde el día uno todo tuviera que pasar exclusivamente por Git, cuando en la práctica casi ninguna organización puede empezar así.

Y es que hay accesos históricos, grupos legacy, excepciones, urgencias y equipos que aún necesitan tocar la plataforma de identidad directamente, de manera que bloquear todo eso de golpe genera más fricción que valor.

Por eso, en una primera fase, Git actúa como fuente de verdad progresiva: define el estado deseado, pero convive con cambios manuales. Si alguien modifica un grupo directamente en Entra ID, no hace falta revertirlo de forma automática, sino que se detecta como drift, se genera una propuesta de cambio y un humano decide si lo acepta e incorpora a Git o lo revierte porque no debería existir.

Más adelante, en una fase madura (con owners claros, validaciones que funcionan y equipos que confían en el flujo), se avanza hacia enforcement. Entonces Git pasa de ser una referencia a ser la vía oficial de cambio, y los accesos creados fuera del flujo se bloquean, se revierten o se tratan como incumplimientos.

Lo importante es no confundir el destino con el punto de partida, porque el destino es gobernar los accesos de forma declarativa y reconciliada, mientras que el arranque realista pasa por visibilidad, detección de drift, revisión humana y adopción gradual.

Y conviene ser honesto con el esfuerzo: la capa que el usuario ve es ligera, pero detrás hay una capa de plataforma (templates, validaciones, reconciliación) que alguien tiene que construir y mantener. No es un proyecto de un sprint, sino una capacidad que se incuba en un dominio pequeño y luego se extiende, así que conviene presupuestarlo como tal y no venderlo como un interruptor.

5. La parte técnica

A partir de aquí entramos en el detalle de implementación. Si solo te interesa el concepto, puedes saltar directamente a la sección 6.

Arquitectura de referencia

Una implementación posible podría apoyarse en estas piezas: Git como fuente de verdad del estado deseado, YAML como capa sencilla donde se definen usuarios, grupos y memberships, CI/CD para validar cambios antes del merge, branch policies para asignar aprobadores según el tipo de acceso, ArgoCD para sincronizar el repositorio contra un cluster, Crossplane como reconciler, el provider de Entra ID para materializar usuarios, grupos y membresías, Entra ID como hub de identidad, y los servicios consumidores (Azure DevOps, SonarQube, DependencyTrack, Kubernetes, ArgoCD u otros) que consumen esos grupos por SSO o integración de identidad.

El flujo, de principio a fin, quedaría así:

Solicitud
→ edición declarativa en YAML
→ pull request
→ validación CI
→ aprobación
→ merge
→ sincronización GitOps
→ reconciliación
→ Entra ID actualizado
→ servicios consumen los grupos

La herramienta exacta es lo de menos, ya que podría ser Crossplane, Terraform, un operador propio o una combinación distinta. Lo que importa es el patrón: el acceso se declara, se revisa, se valida, se aplica y se audita.

Separar el front del back

Para que esto funcione, no se puede exponer toda la complejidad técnica al usuario, y un patrón útil es partir el repositorio en capas de modo que cada perfil toque solo lo que le corresponde:

Capa	Qué contiene	Quién la toca
Front	YAML simple con usuarios, grupos y miembros	Usuarios o equipos mediante PR
Back	Templates, lógica de renderizado y recursos técnicos	Equipo de plataforma
Output	Recursos generados para el reconciler	Nadie directamente

La capa output es el resultado que la capa back genera a partir del front y que consume el reconciler, así que nadie la edita a mano. La idea es que un usuario no tenga que saber cómo se construye un recurso de Crossplane, cómo se llama a Microsoft Graph o qué campos exactos necesita Entra ID, sino que pueda limitarse a expresar la intención:

groups:
ADO-Platform-Pro-InternalTool-Viewer:
platform: ADO
scope: Pro
project: InternalTool
role: Viewer
members:
– ana-perez
owners:
– platform-team

Después, la capa técnica transforma esa intención en los recursos necesarios, y es precisamente esta separación la que convierte Entitlements as Code en una plataforma y no en un repositorio de YAML incomprensible.

Validaciones antes de aplicar cambios

Si todo cambio pasa por Git, el pipeline de validación se convierte en una pieza crítica de gobierno, y validar no significa solo comprobar que el YAML está bien formado, sino codificar reglas de negocio: que los nombres de grupos sigan la convención, que los roles pertenezcan a un catálogo permitido, que los usuarios referenciados existan, que no haya miembros duplicados, que los grupos sensibles tengan owner, que los grupos de administración exijan aprobaciones adicionales, que no haya ciclos en grupos anidados y que el cambio genere un diff comprensible antes de aplicarse.

Aquí es donde el «as Code» aporta su valor más tangible, porque la gobernanza deja de depender de que alguien recuerde las reglas y pasa a estar codificada en el propio flujo.

Aprobaciones basadas en ownership

No todos los accesos deberían aprobarse igual. Un cambio sobre un grupo de Azure DevOps lo revisa el owner de ese proyecto, un cambio sobre grupos de Kubernetes pasa por plataforma y un grupo de administración exige más controles que uno de solo lectura. Todo esto se modela con aprobadores automáticos según el path modificado:

values/groups/ado-platform.yaml → owner de la organización o proyecto
values/groups/k8s.yaml → equipo de plataforma
values/users.yaml → equipo de identidad o plataforma
grupos *-Admin → doble aprobación

De esta forma, el propio repositorio codifica a quién pedir permiso, en lugar de dejarlo en la memoria de alguien.

Drift detection: convivir con la realidad

En el mundo real, y sobre todo al principio, habrá cambios manuales: alguien tocará un grupo en plena incidencia, alguien añadirá un usuario con urgencia y alguien creará un grupo «temporal» que acabará durando un año. Precisamente por eso la detección de drift es clave.

Un enfoque razonable en fases iniciales es un proceso periódico que compara el estado real de Entra ID con lo declarado en Git y que, ante una diferencia, genera una PR automática con el cambio detectado para que el humano decida:

Merge → aceptamos el cambio manual y lo incorporamos a Git
Close → no lo aceptamos y se revierte (a mano o por enforcement)

Este patrón no niega la realidad operativa, sino que la absorbe y la pone sobre la mesa como una decisión consciente. En entornos más maduros el modelo se endurece (bloqueando cambios fuera de flujo, activando reconciliación correctiva o tratando toda modificación manual como una desviación), pero eso debería ser una decisión de madurez y no una imposición desde el día uno.

Bootstrap: cómo empezar sin partir de cero

¿Cómo se adopta esto en una organización que ya tiene cientos de usuarios, grupos y excepciones en marcha? La respuesta no es empezar de cero, sino partir de lo que ya existe:

1. Discovery. Exportar usuarios, grupos y membresías existentes vía API del proveedor de identidad.
2. Normalización. Convertir ese estado en un modelo declarativo: usuarios, grupos, owners, membresías, legacy y categorías.
3. Validación en modo observación. Desplegar el modelo sin aplicar cambios destructivos, solo comprobando si lo declarado coincide con la realidad.
4. Corrección progresiva. Resolver diferencias, naming inconsistente, duplicados, owners inexistentes y excepciones.
5. Activación gradual. Empezar a gestionar ciertos dominios desde Git, por áreas pequeñas y poco críticas.
6. Evolución hacia enforcement. Cuando el modelo madure, convertir Git en la vía oficial de cambio.

La adopción es deliberadamente incremental: nunca un big bang, sino dominios que se van incorporando uno a uno a medida que el modelo gana confianza.

Interfaces: YAML, CLI, portal e IA

Nadie debería verse obligado a editar YAML. Para los equipos técnicos puede bastar la edición directa, pero un responsable funcional o un equipo poco acostumbrado a Git necesitan otra cosa, así que sobre el mismo modelo se pueden construir interfaces distintas: YAML directo para técnicos, CLI para plataforma, portal web para usuarios finales, formularios para solicitudes frecuentes y asistentes de IA que traduzcan lenguaje natural en propuestas de cambio.

Sea cual sea la interfaz, la regla no cambia: ninguna se salta el gobierno. Da igual que el cambio lo proponga una persona, una CLI, un portal o una IA, porque el resultado siempre es una propuesta que pasa por validación, revisión, aprobación y reconciliación.

Con IA esto resulta especialmente importante, ya que la IA propone, el sistema valida y las personas responsables aprueban. Puede generar la PR, explicar el impacto o guiar al usuario, pero no debería aprobar, mergear ni saltarse un control, porque es una interfaz de productividad y no una autoridad de gobierno.

6. Autoservicio sin perder gobierno

Muchas organizaciones oscilan entre dos extremos igualmente malos. En uno, todo depende de tickets, esperas y personas concretas, lo que produce lentitud, frustración y cuellos de botella; en el otro, se reparte autonomía sin un modelo claro, y aunque se gana velocidad también aparecen más riesgo, más excepciones y menos control.

Entitlements as Code habilita el punto intermedio, porque los equipos piden cambios de forma más sencilla pero esos cambios siguen pasando por un flujo gobernado: los owners aprueban, las reglas se validan, el historial queda registrado y la plataforma reconcilia el estado. Es autoservicio, no barra libre.

7. Qué se gana

El beneficio más inmediato es la trazabilidad auditable, ya que cada cambio queda registrado con autor, revisión, fecha y diff exacto, lo que convierte una auditoría de accesos (y la respuesta a marcos como ISO 27001, SOX o el ENS) en consultar un historial en lugar de reconstruir el pasado.

Detrás viene la resiliencia organizativa, porque el conocimiento deja de vivir en una o dos personas y pasa a estar expresado en un sistema. Si alguien clave se va, las reglas, los owners y las membresías siguen ahí, lo que se traduce a la vez en menos riesgo operativo y menos dependencia.

A medida que crecen equipos, aplicaciones, entornos e identidades de servicio, el modelo escala sin multiplicar tickets manuales y aplica las reglas de forma consistente, dependa de quien dependa el cambio. Ahí está la paradoja útil: automatizar accesos sin gobierno aumenta el riesgo, pero automatizar sobre un modelo declarativo, revisado y auditable lo reduce, que es justamente la diferencia entre ir rápido y descontrolarse.

8. Por qué puede convertirse en un estándar

Infrastructure as Code cambió cómo gestionamos infraestructura, Policy as Code cambió cómo validamos reglas y GitOps cambió cómo reconciliamos estado deseado y estado real, de modo que la gestión de accesos necesita una evolución del mismo orden.

El argumento de fondo es de escala. A medida que las organizaciones adoptan cloud, SaaS, plataformas internas, Kubernetes, identidades de servicio, automatización e IA, el número de identidades y permisos crece de forma exponencial (y las identidades no humanas, que ya superan a las humanas en muchos entornos, son la parte que más rápido se descontrola), así que gestionar todo eso a mano sencillamente no escala.

Entitlements as Code lleva la gobernanza de accesos al nivel de madurez que ya exigimos a la infraestructura, los despliegues y las políticas. No implica que todo acceso se gestione igual, ni que Git sea la única interfaz, ni que desaparezcan las herramientas de Identity Governance, sino que propone un modelo más declarativo, versionado, automatizable y auditable para definir quién accede a qué, por qué, bajo qué condiciones y durante cuánto tiempo.

9. Conclusión

Los accesos son una de las últimas grandes áreas que seguimos gestionando con procesos manuales, conocimiento tribal y controles que no escalan. Frente a eso, Entitlements as Code propone tratarlos como estado deseado: expresarlos de forma declarativa, revisarlos como código y reconciliarlos contra la realidad según la madurez de cada organización, de manera que en fases iniciales eso signifique visibilidad, detección de drift y revisión humana, y en fases maduras enforcement, automatización avanzada y gobierno continuo.

Es un término todavía poco extendido, pero la necesidad que resuelve es cada vez más evidente. Si la infraestructura ya es código, si las políticas ya son código y si los despliegues ya se gobiernan con flujos versionados, el siguiente paso lógico es aplicar esa misma mentalidad a quién puede acceder a qué.