Azure es una versátil plataforma en el cloud. Los clientes no solo pueden crear e implementar sus aplicaciones, sino también administrar y gestionar activamente sus entornos. Por lo general, el cloud sigue un paradigma de pago por uso, por el cual el cliente contrata una suscripción y, a continuación, puede implementar prácticamente cualquier cosa en el cloud. Puede tratarse de algo tan pequeño como una máquina virtual básica, o de miles de máquinas virtuales con referencias de almacén (SKU) de mayor tamaño. Azure no evitará que ningún cliente aprovisione los recursos que desea aprovisionar. En el seno de una organización, podría haber un gran número de personas con acceso a la suscripción de Azure de dicha organización. Es necesario tener implantado un modelo de gestión, de forma que las personas con derecho a crear recursos aprovisionen solo aquellos recursos necesarios. Azure proporciona características de administración de los recursos, como el control de accesos basado en roles de Azure (RBAC), Azure Policy, grupos de administración, planos técnicos y bloqueos de recursos para administrar y proporcionar una gestión de recursos.

Otros aspectos importantes de la gestión incluyen la administración de los costes, del
uso y de la información. El equipo de gerencia de una organización siempre quiere estar al
tanto de los costes y del consumo en el cloud. Probablemente desee identificar qué equipo,
departamento o unidad está utilizando qué porcentaje de su coste total. En resumen, quieren
tener informes basados en varias dimensiones del consumo y el coste. Azure ofrece una
función de etiquetado que puede ayudar a obtener este tipo de información sobre la marcha.
En este capítulo, abordaremos los siguientes temas:

• Grupos de administración de Azure
• Etiquetas de Azure
• Azure Policy
• Bloqueos de Azure
• Azure RBAC
• Azure Blueprints
• Implementación de características de gestión de Azure

Grupos de administración de Azure
Empezamos por los grupos de administración de Azure porque, en la mayoría de las próximas
secciones, haremos referencia a los grupos de administración o los mencionaremos. Los
grupos de administración actúan como un nivel de ámbito para que asignes o administres
eficazmente roles y políticas. Los grupos de administración son muy útiles si tienes varias
suscripciones.
Los grupos de administración actúan como marcador de posición para organizar las
suscripciones. También puedes tener grupos de administración anidados. Si aplicas una
política o acceso en el nivel de grupo de administración, los grupos de administración
y las suscripciones subyacentes lo heredarán. Desde el nivel de suscripción, esa política
o acceso lo heredarán los grupos de recursos y, finalmente, los recursos.
A continuación, se muestra la jerarquía de los grupos de administración:

En la Figura 5.1, utilizamos grupos de administración para separar las operaciones de los
diferentes departamentos, como marketing, TI y RR. HH. Dentro de cada uno de estos
departamentos, hay grupos de administración anidados y suscripciones, que ayudan a
organizar los recursos en una jerarquía para la administración de políticas y accesos. Más
adelante, verás cómo se utilizan los grupos de administración como ámbito para la gestión,
la administración de políticas y la administración de accesos.
En la siguiente sección, analizaremos las etiquetas de Azure, que desempeñan otro papel vital
en la agrupación lógica de recursos.

Etiquetas de Azure
Azure permite el etiquetado de grupos de recursos y recursos con pares nombre-valor.
El etiquetado contribuye a la organización lógica y a la categorización de los recursos. Azure
también permite el etiquetado de 50 pares de nombre-valor para un grupo de recursos y
sus recursos. Aunque un grupo de recursos actúa como contenedor o marcador de posición
para los recursos, el etiquetado de un grupo de recursos no implica etiquetar sus recursos
constituyentes. Los grupos de recursos y los recursos deben etiquetarse en función de su
uso, lo que se explicará más adelante en esta sección. Las etiquetas están vinculadas a una
suscripción, un grupo de recursos o un recurso. Azure acepta cualquier par de nombre-valor;
por eso es importante que la organización defina tanto los nombres como sus posibles valores.

Pero ¿por qué es importante el etiquetado? En otras palabras, ¿qué problemas se pueden
resolver mediante el etiquetado? El etiquetado tiene las siguientes ventajas:

• Categorización de recursos: una suscripción a Azure la pueden usar varios
  departamentos de una organización. Es importante que el equipo directivo identifique
  a los propietarios de los recursos. El etiquetado ayuda a asignar identificadores a los
  recursos que pueden usarse para representar a departamentos o funciones.
