☁️ Azure & Entra ID: Guía de Identidades, Jerarquía y AI Foundry
Guía de preparación técnica enfocada en arquitectura, modelos de seguridad en Microsoft Entra ID (antes Azure AD), gestión de recursos en Azure, gobernanza, despliegue de cargas de IA en Azure AI Foundry, y equivalencias directas para ingenieros provenientes de Amazon Web Services (AWS).
01. Entra vs Azure: Planos de Control Separados
Aunque ambos entornos se gestionan desde el mismo portal (portal.azure.com), corresponden a dos sistemas de permisos independientes que operan en capas completamente aisladas.
Analogía del Edificio: Imagina un edificio corporativo de oficinas.
Microsoft Entra ID
Es la recepción y RRHH: valida quién eres, a qué grupos perteneces y si tienes acceso al edificio. Antes conocido como Azure AD.
- Vive a nivel global del Tenant (la organización).
- Gestiona Usuarios, Grupos, App Registrations, Service Principals e Identidades.
- Sus roles (ej: Global Administrator, User Administrator) administran el directorio, no los recursos cloud.
Azure (Plataforma Infra/PaaS)
Son las oficinas, escritorios y herramientas internas: Máquinas Virtuales, Storage Accounts, Datasets, Redes y Bases de Datos.
- Se organiza mediante Management Groups, Suscripciones y Resource Groups.
- Se controla mediante Azure RBAC (ej: Owner, Contributor, Reader).
- Los permisos se asignan con un Scope (ámbito de aplicación específico).
💡 Tip para Entrevistas: "Entra responde a ¿quién eres y puedes autenticarte?; Azure RBAC responde a ¿qué recursos específicos puedes manipular y con qué alcance?. El único puente es que Azure RBAC asigna roles sobre recursos a identidades definidas en Entra."
02. Tipos de Identidad en Entra & Azure
El objetivo principal del diseño moderno de identidades en la nube es permitir que las aplicaciones se autentiquen contra recursos de Azure sin almacenar contraseñas ni secretos en el código fuente.
App Registration vs Service Principal
Para otorgar una identidad propia a una aplicación en Entra ID, se requieren dos objetos interconectados:
App Registration
La definición global de la aplicación: se especifica su nombre, credenciales (certificados, secrets o credenciales federadas), permisos de API (ej: Microsoft Graph) y Redirect URIs.
- Reside en un único tenant (el tenant origen / home).
- Ubicación en consola: Entra ID > App registrations.
- Es una plantilla de configuración (no recibe roles directamente).
Service Principal
La instancia local de dicha aplicación en un tenant concreto. Es la identidad real que se autentica y recibe asignaciones de Azure RBAC.
- Se genera automáticamente al registrar la app (o al conceder acceso en un tenant externo).
- Ubicación en consola: Entra ID > Enterprise applications.
- Es el objeto evaluado por RBAC para permisos de infraestructura.
💡 Analogía de Entrevista: La App Registration es el molde de fabricación (se define una sola vez en el tenant origen); el Service Principal es la escultura de concreto creada a partir del molde en cada tenant (la que ocupa espacio y recibe permisos). Por ello, una arquitectura multi-tenant posee 1 App Registration y múltiples Service Principals.
Managed Identities & Workload Identity Federation
Para evitar la rotación manual de secretos o cerificados, Azure provee identidades administradas automáticas:
Managed Identity
Un Service Principal cuyos secretos son creados, inyectados y rotados automáticamente por la plataforma de Azure. El código de la aplicación interactúa con la API de metadatos local para obtener tokens.
System-assigned
Habilitada directamente en un recurso (VM, App Service, Function). Su ciclo de vida está acoplado de forma rígida al recurso: si el recurso se elimina, la identidad se destruye en Entra ID.
User-assigned
Creada como un recurso independiente en Azure. Se puede asociar a múltiples recursos simultáneamente y persiste aunque los recursos asociados sean eliminados.
Workload Identity Federation
Permite a cargas fuera de Azure (GitHub Actions, AWS, GCP, Kubernetes On-Premise) autenticarse mediante OIDC. Entra valida el token JWT emitido por el proveedor externo y entrega un token de Azure sin usar secretos.
03. Jerarquía de Recursos y Herencia de Roles
La estructura organizativa de Azure sigue un árbol estrictamente descendente donde las políticas de acceso e IAM se propagan automáticamente hacia los niveles inferiores.
Service Groups Public Preview
A diferencia de la jerarquía rígida vertical (Management Group > Subscription > Resource Group), los Service Groups son agrupaciones lógicas a nivel de Tenant que permiten crear vistas transversales entre diferentes suscripciones.
Jerarquía Estándar
- Un solo padre por recurso (relación estricta).
- Diseñada para RBAC acumulativo y Azure Policy.
- Herencia obligatoria de permisos hacia los recursos.
Service Groups
- Un recurso puede formar parte de múltiples Service Groups.
- Diseñado para inventario, observabilidad y agrupamiento lógico.
- Los permisos NO se heredan hacia los recursos miembros (respetando el principio de mínimo privilegio).
04. Azure AI Foundry: Hub, Proyectos y Cuentas
Azure AI Foundry es el entorno unificado de desarrollo para construir, evaluar y desplegar modelos de IA generativa y Machine Learning.
Arquitectura Hub-Proyecto
Centraliza las conexiones de red privada, almacenamiento (Storage Account), administradores de llaves (Key Vault) y capacidades de cómputo.
Tipos de Cuentas de IA (Kinds)
| Kind de Cuenta | Modelos Incluidos | Escenario Recomendado |
|---|---|---|
| AIServices | OpenAI (GPT-4o), Mistral, Llama 3, Cohere, más Servicios Cognitivos clásicos (Visión, Voz, Lenguaje). | Configuración estándar móderna multi-modelo bajo un único endpoint administrado. |
| OpenAI | Exclusivo para modelos de OpenAI (GPT-4, GPT-3.5, Embeddings, DALL-E). | Aislamiento estricto de cuotas, límites de tasa (TPM/RPM) y fronteras de red para OpenAI. |
| CognitiveServices | Servicios tradicionales de visión por computador, traducción y análisis de texto (sin LLMs). | Integraciones legacy que no requieren capacidades de IA Generativa. |
Requerimientos de Permisos RBAC en AI Foundry
Al desplegar entornos seguros con VNet privada y acceso restringido, Azure aplica una política deny-by-default. Dado que el Hub y los Proyectos se interconectan mediante Conexiones (que no propagan roles RBAC automáticamente), es necesario autorizar explícitamente tres identidades:
| Identidad | Momento de Ejecución | Propósito del Acceso RBAC |
|---|---|---|
| Azure Machine Learning RP | Aprovisionamiento inicial. | Permite a la infraestructura subyacente crear y orquestar recursos en la suscripción. |
| Managed Identity del Hub | Configuración de recursos. | Permite al Hub vincular y autenticarse contra las Cuentas de IA y Storage Accounts. |
| Managed Identity del Proyecto | Tiempo de inferencia / ejecución. | Permite a las ejecuciones dentro del Proyecto consumir los endpoints de los modelos. Requiere roles como Azure AI Developer y Cognitive Services OpenAI Contributor. |
05. Estrategias de Despliegue de Modelos de IA
Azure ofrece cuatro enfoques principales para ejecutar modelos fundacionales, balanceando la complejidad operativa con el control de infraestructura.
Serverless API (Pay-as-you-go)
Consumo del modelo como servicio administrado vía API REST. Sin gestión de máquinas ni GPUs.
- Pago estricto por token procesado.
- Escalabilidad automática instantánea.
- Ideal para cargas con demanda variable o prototipos.
Managed Compute (Infra Dedicada)
Despliegue de pesos del modelo en instancias de GPU dedicadas dentro de la suscripción, gestionadas por Foundry.
- Pago fijo por hora de GPU reservada.
- Aislamiento de red completo dentro de VNet propia.
- Requerido para modelos del catálogo que carecen de opción Serverless.
VMs con GPUs Dedicadas (NC / ND / NV Series)
Aprovisionamiento manual de instancias IaaS con GPUs NVIDIA. El equipo de ingeniería administra el sistema operativo, controladores CUDA, runtime (ej: vLLM, Ollama, Triton) y la capa de API.
- Control absoluto: Permite ejecutar cualquier modelo o arquitectura no soportada en el catálogo.
- Multiuso: Adecuado para fine-tuning pesado, entrenamiento distributed y procesamiento HPC.
- Carga Operativa: Responsabilidad total sobre parches, alta disponibilidad y escalado manual.
AKS Cluster con Node Pools de GPUs
Despliegue de servidores de inferencia orquestados en Kubernetes mediante Azure Kubernetes Service. Proporciona despliegues declarativos, escalado basado en métricas customizadas (KEDA) y balanceo entre réplicas.
- GPU Slicing en AKS:
- Time-Slicing (Software): Multiplexación por software para entornos Dev/Test o modelos livianos. Sin aislamiento de memoria (riesgo de noisy neighbor).
- MIG / Multi-Instance GPU (Hardware - A100/H100): Particionamiento físico de la GPU en hasta 7 instancias independientes con memoria y cores dedicados para producción.
06. Matriz de Equivalencias: AWS vs Azure
Tabla de correspondencia directa para arquitectos e ingenieros con experiencia previa en Amazon Web Services.
| Recurso Azure | Equivalente AWS | Diferencia Clave de Arquitectura |
|---|---|---|
| IDENTIDAD Y GOBERNANZA | ||
| Microsoft Entra ID | AWS IAM Identity Center + IAM | Entra ID es un directorio empresarial e IdP completo. En AWS, IAM se encuentra distribuido por cuenta. |
| Azure RBAC | AWS IAM Policies | RBAC asigna roles predefinidos sobre un scope jerárquico. AWS IAM utiliza políticas JSON asociadas a entidades. |
| Subscription | AWS Account | Límite principal de facturación y aislamiento de recursos. |
| Management Group | AWS Organizations / OU | Agrupamiento jerárquico para herencia de políticas y gobernanza. |
| Resource Group | (Sin equivalente directo) | Contenedor obligatorio en Azure. AWS utiliza etiquetado (Tags) o Stacks de CloudFormation. |
| Managed Identity | AWS IAM Roles for EC2/EKS | Asignación de identidades a recursos informáticos sin credenciales en código. |
| INTELIGENCIA ARTIFICIAL Y MACHINE LEARNING | ||
| Azure AI Foundry | Amazon Bedrock + SageMaker Studio | Foundry unifica la gestión de modelos fundacionales multi-proveedor y el ciclo de vida de ML. |
| Azure OpenAI Service | Amazon Bedrock (Anthropic, Meta, Amazon) | Modelos gestionados vía API. Azure posee acceso exclusivo de grado empresarial a la suite de OpenAI. |
| Azure Machine Learning | Amazon SageMaker | Plataforma end-to-end para entrenamiento, versionado y despliegue de modelos ML. |
| ALMACENAMIENTO Y BASES DE DATOS | ||
| Azure Blob Storage | Amazon S3 | Almacenamiento de objetos masivo sin estructurar. |
| Azure Cosmos DB | Amazon DynamoDB | Base de datos NoSQL distribuida globalmente. Cosmos DB soporta APIs múltiples (Mongo, Cassandra, SQL, Gremlin). |
| Azure SQL Database | Amazon RDS (SQL Server) / Aurora | Base de datos relacional PaaS completamente administrada. |
| COMPUTO Y REDES | ||
| Azure Virtual Machines | Amazon EC2 | Instancias IaaS de cómputo. |
| Azure Kubernetes Service (AKS) | Amazon EKS | Orquestador de contenedores Kubernetes administrado. |
| Azure Functions | AWS Lambda | Cómputo serverless impulsado por eventos. |
| Virtual Network (VNet) | Amazon VPC | Red privada virtual en la nube. |
| Azure Key Vault | AWS KMS + Secrets Manager | Key Vault centraliza claves criptográficas, secretos y certificados TLS en una sola herramienta. |
📌 Resumen de Cambio de Paradigma (AWS → Azure):
1. Una Suscripción de Azure equivale a una Cuenta de AWS.
2. Los Resource Groups son obligatorios en Azure para gestionar el ciclo de vida de los recursos.
3. El plano de identidad (Entra ID) está desacoplado del plano de gestión de recursos (Azure RBAC).