Etiquetas y bloqueos de recursos

Las etiquetas de recursos son pares nombre-valor de metadatos que se adjuntan a los recursos, grupos de recursos y suscripciones de Azure. A diferencia de las estructuras de carpetas, las etiquetas permiten categorizar un mismo recurso según varias dimensiones simultáneamente. Por ejemplo, una VM puede tener a la vez las etiquetas Environment=Production, Team=Backend, CostCentre=CC-042 y Project=Phoenix, lo que permite filtrar de forma independiente por cualquiera de esas dimensiones.

Normalmente, las organizaciones definen una taxonomía de etiquetado estándar que abarca varias dimensiones. Las etiquetas financieras (CostCentre, BudgetOwner) permiten asignar los costes. Las etiquetas operativas (Environment, Criticality, Owner) facilitan el filtrado y las alertas. Las etiquetas del ciclo de vida (AutoShutdown, ExpiryDate) permiten la automatización. Las etiquetas de seguridad (DataClassification, Compliance) son compatibles con las herramientas de seguridad. Definir la taxonomía antes de implementar los recursos evita crear un conjunto de etiquetas incoherente y difícil de consultar.

Las etiquetas se pueden aplicar mediante Azure Portal, la CLI, plantillas de ARM, Bicep y Terraform. El comando az tag administra las etiquetas de los recursos, mientras que az group update aplica etiquetas a los grupos de recursos. Mediante Azure Policy con el efecto Modify o Append, puede agregar o exigir etiquetas automáticamente al crear recursos, lo que garantiza que todos los recursos nuevos tengan una etiqueta CostCentre sin depender de que los desarrolladores recuerden agregarla manualmente.

Es común pensar que las etiquetas de un grupo de recursos se propagan automáticamente a los recursos que contiene. No es así: las etiquetas de los recursos de Azure no se heredan de los ámbitos principales. Si etiqueta un grupo de recursos con Environment=Production, las máquinas virtuales y las bases de datos de ese grupo no reciben automáticamente dicha etiqueta. Para imponer un etiquetado coherente, use una Azure Policy con la definición integrada Inherit a tag from the resource group, que copia automáticamente la etiqueta del grupo de recursos en todos los recursos que contiene.

Las etiquetas son especialmente útiles cuando se combinan con Azure Cost Management. En la vista de análisis de costos, puede agrupar el gasto por cualquier clave de etiqueta; por ejemplo, puede consultar el gasto mensual total por CostCentre para saber qué departamento consume más recursos en la nube. También puede filtrar por Environment=Production para excluir el gasto de desarrollo de los presupuestos de producción. Azure Cost Management requiere que la etiqueta se haya aplicado antes del período de facturación para que aparezca en los datos de costos.

Los bloqueos de recursos protegen los recursos de Azure frente a eliminaciones o modificaciones accidentales, independientemente de los permisos de RBAC que tenga un usuario. Incluso un usuario con derechos de Owner o Contributor puede no tener permitido eliminar o modificar un recurso bloqueado. Los bloqueos se aplican en el nivel de recurso, grupo de recursos o suscripción, y se propagan hacia abajo: un bloqueo en un grupo de recursos protege todos los recursos que contiene.

Azure admite dos tipos de bloqueo. CanNotDelete (bloqueo de eliminación) permite a los usuarios leer y modificar el recurso, pero impide eliminarlo. Es el bloqueo más común: se aplica a bases de datos de producción, cuentas de almacenamiento y redes virtuales para evitar su eliminación accidental. ReadOnly impide todas las operaciones de escritura y eliminación, por lo que el recurso se comporta como si todos tuvieran asignado únicamente el rol Reader. ReadOnly es más restrictivo y puede interrumpir procesos automatizados que actualizan las propiedades de los recursos.

Para eliminar o modificar un recurso bloqueado, el usuario debe quitar primero el bloqueo, lo que requiere el permiso Microsoft.Authorization/locks/delete (disponible de forma predeterminada para los roles Owner y User Access Administrator). La eliminación del bloqueo, la modificación del recurso y la posible reaplicación del bloqueo se pueden incluir en un flujo de trabajo de administración de cambios, de modo que los recursos protegidos puedan modificarse mediante un proceso controlado con un registro de auditoría.

Un bloqueo aplicado en un ámbito principal (suscripción o grupo de recursos) es heredado por todos los recursos secundarios. No se puede anular un bloqueo en un ámbito inferior: si un grupo de recursos tiene un bloqueo CanNotDelete, no se pueden eliminar los recursos individuales que contiene, aunque no tengan un bloqueo aplicado directamente. Agregar un bloqueo CanNotDelete en el nivel del recurso además del bloqueo principal no cambia el comportamiento; el bloqueo principal ya proporciona la protección.

Los bloqueos ReadOnly pueden provocar errores inesperados en procesos automatizados. Algunas operaciones de Azure que parecen ser de solo lectura en la superficie requieren acceso de escritura a las propiedades de los recursos en segundo plano. Por ejemplo, un bloqueo ReadOnly impide enumerar las claves de acceso de una cuenta de almacenamiento porque esa acción modifica el registro de auditoría de la cuenta. También se bloquean el escalado de una máquina virtual, el reinicio de un App Service y la conexión de un disco a una máquina virtual en ejecución. Pruebe los bloqueos ReadOnly en entornos que no sean de producción antes de aplicarlos a recursos críticos.

La combinación de etiquetas y bloqueos crea un potente patrón de gobernanza. Puede usar una etiqueta como Protected=true para marcar los recursos que deberían tener bloqueos CanNotDelete y, después, ejecutar un Runbook de Azure Automation que busque los recursos con esa etiqueta y cree el bloqueo si falta. Este patrón de gobernanza autorreparable garantiza que, incluso si un administrador quita accidentalmente un bloqueo, este se vuelva a aplicar automáticamente según la programación del runbook.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que: las etiquetas de recursos son pares de metadatos de nombre y valor que permiten asignar costos, filtrar y automatizar operaciones en cualquier dimensión; las etiquetas no se heredan de los grupos de recursos principales y deben imponerse mediante Azure Policy; y los bloqueos de recursos (CanNotDelete y ReadOnly) protegen los recursos frente a cambios accidentales independientemente de los permisos de RBAC. A continuación, exploraremos Azure Blueprints para empaquetar artefactos de gobernanza.