Azure RBAC mínimo privilegio: chau al rol Contributor

En pocas palabras: Para una revisión de arquitectura de solo lectura en Azure alcanza con un rol personalizado de tres permisos: */read, exportTemplate/action y topology/action, sin Data Actions. Prateek Singh (Ganak AI Labs, Cloudeval) publicó esta guía, actualizada el 6 de octubre de 2026, como alternativa al rol Contributor.

Azure RBAC de mínimo privilegio es la práctica de asignarle a una identidad solo las acciones de Azure Resource Manager que necesita para su tarea, sin permisos de escritura ni acceso a datos. Para una herramienta de revisión de arquitectura de solo lectura, como Cloudeval, eso significa un rol personalizado con tres acciones concretas en vez del Contributor que usan casi todas las guías rápidas.

¿Por qué los escáneres de arquitectura piden el rol Contributor por defecto?

Porque es una sola línea y siempre funciona. La mayoría de las guías de setup arrancan con az ad sp create-for-rbac --role Contributor, que le da a la service principal permiso para gestionar casi todo en el scope asignado, excepto administrar accesos. Nada falla durante la instalación, así que nadie se pregunta si hace falta tanto.

El problema es otro. Una credencial que puede borrar recursos es un riesgo mucho más grande de guardar en un servicio de terceros que una que solo puede leer. Ponele que la clave de tu service principal termina filtrada en un repo público (pasa más de lo que te gustaría admitir): con Contributor, quien la encuentre puede modificar tu infraestructura. Con un rol de solo lectura, lo peor que puede hacer es mirar.

Microsoft lo dice sin vueltas en sus procedimientos recomendados de RBAC: hay que conceder el mínimo privilegio necesario y “evitar asignar roles más amplios en ámbitos más amplios incluso si inicialmente parece más conveniente hacerlo”. Cloudeval, la herramienta que documenta este caso, no necesita Contributor para su sincronización normal con Azure (Cloud sync).

¿Qué permisos necesita realmente una revisión de arquitectura de solo lectura en Azure?

Necesita exactamente tres acciones: leer metadata del plano de control, exportar plantillas de implementación y consultar la topología de red. Nada de Data Actions, nada de escritura, nada de administración de accesos. Esto se conecta con lo que analizamos en conectarte por SSH a una VM.

*/read es la única acción del rol incorporado Reader de Azure: lee suscripción, grupo de recursos, recursos, proveedores, implementaciones y metadata de topología dentro del scope asignado. Las otras dos acciones son específicas de lo que necesita una herramienta que arma un reporte de arquitectura a partir de recursos ya desplegados.

Permiso	Qué permite	Para qué lo usa el escáner
*/read	Leer información de control plane de todos los recursos de Azure (única acción del rol Reader)	Leer suscripción, grupo de recursos, recursos, proveedores, implementaciones y topología en el scope
Microsoft.Resources/deployments/exportTemplate/action	Exportar la plantilla de una implementación	Armar los datos de entrada del reporte a partir de recursos en vivo
Microsoft.Network/networkWatchers/topology/action	Obtener una vista de red con recursos y relaciones dentro del grupo de recursos	Agregar la topología de Network Watcher al grafo de arquitectura
Data Actions	Ninguna	No se necesita acceso a contenido de blobs ni valores de secretos de Key Vault

Eso es todo lo que entra en el rol. Reader más dos acciones nombradas, sin comodines innecesarios en el resto de la definición.

¿Cómo crear el rol personalizado y asignarlo paso a paso?

Se crea una service principal dedicada sin rol asignado, se define el rol personalizado en un JSON y se asigna a nivel de grupo de recursos. Tres pasos, sin Contributor en ningún momento.

Primero, la service principal. Las versiones actuales de Azure CLI no asignan ningún rol en az ad sp create-for-rbac salvo que se pase el flag --role, así que si lo omitís, la identidad arranca sin acceso. Relacionado: certificaciones de Azure según tu rol.