• Administración de información para recursos de Azure: como ya se ha dicho,
  cualquiera con acceso a la suscripción puede aprovisionar recursos de Azure. A las
  organizaciones les gusta tener implantada una correcta categorización de los recursos
  para cumplir con las políticas de administración de la información. Estas políticas se
  pueden basar en la administración del ciclo de vida de las aplicaciones, como es el caso
  de la administración de los entornos de desarrollo, pruebas y producción. También
  podrían basarse en el uso o en cualquier otra prioridad. Cada organización tiene su
  propia forma de definir las categorías de información y Azure lo hace posible gracias
  a las etiquetas.
• Administración de costes: el etiquetado en Azure puede ayudar a identificar los
  recursos basándose en su categorización. Se pueden ejecutar consultas en Azure
  para identificar, por ejemplo, el coste por categoría. Por ejemplo, se puede determinar
  fácilmente el coste de los recursos de Azure destinados al desarrollo de un entorno
  para el departamento de finanzas y el departamento de marketing. Por otra parte,
  Azure también proporciona información de facturación basándose en las etiquetas.
  Esto ayuda a identificar las tasas de consumo de equipos, departamentos o grupos.

Sin embargo, las etiquetas de Azure tienen ciertas limitaciones:

• Azure permite asociar un máximo de 50 pares de etiquetas de nombre-valor a grupos
  de recursos.
• Las etiquetas no son heredables. Las etiquetas aplicadas a un grupo de recursos no
  se aplican a los recursos individuales que hay dentro de él. Sin embargo, es bastante
  fácil olvidar etiquetar los recursos al aprovisionarlos. Azure Policy proporciona el
  mecanismo que se utiliza para garantizar que las etiquetas se etiquetan con el valor
  adecuado durante el aprovisionamiento. Tendremos en cuenta los detalles de estas
  políticas más adelante en este capítulo.

Las etiquetas pueden asignarse a recursos y grupos de recursos mediante PowerShell, Azure
CLI 2.0, las plantillas de Azure Resource Manager, Azure Portal y las API de REST de Azure
Resource Manager.
A continuación se muestra un ejemplo de categorización de administración de la información
con etiquetas de Azure:

En este ejemplo, se utilizan pares de nombre-valor de Departamento, Proyecto, Entorno,
Propietario, Aprobador, Mantenedor, Fecha de inicio, Fecha de retirada y Fecha de
aplicación de la revisión para etiquetar los recursos. Es muy fácil encontrar todos los
recursos para una etiqueta determinada o combinación de etiquetas con PowerShell,
Azure CLI o las API de REST. En la siguiente sección analizaremos formas de usar
PowerShell para asignar etiquetas a los recursos.

Etiquetas con PowerShell
Las etiquetas pueden administrarse utilizando PowerShell, las plantillas de Azure Resource
Manager, Azure Portal y las API de REST. En esta sección, se utilizará PowerShell para crear
y aplicar etiquetas. PowerShell proporciona un cmdlet para recuperar y asociar etiquetas a
grupos de recursos y recursos:

• Para recuperar etiquetas asociadas a un recurso con PowerShell, puede utilizarse
  el cmdlet Get-AzResource:
  (Get-AzResource -Tag @{ «Environment»=»Production»}).Name
• Para recuperar etiquetas asociadas a un grupo de recursos con PowerShell, puede
  utilizarse el siguiente comando:
  Get-AzResourceGroup -Tag @{«Environment»=»Production»}
• Para asignar etiquetas a un grupo de recursos, se puede usar el cmdlet Update-AzTag:
  $tags = @{«Dept»=»IT»; «Environment»=»Production»}
  $resourceGroup = Get-AzResourceGroup -Name demoGroup
  New-AzTag -ResourceId $resourceGroup.ResourceId -Tag $tags
• Para asignar etiquetas a un recurso, puede utilizarse el mismo cmdlet Update-AzTag:
  $tags = @{«Dept»=»Finance»; «Status»=»Normal»}
  $resource = Get-AzResource -Name demoStorage -ResourceGroup demoGroup
  New-AzTag -ResourceId $resource.id -Tag $tags
• Puedes actualizar las etiquetas existentes mediante el comando Update-AzTag; sin
  embargo, debes especificar la operación como Merge o Replace. Merge anexará las
  nuevas etiquetas que estás transfiriendo a las etiquetas existentes; sin embargo,
  la operación Replace reemplazará todas las etiquetas antiguas por las nuevas. A
  continuación se presenta un ejemplo de actualización de las etiquetas en un grupo
  de recursos sin reemplazar las existentes:
  $tags = @{«Dept»=»IT»; «Environment»=»Production»}
  $resourceGroup = Get-AzResourceGroup -Name demoGroup
  Update-AzTag -ResourceId $resourceGroup.ResourceId -Tag $tags -Operation
  Merge

