Terraform desde las Trincheras (Buena práctica ‘Uso de service principal’)

Continuando con las buenas prácticas de IaC con Terraform (que hemos podido utilizar en nuestros proyectos de Azure esperando que faciliten una curva de aprendizaje para aquellos que aún no las aplican y que también están referenciadas en Internet donde existe bastante información de calidad sobre ello) revisaremos la tercera parte de esta serie de artículos:

1. Terraform desde las Trincheras (Buena práctica ‘Agrupación de capas lógicas’).
2. Terraform desde las Trincheras (Buena práctica ‘Definición de nomenclatura’).

Uso de Service Principal

La forma predeterminada de ejecutar los comandos Terraform es usando una cuenta personal que tenga los permisos para la creación, eliminación y actualización de recursos cloud en Azure y el comando para ello es el az login (que lanza el navegador web predeterminado para que se ingrese las credenciales de la cuenta Azure). Adicionalmente si la cuenta personal en Azure tiene más de una suscripción, antes de ejecutar los comandos Terraform se tiene que establecer la suscripción por defecto con el comando az account set.

Todo lo anterior genera una interacción que no permite aprovisionar los recursos cloud de la Arquitectura en una forma automatizada y para resolver ello, el uso de Service Principal (aplicación dentro del Azure Active Directory cuyos tokens de autenticación pueden ser usados por Terraform) es la solución.

Para agregar en el código Terraform el uso de Service Principal, tenemos que hacer 2 pasos:

1. Crear Service Principal en Azure.
2. Modificar archivo main en código Terraform.

Creación de Service Principal en Azure

Para realizar esta tarea una forma muy común es usando el comando az ad sp create-for-rbac donde se le tiene que indicar el nombre del Service Principal, el rol asociado al Service Principal y la suscripción (o las suscripciones) a las que tendrá acceso el Service Principal. Un ejemplo de ello se puede observar a continuación:

az ad sp create-for-rbac --display-name="sp-terraform" --role="Contributor" --scopes "/subscriptions/AQUI-VA-ID-SUSCRIPCION-1" "/subscriptions/AQUI-VA-ID-SUSCRIPCION-2" "/subscriptions/AQUI-VA-ID-SUSCRIPCION-3"

El resultado luego de ejecutar el comando anterior son 4 datos que se usarán en el código Terraform y un ejemplo de ello se muestra en la siguiente imagen:

Modificación de archivo main en código Terraform

En el archivo main de la capa lógica donde realizaremos el cambio se tiene que modificar la sección provider y agregar 2 atributos nuevos (client_id y client_secret) como se puede observar a continuación:

provider "azurerm" {
  subscription_id            = var.SubscriptionId
  client_id                  = var.ClientId
  client_secret              = var.ClientSecret
  tenant_id                  = var.TenantId
  skip_provider_registration = false
  features {}
}

El client_id debe tener el valor del dato appId luego de ejecutar el comando az ad sp create-for-rbac; y lo mismo para con el client_secret que debe tener el valor del dato password. Luego del cambio cada vez que se ejecuten los comandos Terraform se tomará en cuenta las credenciales del Service Principal para validar el acceso y la autorización asociados sin necesidad de alguna interacción manual.

Si se requiere más información sobre esta buena práctica se puede revisar el siguiente artículo:

• Azure Provider: Authenticating using a Service Principal with a Client Secret.

Un punto importante también a mencionar sobre el uso de Service Principal, es que si ya se viene usando en el código Terraform, entonces cuando se intenta escalar el aprovisionamiento de la Arquitectura Cloud con GitOps costará menos implementarlo.

En el siguiente artículo explicaremos la buena práctica de IaC con Terraform llamada «Uso de módulos».