• Service principal dedicada: una identidad por herramienta, para poder rotarla o revocarla sin tocar el resto del entorno.
• Definición del rol en JSON: Actions con las tres acciones de la tabla anterior, DataActions vacío y AssignableScopes apuntando a la suscripción.
• Creación con CLI: az role definition create --role-definition archivo.json registra el rol en Azure.
• Asignación con scope acotado: az role assignment create --assignee $APP_ID --role "nombre-del-rol" --scope /subscriptions/.../resourceGroups/$RG lo aplica solo al grupo de recursos elegido.

Un detalle que confunde a mucha gente: AssignableScopes controla dónde se puede asignar el rol, no dónde se asigna de hecho. Si querés cambiar los scopes asignables de un rol ya existente, corrés az role definition update con el mismo JSON modificado, según documenta el tutorial oficial de roles personalizados con CLI.

Network Watcher suele vivir en su propio grupo de recursos, por defecto NetworkWatcherRG. Si querés topología de red y ese grupo queda fuera del scope que asignaste, la sincronización va a seguir leyendo recursos y exportando plantillas, pero las relaciones de red van a aparecer flacas o directamente vacías.

¿Alcanza con el rol Reader incorporado de Azure?

Casi, pero no del todo. Reader es exactamente */read, sin ninguna otra acción y sin Data Actions. Para una revisión de arquitectura completa le faltan las dos acciones específicas de exportación de plantillas y topología de red.

Sin exportTemplate/action, los datos de entrada del reporte pueden quedar incompletos. Sin topology/action, el grafo de red sale más pobre de lo esperado. ¿Se puede arreglar agregando Contributor? No, y ahí está el punto de todo este enfoque: la solución es sumar las dos acciones puntuales, no ampliar el rol entero.

Hay un matiz técnico que vale la pena marcar. */read es un comodín, y las best practices de Microsoft recomiendan listar las acciones de forma explícita en roles personalizados en vez de usar comodines, porque un wildcard también va a cubrir acciones futuras que todavía no existen. En este caso particular cubre solo lecturas y espeja al rol Reader, así que el riesgo real está en el scope, no en el comodín. Asignalo por grupo de recursos y, si tu organización es estricta con esto, cambiá */read por una lista explícita de las acciones de lectura que realmente usás.

¿Qué hacer si faltan permisos o datos sin ampliar el rol a Contributor?

Casi siempre el arreglo es una acción puntual o una asignación puntual, nunca Contributor. Cuando algo sale incompleto, el primer paso es mirar la tabla de síntomas antes de tocar el rol. Más contexto en comparativa entre Microsoft y GitHub.

Síntoma	Causa probable	Arreglo
La conexión autentica pero no aparece ningún grupo de recursos	La asignación todavía no propagó, o está en otra suscripción o grupo	Esperar unos minutos, revisar el scope y probar de nuevo
El grupo de recursos se ve pero los reportes fallan al armarse	Al rol le falta deployments/exportTemplate/action	Actualizar la definición del rol y volver a sincronizar
El grafo funciona pero las relaciones de red salen escasas	Falta networkWatchers/topology/action, o no hay asignación en NetworkWatcherRG	Agregar la acción y asignar también en el grupo de Network Watcher
La sincronización incluye demasiados grupos de recursos	El rol quedó asignado a nivel suscripción, o no se eligieron grupos específicos	Asignar a nivel resource group y seleccionar los grupos objetivo

Volver a correr la sincronización sin confirmar antes el scope no soluciona nada. Lo único que vas a conseguir es una copia más fresca del mismo problema.

Errores comunes al configurar RBAC de mínimo privilegio en Azure