Examinemos ahora las etiquetas con plantillas de Azure Resource Manager.
Etiquetas con plantillas de Azure Resource Manager
Las plantillas de Azure Resource Manager también ayudan a definir las etiquetas de cada
recurso. Pueden utilizarse para asignar varias etiquetas a cada recurso de la manera siguiente:

{
«$schema»: «https://schema.management.azure.com/schemas/2019-04-01/
deploymentTemplate.json#»,
«contentVersion»: «1.0.0.0»,
«resources»: [
{
«apiVersion»: «2019-06-01»,
«type»: «Microsoft.Storage/storageAccounts»,
«name»: «[concat(‘storage’, uniqueString(resourceGroup().id))]»,
«location»: «[resourceGroup().location]»,
«tags»: {
«Dept»: «Finance»,
«Environment»: «Production»
},
«sku»: {
«name»: «Standard_LRS»
},
«kind»: «Storage»,
«properties»: { }
}
]
}
En el ejemplo anterior, se agregaron un par de etiquetas, Departamento y Entorno, a un
recurso de cuenta de almacenamiento mediante plantillas de Azure Resource Manager.
Etiquetar grupos de recursos y recursos
Es fundamental que los arquitectos decidan la taxonomía y la arquitectura de la información
de los recursos y grupos de recursos de Azure. Estos deberían identificar las categorías en las
que se clasificarán los recursos según los requisitos de consulta. Sin embargo, también deben
identificar si las etiquetas deben asociarse a recursos individuales o a grupos de recursos.

Si todos los recursos de un grupo de recursos necesitan la misma etiqueta, es mejor
etiquetar el grupo de recursos, incluso si las etiquetas no heredan los recursos en el grupo
de recursos. Si tu organización requiere que las etiquetas se transfieran a todos los recursos
subyacentes, puedes plantearte la posibilidad de escribir un script de PowerShell para
obtener las etiquetas del grupo de recursos y actualizar las etiquetas de los recursos del
grupo de recursos. Es importante tener en cuenta las consultas sobre etiquetas antes de
decidir si estas etiquetas deben aplicarse en el nivel de los recursos o en el nivel del grupo
de recursos. Si las consultas se refieren a tipos de recursos individuales de una suscripción
y de distintos grupos de recursos, tendrá más sentido asignar las etiquetas a recursos
individuales. No obstante, si la identificación de los grupos de recursos es suficiente para que
las consultas tengan efecto, entonces las etiquetas deberían aplicarse únicamente a grupos
de recursos. Si trasladas recursos entre grupos de recursos, las etiquetas aplicadas en el nivel
de grupo de recursos se perderán. Si estás trasladando recursos, plantéate la posibilidad de
volver a agregar las etiquetas.
Azure Policy
En la sección anterior, hemos descrito la aplicación de etiquetas para implementaciones de
Azure. Las etiquetas son una excelente alternativa para organizar recursos. Sin embargo, hay
algo más de lo que no hemos hablado: ¿cómo pueden asegurarse las organizaciones de que
las etiquetas se apliquen a cada implementación? Debe haber una aplicación automatizada
de las etiquetas de Azure a los recursos y grupos de recursos. No hay ninguna comprobación
de Azure que garantice la aplicación de las etiquetas apropiadas a los recursos y grupos
de recursos. Esto no es exclusivo de las etiquetas, sino que se aplica a la configuración
de cualquier recurso en Azure. Por ejemplo, quizás desees restringir dónde se pueden
aprovisionar los recursos geográficamente (por ejemplo, solo en la región Este de EE. UU.).
Puede que a estas alturas ya hayas adivinado que esta sección trata acerca de la formulación
de un modelo de gestión en Azure. La gestión es un elemento importante en Azure porque
garantiza que todo aquel que acceda al entorno de Azure esté al tanto de las prioridades
y los procesos de la organización. También ayuda a controlar los costes. Esto facilita la
definición de las convenciones de la organización para administrar recursos.
Cada política puede crearse utilizando varias reglas, pudiendo aplicarse varias políticas a una
suscripción o grupo de recursos. En función de si se cumplen las reglas, las políticas pueden
ejecutar varias acciones. Una acción podría ser denegar una transacción en curso, auditar
una transacción (lo que significa escribirla en registros y permitir que finalice) o anexar
metadatos a una transacción en caso de estar ausente.
Las políticas podrían estar relacionadas con la convención de nomenclatura de los recursos,
el etiquetado de los recursos, los tipos de recursos que pueden aprovisionarse, la ubicación
de los recursos o cualquier combinación de estas.
Azure proporciona numerosas políticas integradas y es posible crear políticas personalizadas.
Hay un lenguaje de políticas basado en JSON que se puede utilizar para definir políticas
personalizadas.
Ahora que conoces la finalidad y el caso práctico de Azure Policy, vamos a hablar sobre las
políticas integradas, el lenguaje de las políticas y las políticas personalizadas.
Políticas integradas
Azure proporciona un servicio para la creación de políticas personalizadas; no obstante,
también proporciona una serie de políticas «out of the box» que pueden usarse con fines
de gestión. Estas políticas se refieren a ubicaciones permitidas, tipos de recursos permitidos
y etiquetas. Puedes encontrar más información sobre estas políticas integradas en https://
docs.microsoft.com/azure/azure-resource-manager/resource-manager-policy.
Lenguaje de las políticas
Las políticas de Azure utilizan JSON para definir y describir las políticas. Hay dos pasos
en la adopción de una política. La política debe definirse y, a continuación, debe aplicarse
y asignarse. Las políticas tienen un ámbito y pueden aplicarse en el nivel de grupo de
administración, suscripción o grupo de recursos.
Las políticas se definen utilizando bloques if…then, del mismo modo que cualquier lenguaje
de programación popular. El bloque if se ejecuta para evaluar las condiciones y, según los
resultados de esas condiciones, se ejecuta el bloque then:
{
«if»: {
|
},
«then»: {
«effect»: «deny | audit | append»
}
}
Las políticas de Azure no solo permiten condiciones if sencillas, sino que también permiten
unir varias condiciones if de forma lógica para crear reglas complejas. Estas condiciones
pueden unirse con operadores AND, OR y NOT.

