Gobernanza IT: quién entra, quién puede desplegar y cómo se demuestra
Una pregunta de control para cualquier empresa con equipo técnico propio: si mañana se marcha alguien, ¿cuántos sitios distintos hay que tocar para dejarle sin acceso? Si la respuesta es «habría que mirarlo», todavía no tienes un problema de seguridad. Tienes un problema de gobernanza, que es el que lo produce.
La escena es reconocible. Cada servicio con su login propio: el repositorio, el panel de la nube, el gestor de incidencias, la base de datos de staging que alguien abrió «solo un rato». Los permisos se piden por WhatsApp y se conceden por confianza. El acceso a producción lo conserva quien lo pidió alguna vez, incluido el becario que entró en verano y sigue en el grupo. Y cuando algo se rompe, «¿quién cambió esto y cuándo?» se contesta reconstruyendo la memoria de tres personas.
Nada de eso se arregla con un comité ni con un documento de políticas que nadie lee.
Dónde duele, en dinero
El coste no aparece en una factura, aparece en cuatro sitios.
Las altas y bajas. Incorporar a alguien son seis correos y dos días de espera; darle de baja es una lista que nadie mantiene. El día que hay una salida conflictiva, la empresa descubre en cuántos servicios seguía dentro.
La auditoría. Llega un cliente grande, o una certificación, y pide algo muy concreto: la lista de quién tiene acceso a los datos de producción y la evidencia de que ese acceso está controlado. Si esa lista hay que fabricarla a mano, la respuesta llega tarde y con agujeros. Y ahí es donde se encallan operaciones comerciales que ya estaban cerradas.
La rotación. Cuando el conocimiento de quién puede hacer qué vive en la cabeza de la persona que montó el sistema, su marcha no se lleva un empleado: se lleva el mapa.
Los incidentes. Sin trazabilidad no hay causa raíz, solo hipótesis. Y un incidente que no se explica se repite.
Gobernanza IT no es un comité ni un documento. Son tres cosas concretas: identidad centralizada, permisos que se derivan de un único sitio y un camino a producción que nadie puede saltarse.
Tres capas, no diez políticas
Una identidad, un login
Las personas existen en un solo sitio y los servicios delegan en él. El alta y la baja se hacen una vez.
Permisos que se derivan, no que se copian
El rol se declara donde vive la identidad y viaja en el token. La aplicación lo lee y decide, sin lista paralela.
Un solo camino a producción
El repositorio es la verdad y lo que se toca a mano se revierte solo. Un cambio en producción es un commit con autor.
La identidad primero, porque todo lo demás cuelga de ella
En Zetesis empezamos siempre por aquí, y no por gusto arquitectónico: mientras cada servicio tenga su propio registro de usuarios, cualquier política de acceso es una promesa.
La pieza es Keycloak hablando OIDC. Un único emisor de identidad, y las aplicaciones como consumidoras. Nosotros operamos el nuestro como servicio independiente, con su propia imagen, su chart de Helm y su ciclo de releases: Keycloak publicado en un único dominio, del que cuelgan las aplicaciones de la plataforma. Esas aplicaciones no saben nada de contraseñas; hablan OIDC con flujo de código de autorización y PKCE, y el intercambio de tokens ni sale del clúster.
Lo relevante para gobernanza no es el producto, es que el realm está declarado como código. La configuración —clientes, roles, organizaciones, políticas— son 2.200 líneas de JSON en un repositorio, aplicadas por keycloak-config-cli en cada sincronización, con importación no destructiva para que un despliegue no borre lo que no está declarado. Cambiar quién puede hacer qué deja de ser cinco clics en una consola de administración que nadie recuerda haber dado.
Y de ahí sale la parte que más cuesta explicar y más se nota: los permisos se derivan, no se replican. En nuestra plataforma hay cuatro roles con significado de negocio en el lado de la identidad —administración global, administración de organización y dos capacidades de producto—. Cuando alguien inicia sesión, la aplicación lee esos roles y su pertenencia a organizaciones directamente del token y los traduce a permisos internos por cliente. La traducción ocurre en cada inicio de sesión, así que la identidad manda y la aplicación obedece; no hay dos listas de permisos que alguien tenga que cuadrar a mano.
Eso tiene una consecuencia práctica que suele convencer más que la teoría. Los tokens de API que un usuario se crea para integraciones se guardan solo como hash SHA-256 —el valor en claro se muestra una vez y no se persiste—, están atados a un cliente concreto y son inmutables tras crearse. Y en cada petición se vuelve a comprobar que la persona detrás del token sigue teniendo el rol necesario. Si se le retira el permiso en la identidad, el token deja de valer al instante aunque siga existiendo. Revocar en un sitio revoca de verdad.
El cambio se gobierna en el repositorio
La segunda pregunta incómoda es quién puede desplegar qué. La respuesta habitual —«los que tienen las credenciales»— no es una respuesta.
Nuestra infraestructura vive declarada en un repositorio GitOps: tres clústeres de Kubernetes sobre Talos, con ArgoCD reconciliando lo declarado contra lo que corre —el montaje entero está contado en el post de Kubernetes y GitOps del homelab—. La disciplina está en dos detalles poco vistosos. El primero: el 100 % de las aplicaciones tiene reconciliación automática con selfHeal y prune, sin una sola excepción. Si alguien entra por la puerta de atrás y cambia algo con kubectl, ArgoCD lo deshace. No hay atajo a producción; hay una única puerta.
El segundo: el proyecto por defecto de ArgoCD está deliberadamente inutilizado —sin repositorios de origen, sin destinos y con todos los recursos en lista negra—, y el control de acceso arranca sin permisos por defecto. Cada aplicación tiene que declarar un proyecto hecho a medida con sus repositorios y namespaces permitidos. Es lo contrario del patrón habitual, donde todo cabe en «default» y nadie sabe qué puede tocar qué.
Con eso, un despliegue a producción es un cambio de una línea, con autor, fecha y motivo:
$ git log --oneline -2 -- px-platon/alejandro/envs/prod/env.json
ec688cc Merge pull request #239 from Zetesis-Labs/auto-bump/zetesis-portal-30641883917
c562212 chore(prod): bump ZetesisPortal images and chart
$ git show c562212 -- px-platon/alejandro/envs/prod/env.json
- "webImageTag": "v0.8.23",
+ "webImageTag": "v0.8.24",
Ese commit lo escribe un bot: cuando se publica una versión, el pipeline abre un pull request en el repositorio de infraestructura con la nueva etiqueta de imagen. Lo mergea una persona. Así, la promoción a producción queda separada del desarrollo, es revisable antes de ocurrir y auditable después.
CI/CD como forma de gobernar equipos
La tercera capa es la que convierte todo lo anterior en algo que un equipo de desarrollo puede usar sin fricción.
Nadie necesita producción para probar. Cada pull request etiquetado levanta su propio entorno completo: namespace aislado, base de datos propia, dominio propio y hasta su propia instancia de identidad. Al cerrar el PR se destruye solo, y hay tareas periódicas que barren lo que sobrevive —bases de datos huérfanas, imágenes viejas del registro—. Cuando probar es gratis, el acceso a producción deja de ser una necesidad diaria y pasa a ser una excepción.
Los secretos nunca tocan el repositorio. Hay una única fuente —un gestor de secretos autoalojado— y el operador de External Secrets los materializa en cada entorno; el chart de Helm ni siquiera renderiza si no se le indica de qué secreto leer. Cifrado en git solo lo imprescindible para arrancar el clúster antes de que exista ese operador. Y un escáner de secretos corre en cada push y cada pull request, con el historial completo. Las tres capas y cómo encajan están desglosadas en el post de seguridad y operaciones del homelab.
Las reglas las verifica una máquina, no una reunión. La validación de CI renderiza todos los manifiestos y los valida contra esquema, y además comprueba tres políticas escritas como código ejecutable: prohibido usar comodines en las versiones de los charts, obligatorio fallar si falta una variable en una plantilla, prohibido usar el proyecto por defecto de ArgoCD. Una política que no se puede verificar automáticamente no es una política: es una intención.
Por qué el análisis va antes que la herramienta
Un aviso, porque es el error más caro que vemos.
Hace poco Singular Solving trabajaba con un grupo educativo que quería construir sus sistemas siguiendo un marco de referencia sectorial reconocido, y nosotros hicimos ese análisis. Al analizarlo a fondo apareció lo interesante: ese marco describe cientos de capacidades de negocio y de aplicación, y nombra la identidad digital entre ellas, pero es puramente descriptivo. No dice nada de cómo resolverla. El centro tenía correo en un proveedor, plataforma de aula en otro, comunicaciones en un tercero, cada uno con su usuario y su contraseña. El problema no era la falta de aplicaciones: era la fragmentación. Y ningún catálogo de capacidades te dice quién debe acceder a qué.
Conviene decirlo con precisión: allí un servidor de identidad con Keycloak fue alcance propuesto, no una implantación que hayamos ejecutado. Lo que se entregó fue el análisis.
Por eso nuestro trabajo empieza con un inventario de accesos reales, no con la instalación de nada. Quién entra, dónde, con qué permiso y quién se lo concedió. La herramienta viene después, cuando ya sabes qué estás gobernando.
Para quién encaja
Encaja si tus sistemas internos los usan decenas de personas y el alta de un empleado nuevo sigue siendo una lista de tareas manuales. Si un cliente o una certificación te ha pedido evidencia de control de accesos y la has fabricado a mano. Si más de una persona puede desplegar a producción y no queda registro de quién lo hizo. Si has heredado una plataforma y no sabes quién tiene acceso a qué.
No encaja si tu equipo cabe en tres personas que se sientan juntas: la gobernanza que necesitas ahí es una hoja de cálculo honesta, no un servidor de identidad. Tampoco si buscas el certificado sin cambiar cómo trabajas —podemos ayudarte a documentar lo que hay, pero no a que parezca otra cosa—. Y tampoco si esperas externalizar la operación para siempre: montamos el sistema para que lo lleve tu equipo.
Si lo que te duele no es quién despliega sino que desplegar dé miedo —pipelines lentos, backups sin probar, secretos en una hoja de cálculo—, eso es el otro servicio: consultoría DevOps e infraestructura. Son hermanos y a menudo se contratan juntos, pero responden preguntas distintas.
Preguntas que nos hacen siempre
¿Esto no es simplemente montar un Keycloak?
Keycloak se instala en una tarde; ahí no está el trabajo. Está en decidir el modelo: qué es un rol y qué es una capacidad, cómo se representa la estructura de la organización, qué aplicaciones delegan y en qué orden. Un servidor de identidad mal modelado añade una capa al problema en vez de resolverlo.
¿Qué gana el negocio con tener un único emisor de identidad?
Tres cosas comprobables. Las personas se dan de alta y de baja una vez, no una vez por servicio. Los roles no se replican en cada aplicación: se declaran donde vive la identidad, viajan en el token y la aplicación los traduce en cada inicio de sesión. Y revocar revoca de verdad: si retiras un rol, los tokens de API que dependían de él dejan de valer en la siguiente petición aunque sigan existiendo.
¿Hay que migrarlo todo de golpe?
No. Se empieza por las aplicaciones donde el acceso es más sensible y se avanza una a una: cada aplicación que delega es una lista de usuarios menos que mantener. Lo que no se pueda mover se documenta como excepción explícita, que ya es mejor que la ambigüedad.
No usamos Kubernetes. ¿Nos sirve la mitad?
La capa de identidad es independiente de dónde corran tus cosas. La gobernanza del cambio solo necesita que la infraestructura esté descrita como configuración, con Kubernetes o sin él; lo que no funciona es gobernar servidores configurados a mano.
Consultoría relacionada
Montar un homelab desde cero: Kubernetes y GitOps - Homelab (03/06)
Montar un homelab desde cero: seguridad y operaciones - Homelab (04/06)
Consultoría DevOps e infraestructura
Un despliegue por cliente o un espacio por cliente
Del estándar al grafo y al proyecto
Consultoría de arquitectura de plataformas
Hablemos
Cuéntanos cuántos sitios distintos hay que tocar para dar de baja a alguien en tu empresa. Con esa respuesta ya podemos decirte por dónde empezaríamos.