• Copiar el comando de la guía rápida sin revisar el flag –role: muchos tutoriales de terceros arrancan con Contributor porque es la opción que menos fricción genera en la demo, no porque sea necesaria en producción.
• Asignar a nivel suscripción “por si acaso”: conviene reservar ese scope para cuando la herramienta deba descubrir y sincronizar cada grupo de recursos accesible, y documentar por qué se eligió ese alcance más amplio.
• Agregar Data Actions para “completar” un reporte: si un reporte parece esperar contenido de blobs o secretos de Key Vault, agregar Data Actions no es la respuesta. Un escáner de solo lectura trabaja con metadata del plano de administración, no con datos.
• Probar con un scope gigante multi-suscripción desde el arranque: con un alcance enorme es imposible distinguir si un gap viene de permisos faltantes o del scope mal elegido. Conviene arrancar con un grupo de recursos representativo.
• Olvidarse de rotar el secret de la service principal: un secret vencido es una de las causas más comunes de que una conexión que antes funcionaba empiece a fallar sin motivo aparente.

Qué significa esto para equipos de infraestructura en Latinoamérica

Si tu equipo gestiona Azure para varios clientes o varias áreas internas, este patrón de rol personalizado con tres acciones vale mucho más que cualquier checklist genérica de seguridad. Un credencial de solo lectura que se filtra es un incidente administrable. Una credencial Contributor que se filtra es un incidente de verdad, con borrado de recursos como peor escenario posible.

El mismo criterio de mínimo privilegio aplica más allá de Azure: si tu infraestructura corre en proveedores locales de cloud o hosting, como donweb.com, vale la pena auditar qué accesos tienen las herramientas de terceros conectadas a tus paneles de administración, no solo las que leen datos de nube pública.

Preguntas Frecuentes

¿Por qué los asistentes de configuración de Azure piden el rol Contributor?

Porque es la opción que garantiza que la instalación no falle: Contributor gestiona casi todo en el scope asignado, excepto los accesos. Las guías rápidas lo usan por comodidad, no porque la herramienta necesite permisos de escritura.

¿Qué permisos mínimos necesita una herramienta de solo lectura en Azure?

Para un escáner de arquitectura típico, tres acciones: */read, Microsoft.Resources/deployments/exportTemplate/action y Microsoft.Network/networkWatchers/topology/action, sin ninguna Data Action. Para más detalles técnicos, mirá repos de Microsoft comprometidos con malware.

¿El rol Reader incorporado de Azure alcanza para auditar recursos?

Cubre la lectura básica de metadata con */read, pero le faltan las acciones de exportar plantillas de implementación y de consultar topología de red, necesarias para un reporte de arquitectura completo.

¿Cómo creo un rol personalizado en Azure RBAC con la CLI?

Se define un archivo JSON con Name, Actions, DataActions y AssignableScopes, y se registra con az role definition create --role-definition archivo.json. Para modificarlo después se usa az role definition update con el mismo archivo editado.

¿Por qué no aparecen las relaciones de red después de sincronizar con Azure?

Casi siempre falta la acción Microsoft.Network/networkWatchers/topology/action en el rol, o el rol no está asignado en el grupo de recursos donde vive Network Watcher, por defecto NetworkWatcherRG.

Conclusión

Un escáner de arquitectura de solo lectura no necesita un rol que pueda escribir. El caso documentado por Cloudeval muestra que con tres acciones (*/read más dos actions puntuales) y cero Data Actions alcanza para leer recursos, exportar plantillas y mapear topología de red, todo asignado a nivel de grupo de recursos y con una service principal dedicada por herramienta.

Si estás evaluando qué credenciales le das a cualquier herramienta de terceros conectada a tu entorno de Azure, el criterio práctico es simple: pedile al proveedor la lista exacta de acciones que necesita, armá el rol personalizado con esa lista y nada más, y reservá Contributor únicamente para pruebas descartables en un grupo de recursos que no use nadie más. Si una conexión falla después de aplicar un rol acotado, el arreglo casi nunca es ampliar el rol: es revisar el scope y agregar la acción puntual que falta.

Fuentes

• Least-privilege Azure RBAC for read-only architecture review – Prateek Singh, Cloudeval AI (actualizado 6/10/2026)
• Procedimientos recomendados para RBAC de Azure – Microsoft Learn
• Tutorial: Crear un rol personalizado de Azure con la CLI – Microsoft Learn