• La sintaxis AND requiere que todas las condiciones sean verdaderas.
• La sintaxis OR requiere que una de las condiciones sea verdadera.
• La sintaxis NOT invierte el resultado de la condición.

A continuación, se muestra la sintaxis AND. Está representada por la palabra clave allOf:
«if»: {
«allOf»: [
{
«field»: «tags»,
«containsKey»: «application»
},
{
«field»: «type»,
«equals»: «Microsoft.Storage/storageAccounts»
}
]
},
A continuación, se muestra la sintaxis OR. Está representada por la palabra clave anyOf:
«if»: {
«anyOf»: [
{
«field»: «tags»,
«containsKey»: «application»
},
{
«field»: «type»,
«equals»: «Microsoft.Storage/storageAccounts»
}
]
},
A continuación, se muestra la sintaxis NOT. Está representada por la palabra clave not:
«if»: {
«not»: [
{
«field»: «tags»,
«containsKey»: «application»
},
{
«field»: «type»,
«equals»: «Microsoft.Storage/storageAccounts»
}
]
},
De hecho, estos operadores lógicos pueden combinarse entre sí de la manera siguiente:
«if»: {
«allOf»: [
{
«not»: {
«field»: «tags»,
«containsKey»: «application»
}
},
{
«field»: «type»,
«equals»: «Microsoft.Storage/storageAccounts»
}
]
},
Esto se parece mucho al uso de las condiciones if en lenguajes de programación populares,
como C# y Node.js:
If («type» == «Microsoft.Storage/storageAccounts») {
Deny
}
Es importante mencionar que no hay acción allow, aunque sí hay una acción Deny. Esto
significa que las reglas de políticas deben escribirse teniendo en mente la posibilidad de
denegación. Las reglas deben evaluar las condiciones y aplicar la acción Deny para denegar
la acción si se cumplen las condiciones.

Campos permitidos
Los campos permitidos en las condiciones al definir políticas son los siguientes:

• Name: el nombre del recurso al que se aplica la política. Este campo es muy específico
  y se puede aplicar a un recurso por su uso.
• Type: tipo de recurso, como Microsoft.Compute/VirtualMachines. Este valor aplicaría
  la política a todas las instancias de máquinas virtuales, por ejemplo.
• Location: la ubicación (es decir, la región de Azure) de un recurso.
• Tags: las etiquetas asociadas a un recurso.
• Property aliases: propiedades específicas del recurso. Estas propiedades son
  diferentes para diferentes recursos.

