Arquitectura Azure — Módulo 2: identidad y managed identities

El patrón de identidad de la serie no se mueve: el agente es un principal propio, con permisos por tarea y cero llaves de larga vida — la teoría en AWS, el dialecto en GCP. Azure lo implementa con la pieza más cómoda de las tres nubes y un modelo de asignación que ya conoces de GCP.

Concepto	En AWS	En GCP	En Azure
Identidad de workload/agente	Rol IAM	Service account	Managed identity
Asignación de permisos	Policy en el principal	Binding en el ámbito	Role assignment en el scope
Permisos mínimos	Políticas a medida	Roles predefinidos	Roles built-in de RBAC (+ custom)
App/servicio externo	Usuario IAM (evitar) / OIDC	SA + federación	Service principal + federación
Humanos	Identity Center	Cloud Identity	Entra ID (el mismo directorio)

La tesis del módulo

La managed identity es el rol-sin-llaves llevado a su forma más simple: Azure la crea, la rota y la inyecta — no hay archivo de credencial que exportar ni siquiera como opción de mala práctica — y el RBAC asigna roles sobre scopes jerárquicos (management group → suscripción → RG → recurso) con la herencia que ya dominas de GCP. La novedad de fondo es contextual: como todo vive en Entra ID, la identidad del agente, la del microservicio que lo sirve y la del humano que lo aprueba son entradas del mismo directorio — y eso vuelve baratas integraciones que en otras nubes eran proyectos.

Managed identities: las dos formas

• System-assigned: la identidad nace con el recurso (este Container App tiene la suya) y muere con él. Simple, uno-a-uno, ideal para el caso base.
• User-assigned: la identidad existe como recurso propio y se asigna a uno o más recursos de cómputo. Es la forma que la plataforma de agentes prefiere: la identidad del agente como pieza estable (con sus role assignments cuidados) que sobrevive a redespliegues del cómputo y puede compartirse entre las piezas que legítimamente son “el mismo agente” (su job y su function auxiliar).

En ambas formas, el contrato es el mismo: el código pide un token al entorno (sin secreto alguno en variables, archivos o prompts) y Azure lo emite por la identidad asignada. No existe la “llave JSON exportable” — la tentación que GCP debía prohibir por política, en Azure no está en el menú. El test de la serie (¿puede el agente imprimir su credencial si se lo piden con astucia?) da “no” estructural por diseño.

   CÓMO ACTÚA UNA MANAGED IDENTITY (SIN LLAVES)

  ┌──────────────────────────┐
  │ Container App del agente │
  │ (identidad asignada)     │
  └────────────┬─────────────┘
               │ pide token al entorno
               ▼
  ┌──────────────────────────┐
  │ Entra ID emite el token  │
  │ (expira solo; no hay     │
  │ secreto que guardar)     │
  └────────────┬─────────────┘
               │ llama al recurso
               ▼
  ┌──────────────────────────┐   deny
  │ RBAC: ¿role assignment   │ ──────► rechazo
  │ en este scope o arriba?  │         (log)
  └────────────┬─────────────┘
         allow ▼
  ┌──────────────────────────┐
  │ Service Bus / Cosmos /   │
  │ despliegue de Foundry    │
  └──────────────────────────┘

Para lo que corre fuera de Azure (CI/CD, otras nubes), el service principal es la identidad de aplicación registrada en Entra — y su forma moderna usa federación de credenciales (el token OIDC de GitHub Actions intercambiado por acceso, sin secretos guardados), el calco del Workload Identity Federation de GCP. Si un service principal tiene un client secret guardado en un repo, es la llave de larga vida de esta casa: mismo pecado, mismo tratamiento.

RBAC: roles sobre scopes, herencia incluida

El RBAC de Azure asigna un rol (lista de permisos con nombre: Storage Blob Data Reader, Cognitive Services OpenAI User) a una identidad en un scope — management group, suscripción, resource group o recurso individual — con herencia hacia abajo. Es el modelo de bindings de GCP con los nombres cambiados, y trae las mismas dos consecuencias:

1. El mínimo privilegio se arma con roles built-in en el scope más chico que funcione. El RG-por-agente del módulo 1 paga aquí su primer dividendo: la managed identity del agente de triaje con sus tres roles asignados sobre su propio RG (y sobre la cola y el modelo concretos que usa fuera de él) — nada del resto de la suscripción. Los roles amplios en scopes altos (Contributor en la suscripción — el Editor de esta casa) son el comodín a cazar en auditoría.
2. Se audita hacia arriba. Los permisos efectivos incluyen lo heredado de suscripción y management groups — la lección de GCP, válida entera.

Ojo — la ventaja del directorio único, con su reverso: que agentes, servicios y humanos compartan Entra ID habilita finuras como grupos de aprobadores corporativos gobernando acciones de agentes (módulo 11) o Conditional Access aplicado a identidades de workload. El reverso: el directorio corporativo suele administrarlo otro equipo con otros tiempos. El diseño de la plataforma debe decidir temprano qué vive en RBAC de Azure (recursos — tu cancha) y qué exige tocar Entra (grupos, apps, políticas — cancha compartida), porque la segunda lista lleva calendario ajeno. En AWS y GCP este problema casi no existía; en Azure es un ítem del plan.

El confused deputy multiusuario tampoco se despide en la última nube: el agente potente al servicio de cualquier prompt sigue exigiendo permisos por sesión o validación dura en herramientas — la teoría ya está escrita; solo cambia que aquí los mecanismos hablan tokens de Entra.

Errores comunes

• Client secrets de service principals en repos. La llave de larga vida de Azure. Federación OIDC para lo externo, managed identities para lo interno — secretos guardados, cero.
• Contributor en la suscripción “para avanzar”. El comodín de esta casa, con el mismo ciclo de vida eterno de todos los comodines. Roles built-in específicos en el scope del RG del agente.
• System-assigned para todo por inercia. Cuando la identidad del agente debe sobrevivir al redespliegue o compartirse entre sus piezas, la user-assigned es la forma correcta — y la que mantiene los role assignments estables.
• Ignorar la frontera Azure/Entra en el plan. Los permisos de recursos son tuyos; los grupos y apps del directorio suelen ser de otro equipo. Descubrirlo en la semana del despliegue es el clásico atraso evitable.
• Auditar solo el scope del recurso. La herencia de management groups y suscripción es invisible a nivel de RG. Hacia arriba, siempre — tercera nube, misma regla.
• Traducir “rol” sin mirar. El rol de AWS es identidad; el de GCP y Azure, lista de permisos. En Azure la identidad es la managed identity. El falso amigo de la serie, última llamada.

La frase para llevarse

“La managed identity es el mínimo privilegio sin tentaciones: no hay llave que exportar ni secreto que guardar — solo roles concretos en el scope más chico que funcione, auditados hacia arriba. Y la ventaja de Azure es de contexto: tu agente y su aprobador humano viven en el mismo directorio — úsalo, pero agenda con quien lo administra.”

Qué viene

Módulo 3: cómputo — Container Apps y las Durable Functions. El menú de Azure para los patrones de siempre: Container Apps (el Cloud Run de esta casa, con KEDA escalando por largo de cola — un regalo para agentes), Functions para lo corto, AKS para lo organizacional — y una pieza sin equivalente directo que adelanta el módulo 11: las Durable Functions, orquestación con estado escrita como código.

Material relacionado

• Módulo 1: el mapa de Azure
• Módulo 3: cómputo — Container Apps
• Curso de AWS — Módulo 2: identidad, IAM y el agente como principal
• Curso de GCP — Módulo 2: identidad y service accounts
• Glosario de Arquitectura Azure para Agentes de IA