Terraform desde las Trincheras (Buena práctica ‘Protección de valores que contienen información de seguridad’)

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 quinta 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’).
3. Terraform desde las Trincheras (Buena práctica ‘Uso de service principal’).
4. Terraform desde las Trincheras (Buena práctica ‘Uso de módulos’).

Protección de valores que contienen información de seguridad

Como parte del aprovisionamiento de la infraestructura cloud nos encontramos con el escenario de proteger datos o valores que no deben ser compartidos ni de fácil acceso por terceras personas y en Terraform existen formas de resolver ese problema que se recomienda que se apliquen en un orden determinado tal como se explicará en las siguientes secciones.

Uso de remote state

Por defecto cada vez que ejecutamos los comandos de Terraform se generan carpetas y archivos con la metadata del estado de la infraestructura cloud aprovisionada y que se va actualizando con cada cambio que hacemos en el código Terraform y después de la ejecución de los comandos. Dicho estado se recomienda que se guarde de forma remota usando un Storage Account en Azure con encriptación en reposo para BLOB donde se tendrá un contenedor exclusivo para ello. Este recurso cloud se recomienda que sea exclusivo para el remote state de Terraform, debería existir uno por suscripción y se puede crear de forma manual a través del Portal Azure o a través de comando de Azure CLI. Los datos más importantes para configurarlo en la sección backend son:

• Nombre del Resource Group donde está el Storage Account.
• Nombre del Storage Account.
• Nombre del Contenedor dentro del Storage Account.

Existe un dato más que es el identificador del remote state que recién se define cuando se agrega el cambio en el código Terraform en la sección backend y los 4 datos se pueden observar en el siguiente ejemplo:

terraform {
  backend "azurerm" {
    resource_group_name  = "NOMBRE_DE_RESOURCE_GROUP"
    storage_account_name = "NOMBRE_DE_STORAGE_ACCOUNT_DENTRO_DE_RESOURCE_GROUP"
    container_name       = "NOMBRE_DE_CONTAINER_DENTRO_DE_STORAGE_ACCOUNT"
    key                  = "IDENTIFICADOR_DE_REMOTE_STATE"
  }
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.24.0"
    }
  }
}

Luego que se agrega la sección backend se tiene que ejecutar el comando terraform init y después de ello podemos borrar las carpetas y archivos de metadatos creados localmente en nuestro ordenador.

Con este cambio toda la metadata del estado de la infraestructura cloud aprovisionada estará centralizada en un solo lugar con un control de acceso restringido donde sólo el Service Principal o el usuario con el rol Contributor sobre el Storage Account del remote state de Terraform podrá administrarlo a pesar de que dicho Storage Account tenga su endpoint de acceso público.

Uso de atributo sensitive en variables

Las variables que tengan datos o valores que contienen información de seguridad, además de protegerlas cuando se guardan en el remote state de Terraform, también tienen que protegerse cuando se ingresan sus datos o valores por primera vez o cuando se actualizan. Para ello se recomienda agregar la sección de código Terraform sensitive = true al momento de declarar las variables y para los datos o valores que contienen información de seguridad se puede usar 3 alternativas:

• Una alternativa es guardar los datos o valores en un archivo aparte como por ejemplo secrets.tfvars y cuando ejecutemos los comandos de Terraform compartirlo como un parámetro más, es decir, -var-file="secret.tfvars".
• Otra alternativa es declarar variables de entorno en el terminal donde se ejecutarán los comandos de Terraform que tengan el formato TF_VAR_<NOMBRE_DE_VARIABLE>; por ejemplo, para Linux seria export TF_VAR_otp=abc123, y para Windows sería set "TF_VAR_otp=abc123".
• También se puede ingresar los datos o valores luego que ejecutemos los comandos de Terraform, pues al no usar un archivo .tfvars o variables de entorno que inicien con TF_VAR_ aparecerá en el terminal de Linux o Windows la opción de ingresar la información para las variables que tengan datos o valores que contienen información de seguridad.

Dependiendo de la importancia sobre la información de seguridad que tendrá cada variable se puede usar algunas de las alternativas anteriores. También se debe tomar en cuenta que las 2 primeras puede generar un log de ejecución de comandos como parte del histórico del terminal de Linux o Windows.

En la siguiente imagen se muestra como aparece en los logs de Terraform luego de ejecutar los comandos y usar el atributo sensitive:

En el siguiente enlace existe más información sobre este tema: Protect Sensitive Input Variables.

Uso de herramienta vault

Otra forma de administrar el registro y actualización de las variables con datos o valores que contienen información de seguridad es usar vault donde lo básico es tenerlo instalado localmente, y existen diferentes opciones dependiendo del sistema operativo que se detalla en el siguiente enlace: Install Vault.

Luego de tenerlo instalado localmente ejecutamos en un terminal el siguiente comando vault server -dev y en la siguiente imagen se ve el resultado:

Al final de todos los logs se mostrará un token que debemos copiar para los comandos posteriores de interacción con el vault, pues es el root que tiene permisos de administración.

En un nuevo terminal se configurar las variables de entorno para acceder al vault, para Linux son export VAULT_ADDR=http://127.0.0.1:8200 y export VAULT_TOKEN=<AQUI_VA_TOKEN_ROOT>; y para Windows son set VAULT_ADDR=http://127.0.0.1:8200 y set VAULT_TOKEN=<AQUI_VA_TOKEN_ROOT>. Después ejecutamos el comando vault kv put -mount=secret <IDENTIFICADOR_REFERENCIAL_PROYECTO_TERRAFORM> @<NOMBRE_DE_ARCHIVO_CON_VARIABLE>.json para registrar o actualizar las variables con datos o valores que contienen información de seguridad. El archivo .json debe tener el formato JSON y solo existirá de forma local en el ordenador.

Para integrar la información registrada en el vault con nuestro código Terraform del aprovisionamiento de la infraestructura cloud se tiene agregar un nuevo provider que es vault como se muestra a continuación donde se usa la información de las variables de entorno del párrafo anterior:

terraform {
  required_providers {
    vault = {
      source  = "hashicorp/vault"
      version = "~> 3.0.0"
    }
  }
}

provider "vault" {
  address = "http://127.0.0.1:8200"
  token   = "TOKEN_ROOT_PARA_ADMINISTRAR_VAULT"
}

Luego tenemos que indicar el tipo de autenticación que se tendrá con el vault donde por defecto es token/ como se muestra a continuación donde se busca dicho tipo en vez de crear uno nuevo:

data "vault_auth_backend" "token" {
  path = "token/"
}

Después tenemos que usar el identificador referencial (que se definió con el comando vault kv put) agregándole el prefijo secret/ antes de establecer el valor para el atributo path del código Terraform data "vault_generic_secret", y luego ya podemos usar cualquier información almacenada en vault para que se sea asignada en tiempo de ejecución a las variables con datos o valores que contienen información de seguridad.

El uso de la herramienta vault prepara nuestro código Terraform para integrarlo en un flujo automatizado de GitOps y todo lo que se almacene ahí no estará en el repositorio de código fuente de Terraform.

En el siguiente artículo explicaremos la buena práctica de IaC con Terraform llamada «Ingeniería inversa».