Todos los proyectos

TerraformAzure-AD_DS_Automation

Creación automatizada de una máquina virtual "Windows Server 2019" y "Active Directory Domain Services" (configuración automatizada)

En este proyecto forma automatizada esta máquina virtual, y tras la creación de la máquina virtual, se iniciará y ejecutará un script de PowerShell que configurará nuestro Active Directory, DNS y bosque. Una vez que hagamos el login, mediante una tarea programada en PoweShell, ejecutará un segundo script que acabará de configurar la máquina (unidad organizativa, GPOs y alta de usuarios automatizada en el dominio). Esto mediante un token SAS, almacenado en Key Vault, que permitirá a la identidad administrada de la máquina virtual acceder al contenedor de la cuenta de almacenamiento y descargar los scripts necesarios para la configuración.

Explicación:

Consejos:

Todo lo descrito a continuación se realiza en TERRAFORM. Aunque Terraform aplica los recursos en paralelo, he estructurado esta exposición de forma secuencial para mayor claridad.

Estructura de Recursos

Todo comienza con la definición de un Resource Group, que actúa como contenedor de todos los elementos del proyecto. Dentro de este grupo, se crea una VNet y una subnet para alojar nuestra máquina virtual principal (VM).

Acceso Seguro con Azure Bastion

Para evitar exposiciones innecesarias como puertos abiertos al exterior, implementé Azure Bastion. Esta solución requiere dos recursos adicionales:

• Una subred específica llamada AzureBastionSubnet

• Una IP pública estática

De esta manera, podemos conectarnos de forma segura a la VM sin abrir el puerto RDP al mundo.

Reglas de NSG

Para reforzar la seguridad, asocié un Network Security Group (NSG) a la NIC (Network Interface Card) de la VM a la cual asignamos una IP privada estática. Este NSG contiene:

• Entradas:

  • Permitir tráfico desdela subred de Bastion a la vnet donde se encuentra la VM por el puerto 3389 (RDP)

  • Denegar todo el resto de tráfico entrante

• Salidas:

  • Permitir tráfico desde la vnet donde se encuentra la VM a la cuenta de Azure Storage por el puerto 443 (HTTPS)

  • Denegar cualquier otra salida

Con estas reglas, se garantiza un flujo restringido: Bastion → VM → Storage.

Automatización con Custom Script Extension

Creamos la máquina virtual y definimos dentro de ella la creación de una extensión llamada "CustomScriptExtension", que permite ejecutar scripts automáticamente tras el despliegue. Para ello, almacené los scripts en una cuenta de Azure Storage. Esta cuenta incluye:

• Un contenedor

• Dos blobs: ad_setup.ps1 y post_ad_setup.ps1

Gestión de secretos con Key Vault

Para que la VM pueda descargar los scripts desde Storage, creé un Azure Key Vault donde almacené un token SAS (Shared Access Signature).

A nivel de permisos:

• Asigne a la identidad que implementa en Terraform (a mi mismo) el rol "Key Vault Administrator" para poder generar el token

• Le asigné a la VM el rol "Key Vault Secrets User" para poder utilizarlo

Secuencia de Scripts

Usé dos scripts por una razón clave: la configuración de Active Directory requiere reiniciar la VM.

• ad_setup.ps1 configura el AD, DNS y bosque, además de dejar programada una tarea para el siguiente inicio

• post_ad_setup.ps1 finaliza la configuración: OU, GPOs y alta de usuarios

Gracias a esta secuencia, una vez iniciada la VM ya contamos con un entorno completo de AD funcional y preconfigurado.

• Usa Azure Bastion siempre que puedas: Aporta acceso seguro a la VM sin exponer el puerto RDP (3389) al exterior. La conexión se realiza por HTTPS (443) a través de un túnel gestionado por Azure.

• Nombrado correcto de la subnet de Bastion: La subred debe llamarse AzureBastionSubnet. Se recomienda un mínimo de /27 para evitar errores al desplegar el recurso.

• Define reglas NSG con enfoque de “permitir lo necesario y denegar el resto”: Da prioridad a reglas específicas, como permitir RDP desde Bastion a la VM, y bloquea todo lo demás. Aplica el mismo criterio en reglas inbound y outbound.

• Evita asignar IPs públicas a tus VMs: Minimiza la exposición. Si necesitas automatización, la extensión CustomScriptExtension permite pasar parámetros definidos en Terraform, como tokens SAS.

• Conoce los SKUs disponibles: Cada recurso en Azure tiene múltiples SKUs. Revisa la documentación oficial para encontrar el que mejor se adapta a tu caso de uso.

• Elige el tipo de redundancia adecuado: Para pruebas, LRS suele ser suficiente. Para producción, evalúa opciones como GRS o ZRS y acompáñalas de backups o planes de recuperación.

• Configura el acceso privado en Storage Accounts: Por defecto, establece el acceso como privado y controla el acceso mediante RBAC o service endpoints.

• Centraliza secretos en Azure Key Vault: Guarda claves, certificados y tokens de manera segura, y delega el acceso con los roles adecuados.

• Aplica seguridad JIT y JEA al usar tokens SAS:

  • Just In Time (JIT): Otorga permisos solo durante el tiempo necesario.

  • Just Enough Access (JEA): Otorga únicamente los permisos mínimos requeridos.

Si queréis saber más acerca de las características de cada recurso, el código de los scripts de PowerShell y ahondar un poco más en el proyecto, visitar mi Guthub.

