CAPÍTULO 9 · El mismo proyecto llega a Azure
Administrar Azure es otra responsabilidad
Un supervisor de la plataforma puede configurar umbrales sin tener motivo para cambiar el plan de alojamiento. Del mismo modo, quien publica una versión en Azure no debería recibir automáticamente todas las capacidades de negocio dentro de Django. Los recursos y la aplicación tienen ámbitos de autorización diferentes.
Revisamos IAM para asignar al operador el alcance que necesita sobre los recursos. Esta decisión permite separar publicación, mantenimiento y administración de datos, de acuerdo con las tareas del equipo. El nombre de un rol no debe ocultar su alcance real; necesitamos conocer qué operaciones permite y dónde se aplica.
Con el operador autorizado podemos continuar la preparación del servicio. El código espera determinadas variables desde que se inicia. El siguiente paso consiste en entregar esos valores al proceso alojado sin volver a editar el proyecto ni copiar los secretos del computador al paquete de publicación.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Permisos cloud con un alcance concreto
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Principal. Persona o identidad técnica
- Rol Azure. Conjunto de acciones permitidas
- Scope. Recurso que se administra
- Prueba. Confirma permitidos y denegados
01 / EL PROBLEMA
¿Para qué sirve?
Un desarrollador necesita publicar una web, pero no necesariamente administrar toda la suscripción o cambiar el plan compartido por otros equipos.
02 / COMPRENDER
El concepto, explicado
Azure RBAC controla administración de recursos; roles de Entra controlan directorio; roles internos de Django controlan negocio. Ser administrador de SensorHub no concede despliegue y ser colaborador Azure no es un rol funcional de la app.
Cada asignación combina principal, rol y scope. Website Contributor y Web Plan Contributor tienen acciones diferentes: revisa el rol actual antes de otorgarlo.
Una identidad administrada de la app sirve para los accesos que la app realiza. No necesita administrarse a sí misma para atender HTTP. La identidad de GitHub Actions que despliega puede ser distinta y usar federación OIDC.
Un plan compartido implica impacto compartido. Delegar cambios al plan puede afectar otras webs, aunque el permiso sobre el sitio esté bien acotado.
Tres ámbitos de permisos
| Ámbito | Recurso que gobierna | Ejemplo |
|---|---|---|
| Azure RBAC | Infraestructura Azure | Publicar una web |
| Roles Entra | Directorio e identidad | Invitar usuarios B2B |
| Capacidades Django | Acciones y objetos de negocio | Editar umbral de un sensor |
03 / CONSTRUIR
Implementación paso a paso
- Lista tareas: publicar, consultar logs, modificar settings y escalar plan.
- Identifica el recurso mínimo y sus dependencias por tarea.
- Consulta acciones de los roles y elige alcance por recurso cuando sea suficiente.
- Crea o usa una identidad de despliegue dedicada con federación restringida al repo y entorno.
- Revisa asignaciones heredadas y privilegios de grupos.
- Comprueba tareas permitidas y denegadas con la cuenta delegada.
04 / APLICAR
Ejemplo en SensorHub
# Esquema de asignación; IDs y roles se validan antes de aplicar.
assignments = [
{"principal": "deploy-sensorhub-prod", "role": "Website Contributor",
"scope": "<RESOURCE_ID_APP_SERVICE>"},
{"principal": "support-sensorhub", "role": "Reader",
"scope": "<RESOURCE_ID_APP_SERVICE>"},
]
# No agrega Web Plan Contributor si la tarea no necesita cambiar el plan.Cómo leer el ejemplo
- La lista describe intención; no ejecuta cambios en Azure.
- Reader no implica automáticamente acceso a todos los datos de telemetría.
- La identidad de runtime solo recibe los permisos de recursos que consume.
Error habitual
Conceder Contributor sobre la suscripción para resolver un error de publicación sin investigar la acción faltante.
05 / PRACTICAR
Tu turno
Un desarrollador publica SensorHub y otro servicio usa el mismo plan. ¿Delegarías cambios al plan?
Ver solución orientativa
Mantén administración del plan en un responsable común salvo necesidad justificada. Delega publicación al sitio, valida dependencia y documenta una escalación para cambios de capacidad.
06 / VERIFICAR
Cómo sabes que funciona
- El scope no se amplía por conveniencia.
- Se revisan permisos heredados.
- La identidad de runtime y la de despliegue tienen tareas explícitas.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Variables de producción y contrato de configuración →Continuar en modo relato