Dueño de la suscripción y sin permiso para leer un secreto

Venía de Google Cloud, donde estaba acostumbrado a que un propietario del proyecto lo pueda casi todo. En Azure quedé como Owner de la suscripción y descubrí que eso no me daba acceso a ningún dato: ni a un secreto de la bóveda, ni al estado de Terraform, ni al clúster.

Dos planos, dos permisos

Azure separa el plano de control, que crea, cambia y borra recursos, del plano de datos, que lee y escribe lo que hay adentro. Owner tiene todas las acciones del plano de control y ninguna acción de datos, así que los datos piden roles propios.

En el laboratorio eso se tradujo en cuatro decisiones concretas:

• ·La bóveda de secretos está en modo RBAC, no en políticas de acceso. Escribir un secreto exige Key Vault Secrets Officer, y la identidad de la aplicación solo tiene Key Vault Secrets User, que lee.
• ·La cuenta del estado de Terraform tiene las claves compartidas apagadas. Sin clave, el acceso es con Entra ID, y leer o escribir el estado exige Storage Blob Data Contributor sobre esa cuenta.
• ·El clúster tiene las cuentas locales de Kubernetes deshabilitadas y la autorización pasa por Azure RBAC. Usar kubectl como administrador exige Azure Kubernetes Service RBAC Cluster Admin sobre el clúster.
• ·En el registro de imágenes, el clúster descarga con AcrPull y publicar exige AcrPush, que se le da a quien publica y no a lo que corre.

No es una frontera contra el dueño

Un Owner puede asignarse cualquiera de esos roles, porque puede escribir asignaciones de rol, así que esto no protege los datos del dueño de la suscripción. Lo que hace es obligar a declarar quién toca los datos, con un alcance exacto, y dejarlo en el registro de actividad. Sin esa declaración, el acceso a los datos no existe por accidente.

Por eso en el código cada rol vive al lado del recurso que protege, con el alcance del recurso y no del grupo de recursos: la asignación de la bóveda apunta a la bóveda y la del clúster al clúster.

Por qué apagué cada llave alternativa

Todo esto funciona solo si ninguna de esas puertas tiene una llave de repuesto. Una cuenta de almacenamiento con claves compartidas encendidas deja leer todo a quien tenga la clave, sin pasar por Entra ID y sin rol. Un clúster con cuentas locales tiene un certificado de administrador que no pasa por Azure RBAC. Apagar esas llaves es lo que convierte a los roles de datos en la única forma de entrar.

Un detalle de AKS que conviene saber: desde Kubernetes 1.25, Azure no deja deshabilitar las cuentas locales en un clúster que no esté integrado con Entra ID. Las dos opciones van juntas.

Y una excepción declarada: la cuenta que recibe los registros de flujo de la red virtual mantiene las claves encendidas, porque Network Watcher escribe con la clave de la cuenta y el recurso de Terraform no ofrece una identidad administrada para hacerlo. Nada en el repositorio lee ni guarda esa clave.

Lo que cambia viniendo de Google Cloud

En Google Cloud la separación también existe, pero los roles básicos de propietario y editor abarcan tanto que la costumbre es otra, y la recomendación de Google es justamente no usarlos. Azure la vuelve obligatoria desde el diseño.

Para un equipo que migra, eso significa que el modelo de permisos no se traduce uno a uno. El plano de datos se diseña aparte, y quién lee cada cosa se decide antes de desplegar, no cuando alguien choca con un acceso denegado. La decisión completa está en el repositorio.

En tu plataforma, ¿quién puede leer tus secretos hoy, y cuántos lo pueden hacer solo porque tienen un rol que nadie pensó para eso?