En la siguiente sección, aprenderás más sobre la protección de recursos en entornos
de producción.
Bloqueos de Azure
Los bloqueos son mecanismos que permiten detener ciertas actividades en los recursos.
RBAC proporciona derechos a usuarios, grupos y aplicaciones dentro de un determinado
alcance. Hay roles RBAC «out of the box», como propietario, colaborador y lector. Con el rol
de colaborador, es posible eliminar o modificar un recurso. ¿Cómo pueden evitarse este
tipo de actividades a pesar de que el usuario tenga un rol de colaborador? Presentamos los
bloqueos de Azure.
Los bloqueos de Azure pueden ayudar de dos maneras:

• Pueden bloquear recursos para que no puedan eliminarse, incluso si se tiene acceso
  de propietario.
• Pueden bloquear recursos para que no pueda eliminarse ni modificarse su
  configuración.

Por lo general, los bloqueos resultan muy útiles para los recursos de entornos de producción
que no deban modificarse ni eliminarse accidentalmente.
Los bloqueos se pueden aplicar en los niveles de suscripción, grupo de recursos, grupo de
administración y recursos individuales. Los bloqueos pueden heredarse entre suscripciones,
grupos de recursos y recursos. Aplicar un bloqueo en el nivel principal garantizará que
aquellos recursos en el nivel secundario también lo hereden. Los recursos que se agregan
más adelante en el ámbito secundario también heredan la configuración de bloqueo de forma
predeterminada. Aplicar un bloqueo a un recurso también evitará que se elimine el grupo de
recursos que contenga el recurso.
Los bloqueos se aplican solo a las operaciones que ayudan a la administración de un recurso
y no a las operaciones que son internas del recurso. Los usuarios necesitan permisos RBAC
Microsoft.Authorization/* o Microsoft.Authorization/locks/* para crear y modificar
bloqueos.
Se pueden crear y aplicar bloqueos a través de Azure Portal, de Azure PowerShell, de la CLI
de Azure, de las plantillas de Azure Resource Manager y de las API de REST.
Para crear un bloqueo utilizando una plantilla de Azure Resource Manager, es preciso hacer
lo siguiente:
{
«$schema»: «https://schema.management.azure.com/schemas/2015-01-01/
deploymentTemplate.json#»,
«contentVersion»: «1.0.0.0»,
«parameters»: {
«lockedResource»: {
«type»: «string»
}
},
«resources»: [
{
«name»: «[concat(parameters(‘lockedResource’), ‘/Microsoft.
Authorization/myLock’)]»,
«type»: «Microsoft.Storage/storageAccounts/providers/locks»,
«apiVersion»: «2019-06-01»,
«properties»: {
«level»: «CannotDelete»
}
}
]
}
La sección resources del código de plantilla de Azure Resource Manager consta de una
lista de todos los recursos que se aprovisionarán o actualizarán dentro de Azure. Hay un
recurso de cuenta de almacenamiento y la cuenta de almacenamiento tiene un recurso de
bloqueo. Se proporciona un nombre para el bloqueo mediante la concatenación dinámica
de cadenas y el bloqueo que se aplica es del tipo CannotDelete, lo que significa que la cuenta
de almacenamiento está bloqueada en cuanto a eliminación. La cuenta de almacenamiento
solo se puede eliminar después de eliminar el bloqueo.
Para crear y aplicar un bloqueo a un recurso utilizando PowerShell, es preciso hacer lo siguiente:
New-AzResourceLock -LockLevel CanNotDelete -LockName LockSite ‘
-ResourceName examplesite -ResourceType Microsoft.Web/sites ‘
-ResourceGroupName exampleresourcegroup
Para crear y aplicar un bloqueo a un grupo de recursos utilizando PowerShell, es preciso
hacer lo siguiente:
New-AzResourceLock -LockName LockGroup -LockLevel CanNotDelete ‘
-ResourceGroupName exampleresourcegroup
Para crear y aplicar un bloqueo a un recurso utilizando la CLI de Azure, es preciso hacer
lo siguiente:
az lock create –name LockSite –lock-type CanNotDelete \
–resource-group exampleresourcegroup –resource-name examplesite \
–resource-type Microsoft.Web/sites
Para crear y aplicar un bloqueo a un grupo de recursos utilizando Azure CLI, es preciso hacer
lo siguiente:
az lock create –name LockGroup –lock-type CanNotDelete \ –resource-group
exampleresourcegroup
Para crear o eliminar bloqueos de recursos, el usuario debe tener acceso a las acciones
Microsoft.Authorization/* o Microsoft.Authorization/locks/. También puedes conceder permisos granulares. Los propietarios y los administradores de accesos de usuarios tendrán acceso a la creación o eliminación de bloqueos de forma predeterminada. Si te preguntas qué son las palabras clave Microsoft.Authorization/ y Microsoft.
Authorization/locks/*, en la siguiente sección aprenderás más sobre estas palabras.
Examinemos ahora Azure RBAC.
Azure RBAC
Azure proporciona autenticación utilizando Azure Active Directory para sus recursos.
Una vez que se ha autenticado una identidad, se deberá decidir a qué recursos tendrá
permitido el acceso dicha identidad. Esto se conoce como autorización. La autorización
evalúa los permisos que se han concedido a una identidad. Cualquiera con acceso a una
suscripción de Azure debe tener concedidos únicamente los permisos suficientes para
poder desempeñar su trabajo; nada más.

RBAC ayuda a la creación y asignación de diferentes permisos a diferentes identidades.
Esto ayuda a segregar las funciones en el seno de los equipos, en lugar de que todos los
miembros tengan todos los permisos. RBAC contribuye a que cada persona se responsabilice
únicamente de su trabajo, ya que puede que otros ni siquiera tengan el acceso necesario
para hacerlo. Cabe señalar que proporcionar permisos de un alcance superior garantiza
automáticamente que los recursos secundarios hereden dichos permisos. Por ejemplo,
proporcionar a una identidad acceso de lectura a un grupo de recursos significa que
dicha identidad también tendrá acceso de lectura a todos los recursos del grupo.
Azure proporciona tres roles integrados de propósito general. Son los siguientes:

• El rol de propietario, que tiene pleno acceso a todos los recursos.
• El rol de colaborador, que tiene acceso a recursos de lectura y escritura.
• El rol de lector, que tiene permisos solo de lectura en los recursos.
  Azure proporciona más roles, pero son específicos de los recursos, como los roles
  de colaborador de red y de administrador de seguridad.
  Para obtener todos los roles proporcionados por Azure para todos los recursos, ejecuta
  el comando Get-AzRoleDefinition en la consola de PowerShell.
  Cada definición de rol tiene determinadas acciones permitidas y no permitidas. Por ejemplo,
  el rol de propietario tiene todas las acciones permitidas y ninguna acción prohibida:
  PS C:\Users\riskaria> Get-AzRoleDefinition -Name «Propietario»
  Name : Propietario
  Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
  IsCustom : False
  Description : te permite administrarlo todo, incluido el acceso a los
  recursos.
  Actions : {*}
  NotActions : {}
  DataActions : {}
  NotDataActions : {}
  AssignableScopes : {/}
  Cada rol consta de varios permisos. Cada recurso proporciona una lista de operaciones. Las
  operaciones que admite un recurso pueden obtenerse con el cmdlet Get-AzProviderOperation.
  Este cmdlet toma el nombre del proveedor y el recurso para recuperar las operaciones:

La autorización se conoce comúnmente como RBAC. En Azure, RBAC se refiere a la asignación
de permisos a las identidades dentro de un determinado alcance. El ámbito puede ser un
grupo de administración, una suscripción, un grupo de recursos o recursos individuales.

PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString
«Microsoft.Insights/» | select Operation Esto se traducirá en el resultado siguiente: PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString «Microsoft.Insights/» | select Operation

Operation

Microsoft.Insights/Metrics/Action
Microsoft.Insights/Register/Action
Microsoft.Insights/Unregister/Action
Microsoft.Insights/ListMigrationDate/Action
Microsoft.Insights/MigrateToNewpricingModel/Action
Microsoft.Insights/RollbackToLegacyPricingModel/Action
.
.
.
.
.
.
.
.
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Read
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Write
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Delete
Microsoft.Insights/PrivateLinkScopeOperationStatuses/Read
Microsoft.Insights/DiagnosticSettingsCategories/Read
El resultado que se muestra aquí proporciona todas las acciones disponibles en el proveedor
de recursos Microsoft.Insights en todos sus recursos asociados. Los recursos incluyen
Metrics, Register y otros, mientras que las acciones incluyen Read, Write y otras.
Examinemos ahora los roles personalizados.

Roles personalizados
Azure proporciona numerosos roles genéricos «out of the box», como propietario, colaborador
y lector, así como roles especializados específicos de recursos, como colaborador de la
máquina virtual. Tener un rol de lector asignado a un usuario/grupo o entidad de servicio
implicará la asignación de permisos de lector al ámbito. El ámbito puede ser un recurso, un
grupo de recursos o una suscripción. Del mismo modo, un colaborador podrá leer y modificar
el ámbito asignado. Un colaborador de la máquina virtual podría modificar la configuración de
la máquina virtual y no la configuración de ningún otro recurso. Sin embargo, hay ocasiones
en las que los roles existentes podrían no satisfacer nuestros requisitos. En estos casos, Azure
permite la creación de roles personalizados. Pueden asignarse a usuarios, grupos y entidades
de servicio y son aplicables a recursos, grupos de recursos y suscripciones.
Los roles personalizados se crean mediante la combinación de varios permisos. Por ejemplo,
un rol personalizado puede constar de operaciones de múltiples recursos. En el siguiente
bloque de código, se creará una nueva definición de rol, pero en lugar de establecer
todas las propiedades manualmente, se recupera uno de los roles de «Virtual Machine
Contributor» (Colaborador de la máquina virtual) existentes porque casi coincide con
la configuración del nuevo rol personalizado. No utilices el mismo nombre que los roles
integrados, ya que eso crearía conflicto. A continuación, se anula la propiedad ID y se
proporciona un nuevo nombre y descripción. El código también elimina todas las acciones,
agrega algunas acciones, agrega un nuevo ámbito después de borrar el ámbito existente y,
por último, crea un nuevo rol personalizado:
$role = Get-AzRoleDefinition «Virtual Machine Contributor»
$role.Id = $null
$role.Name = «Virtual Machine Operator»
$role.Description = «Can monitor and restart virtual machines.»
$role.Actions.Clear()
$role.Actions.Add(«Microsoft.Storage//read») $role.Actions.Add(«Microsoft.Network//read»)
$role.Actions.Add(«Microsoft.Compute//read») $role.Actions.Add(«Microsoft.Compute/virtualMachines/start/action») $role.Actions.Add(«Microsoft.Compute/virtualMachines/restart/action») $role.Actions.Add(«Microsoft.Authorization//read»)
$role.Actions.Add(«Microsoft.Resources/subscriptions/resourceGroups/read»)
$role.Actions.Add(«Microsoft.Insights/alertRules/») $role.Actions.Add(«Microsoft.Support/»)
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add(«/subscriptions/548f7d26-b5b1-468e-ad45-6ee12accf7e7″)
New-AzRoleDefinition -Role $role
Hay una característica en versión preview disponible en Azure Portal que puedes utilizar
para crear roles RBAC personalizados desde el propio Azure Portal. Tienes la opción de
crear roles desde cero, clonar un rol existente o empezar a escribir el manifiesto JSON.
En la Figura 5.3 se muestra la hoja Crear rol personalizado (Create a custom role), que está
disponible en la sección IAM > +Agregar (+Add):

Esto facilita el proceso de creación de roles personalizados.
¿En qué se diferencian los bloqueos de RBAC?
Los bloqueos no son iguales que en RBAC. RBAC ayuda a permitir o denegar permisos para
los recursos. Estos permisos tienen que ver con la realización de operaciones tales como
lectura, escritura y actualización de los recursos. Los bloqueos, por otra parte, se refieren
a la anulación de permisos para configurar o eliminar recursos.
En la siguiente sección, analizaremos Azure Blueprints, que nos ayuda con la organización
de artefactos, como asignaciones de roles, asignaciones de políticas y mucho más, que
hemos descrito hasta ahora.
Azure Blueprints
Estarás familiarizado con la palabra «plano técnico», que hace referencia al plan o al diseño que
utiliza un arquitecto para diseñar una solución. Del mismo modo, en Azure, los arquitectos del
cloud pueden aprovechar Azure Blueprints para definir un conjunto de recursos repetibles de
Azure que se adhiera a los estándares, procesos y patrones de una organización.
Blueprints nos permite organizar la implementación de varios recursos y otros artefactos, como:

• Asignaciones de roles
• Asignaciones de políticas
• Plantillas de Azure Resource Manager
• Grupos de recursos

Los objetos de plano técnico de Azure se replican en varias regiones y están respaldados
por Azure Cosmos DB. La replicación ayuda a proporcionar acceso uniforme a los recursos
y a mantener los estándares de la organización, independientemente de la región en la que
estés implementando.
Azure Blueprints consta de varios artefactos y a continuación puedes encontrar la lista
de artefactos admitidos: https://docs.microsoft.com/azure/governance/blueprints/
overview#blueprint-definition
Los planos técnicos se pueden crear desde Azure Portal, Azure PowerShell, la CLI de Azure,
las API de REST o las plantillas de ARM.
En la siguiente sección, examinaremos un ejemplo de implementación de las características
de gestión de Azure. En el ejemplo, se utilizarán servicios y características como RBAC, Azure
Policy y bloqueos de recursos de Azure.
Ejemplo de implementación de características de gestión de Azure
En esta sección, veremos un ejemplo de implementación de arquitectura para una
organización ficticia que quiere implementar las características de gestión y administración
de costes de Azure.
Contexto
Empresa, Inc es una empresa internacional que está implementando una solución de redes
sociales en una plataforma de IaaS de Azure. Utiliza servidores web y servidores de aplicaciones
implementados en máquinas virtuales y redes de Azure. Azure SQL Server actúa como base de
datos de back-end.
RBAC para Empresa, Inc
La primera tarea es garantizar que los equipos apropiados y los propietarios de la aplicación
pueden acceder a sus recursos. Se considera que cada equipo tiene requisitos diferentes.
En aras de la claridad, Azure SQL se implementa en un grupo de recursos independiente
respecto de los artefactos de IaaS de Azure.
El administrador asigna los siguientes roles para la suscripción:

Azure Policy
La empresa debería implementar Azure Policy para asegurarse de que sus usuarios
siempre aprovisionen los recursos de conformidad con las directrices de la empresa.
Las políticas de Azure rigen diversos aspectos relacionados con el desarrollo de los recursos.
Las políticas también regirán las actualizaciones después de la implementación inicial. En la
siguiente sección se explican algunas de las políticas que se deben implementar.
Implementaciones en determinadas ubicaciones
Los recursos e implementaciones de Azure solo pueden ejecutarse en determinadas
ubicaciones seleccionadas. No sería posible implementar recursos en regiones no incluidas
en la política. Por ejemplo, las regiones permitidas son Europa occidental y este de EE. UU.
No debería ser posible implementar recursos en ninguna otra región.
Etiquetas de recursos y grupos de recursos
Todos los recursos de Azure, incluidos los grupos de recursos, deberán tener etiquetas
asignadas obligatoriamente. Las etiquetas incluirán, como mínimo, detalles sobre
el departamento, el entorno, los datos de creación y el nombre del proyecto.
Registros de diagnóstico y Application Insights para todos los recursos
Todos los recursos implementados en Azure deben tener los registros de diagnóstico
y registros de aplicaciones habilitados siempre que sea posible.

Bloqueos de Azure
Una empresa debe implementar bloqueos de Azure para garantizar que los recursos
importantes no se eliminen accidentalmente. Todos los recursos que son importantes para
el funcionamiento de una solución deben estar bloqueados. Esto significa que ni siquiera los
administradores de los servicios que se ejecutan en Azure tienen la capacidad de eliminar
estos recursos; la única manera de eliminar un recurso es quitar primero el bloqueo.
También debes tener en cuenta que:
Todos los entornos de producción y preproducción, aparte de los entornos de desarrollo
y pruebas, estarán bloqueados en cuanto a eliminación.
Todos los entornos de desarrollo y pruebas que tengan instancias únicas también
se bloquearían en cuanto a eliminación.
Todos los recursos relacionados con la aplicación web estarán bloqueados en cuanto
a eliminación para todos los entornos de producción.
Todos los recursos compartidos estarán bloqueados en cuanto a eliminación, con
independencia del entorno.
Resumen
En este capítulo, has aprendido que la gestión y la administración de costes son unas de las
máximas prioridades para las empresas que migran al cloud. Tener una suscripción a Azure
con un plan de pago por uso puede ser perjudicial para el presupuesto de la empresa, ya
que cualquiera con acceso a la suscripción puede aprovisionar tantos recursos como desee.
Algunos recursos son gratuitos, pero otros son costosos.
También has aprendido que es importante que las organizaciones conserven el control
de sus costes en el cloud. Las etiquetas ayudan a generar informes de facturación. Estos
informes pueden generarse por departamento, proyecto, propietario o cualquier otro
criterio. Aunque el coste es importante, la gestión es igualmente importante. Azure ofrece
bloqueos, políticas y RBAC para implementar una gestión apropiada. Las políticas garantizan
que las operaciones con recursos puedan denegarse o auditarse, los bloqueos garantizan
que los recursos no puedan modificarse ni eliminarse, y RBAC garantiza que los empleados
tengan los permisos necesarios para poder desempeñar sus trabajos. Estas características
permiten a las empresas aplicar una gestión y un control de costes eficaces en sus
implementaciones de Azure.
En el próximo capítulo, explicaremos la administración de costes en Azure. Examinaremos
los diferentes métodos de optimización, administración de costes y API de facturación.