Mis alumnos son profesionales expertos, en muchos de los casos, en el uso real del Cloud. A los cuales no les puedo contar solo historias de unicornios y arco iris desde un plano teórico o del temario; y que me hacen preguntas complejas que me motivan al aprendizaje e investigación constante, como en mis mejores tiempos de consultoría.
Uno de ellos me hizo una pregunta recurrente sobre la inconveniencia de tener acceso a la información que ofrece el KUDU de cualquier WebApp, y si existe alguna forma de impedirlo, o limitarlo.
Y la respuesta que he encontrado me ha dejado bastante insatisfecho.
Jugando con el RBAC
Él control de acceso basados en roles, junto con las policies de los recursos, son los mecanismos que utilizo para dar los privilegios de uso a los usuarios, o grupos de usuarios.
Y es la solución más sencilla para mi objetivo de evitar que un usuario pueda acceder al Kudu de una Web app: dar permisos solo de lectura a nivel de la suscripción.
¿Es suficiente? No.
Es más bien matar moscas a cañonazos, porque también le estoy dando acceso al usuario a todos los recursos de la suscripción (aunque sea en modo de lectura). Y lo peor es que no hay forma fácil de evitarlo desde el portal, ya que los privilegios se heredan a todos los recursos dentro de la misma y no se pueden eliminar.
La otra opción que tengo es crear mi propio Rol con powershell o az cli. Pero, tampoco hay un permiso especial para el acceso al Kudu y (aunque aún no lo he podido comprobar) no tendría forma de limitar su uso. De hecho, en el listado de privilegios que se pueden definir en un rol personalizado, no he localizado ninguno que me valga.
Al parecer -solo desde un plano teórico- por ahora la única forma de hacer un rol que deniegue privilegios es por medio de los novedosos Blueprint; mecanismos de construcción de infraestructura y servicios que aúnan conjuntos de recursos, plantillas arm, asignaciones de roles y directivas, para asegurar la configuración del entorno.
Y aunque no es una respuesta definitiva, espero que sea de utilidad.