TerraformAzure-IDAutomation

Creación de usuarios en EntraID y asignación de roles automática en función de atributos de usuario

En este proyecto me centraré en la creación de usuarios en EntraID a través de Terraform mediante un archivo.json almacenadado localmente. Una vez se da de alta los usuarios, se asignará un rol (RBAC) y un resource group (que también será creado) en función de atributos de usuario. También definiré variables para que el flujo del proyecto sea óptimo y seguro.

Explicación:

Consejos:

Todo lo descrito a continuación se realiza en TERRAFORM. Aunque Terraform aplica los recursos en paralelo, he estructurado esta exposición de forma secuencial para mayor claridad.

Estructura de Recursos

Definiremos en Terraform la creación de dos grupos de recursos. Uno se llamará "frontend" y otro se llamará "backend". Suponemos que estos recursos están bajo una suscripción llamada "dev". De esta forma vamos a aplicar dos tags a cada grupo de recursos, que nos ayudarán en la administración de los mismos. El primero tendrá los tags "dev, frontend" y el segundo "dev, backend". Asi podremos enfocar la administración de presupuestos de la suscripción general o de cada grupo de recursos individual.

Alta de usuarios

Para dar de alta los usuarios, tendremos ya creado un archivo .json con los usuarios y sus atributos. En este caso los usuarios son los siguientes:

• "nombre": "Laura Fernández", "email": "laura.fernandez@ejemplo.onmicrosoft.com", "departamento": "frontend", "puesto": "n2"

• "nombre": "Roberto López", "email": "roberto.lopez@ejemplo.onmicrosoft.com", "departamento": "backend", "puesto": "n1"

• "nombre": "Beatriz Martín", "email": "beatriz.martin@ejemplo.onmicrosoft.com", "departamento": "frontend", "puesto": "n1"

• "nombre": "Miguel Torres", "email": "miguel.torres@ejemplo.onmicrosoft.com", "departamento": "backend", "puesto": "n2"

  Para darlos de alta desde Terraform en Azure, iteramos sobre cada usuario en el archivo "users.json" que tendremos referenciada su ubicación en el archivo "locals.tf" y creamos un objeto (usuario) por cada correo electrónico del listado y completamos su información con los atributos que tienen (nombre, departamento, puesto)

Asignación de rol y resource group

Para esto, volveremos a iterar sobre cada usuario haciendo referencia al valor del elemento. Para explicarme mejor, pongo un ejemplo:

• "nombre": "Laura Fernández", "email": "laura.fernandez@ejemplo.onmicrosoft.com", "departamento": "frontend", "puesto": "n2"

Este usuario tiene un valor de departamento "frontend" y un valor de puesto "n2". Con lo cual en nuestra iteración, definimos que si el usuario sobre el que se itera tiene como valor puesto "n2" se le asignará el rol "Contributor" para el grupo de recursos que tiene en su valor departamento, en este caso "frontend". En la iteración lo que se hace es un operador ternario o expresión condicional, es decir, define que si es "frontend" tiene que ir a "frontend" y si no es así, irá a "backend". Lo mismo hace con el puesto, si es "n1" se le asignará "Reader" y si no es "n1" se le asignará "Contributor".

De esta forma controlamos el rol y su alcance.

• Pensar en qué quieres hacer antes de empezar a escribir la configuración:

  Al ser una estructura de archivos dependientes unos de otros, no tener un mapa claro de lo que quieres realizar

  te hará tener que reescribir el código varias veces, lo que puede dar lugar a error.

• Usar "secrets.tfvars" siempre que vayas a pasar datos sensibles. Es muy importante que nuestro proyecto sea SEGURO:

  Pasar la información a través de este archivo también nos va a ayudar a que el archivo sea reutilizable ya que la

  información no se almacenará en el código. Modificando las variables puede ser reutilizado.

• A la hora de crear el archivo con los usuarios, define atributos de forma simple y unificada:

  Procurar no llamar a un departamento "Dev" a otro "dev", a otro "Desarrollo". El proyecto tiene que tener coherencia

  y continuidad desde el principio.

• Coherencia y continuidad también en las variables. Saber como llamamos a las variables y hacer referencia a ellas:

  No tener esto claro nos va a dar muchos errores a la hora de desplegar la infrastructura en Terraform ya que no va a encontrar

  los datos necesarios al no estar correctamente relacionados. SIEMPRE que puedas utiliza variables para que sea reutilizable.

• Se ordenado:

  Intenta darle un sentido lógico a la implementación. Aunque no influya para el despliegue el orden de creación, es mejor no mezclar las cosas.

  ¿Mis usuarios van a estar asignados a un resource group?, entonces en mi código creo primero los resource groups y luego creo los usuarios.

  ¿Los permisos se los voy a asignar a los usuarios que estoy creando?. Primero creo los usuarios y despues asigno los roles.

  -> resource group -> usuario -> rol

• Seguridad de identidades:

  De forma mínima, por lo menos tienes que hacer 2 cosas al dar de alta identidades en tu tenant.

  -Forzar a cambiar la contraseña asignada por el administrador en el primer inicio de sesión del usuario.

  -Configurar el segundo factor de autenticación (2FA) para añadirle una capa mas de seguridad a la identidad.

Si queréis saber más acerca de las características de cada recurso, y ahondar un poco más en el proyecto, visitar mi Guthub.