DEV Community

Cover image for CI/CD con GitHub Actions, Terraform y AWS desplegando OWASP Juice Shop
Hassel Muñoz
Hassel Muñoz

Posted on

CI/CD con GitHub Actions, Terraform y AWS desplegando OWASP Juice Shop

#aws #devops #owasp #cicd

El problema real

Gestionar infraestructura manualmente sigue siendo uno de los mayores puntos de fricción en equipos DevOps. Cambios no auditados, configuraciones inconsistentes entre ambientes y despliegues manuales generan errores difíciles de rastrear y operaciones poco confiables.

La solución moderna es automatizar completamente el ciclo de vida de infraestructura y despliegue utilizando Infrastructure as Code (IaC) y pipelines CI/CD.

En este proyecto implementaremos un flujo automatizado utilizando GitHub Actions, Terraform y AWS para desplegar OWASP Juice Shop, una aplicación vulnerable utilizada ampliamente para prácticas de seguridad ofensiva y pruebas de AppSec.

¿Qué implementa este proyecto?

Este laboratorio implementa un pipeline CI/CD completo que automatiza:

  • Validación de infraestructura
  • Planificación de cambios Terraform
  • Despliegue automático en AWS
  • Gestión declarativa de infraestructura
  • Protección de ramas y flujo GitOps
  • Destrucción controlada de recursos

Todo utilizando herramientas modernas del ecosistema cloud-native.

Arquitectura del flujo CI/CD

Objetivos del proyecto

  • Implementar un flujo CI/CD automatizado utilizando GitHub Actions
  • Utilizar Terraform como herramienta de Infrastructure as Code
  • Desplegar automáticamente OWASP Juice Shop en AWS
  • Aplicar buenas prácticas DevOps y GitOps
  • Comprender el ciclo completo desde código hasta despliegue

Tecnologías utilizadas

Tecnología Propósito
GitHub Actions Automatización CI/CD
Terraform Infrastructure as Code
AWS Infraestructura cloud
Elastic Beanstalk Hosting de aplicación
S3 Backend Almacenamiento remoto del state
DynamoDB State locking de Terraform
OWASP Juice Shop Aplicación vulnerable de pruebas

Estructura del repositorio

backend.tf

Define el backend remoto de Terraform.

Ejemplo recomendado:

terraform {
  backend "s3" {
    bucket         = "terraform-state-prod"
    key            = "juice-shop/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}
Enter fullscreen mode Exit fullscreen mode

Esto permite:

  • State remoto compartido
  • Versionado
  • Cifrado
  • Locking concurrente
  • Trabajo colaborativo seguro

provider.tf

Define el provider AWS utilizado por Terraform.

provider "aws" {
  region = var.aws_region
}
Enter fullscreen mode Exit fullscreen mode

vars.tf

Contiene variables reutilizables para:

  • Región AWS
  • Networking
  • Nombres de recursos
  • Configuración de ambientes

hs-juice-shop.tf

Contiene la infraestructura principal:

  • VPC
  • Subredes públicas y privadas
  • NAT Gateway
  • Elastic Beanstalk
  • CodePipeline
  • Recursos asociados

GitHub Actions Workflow

action-tf-plan.yaml

Se ejecuta en cada Pull Request.

Funciones principales

  • terraform fmt
  • terraform validate
  • terraform plan
  • Validación de cambios
  • Revisión previa antes del merge

Esto evita cambios inseguros en infraestructura.

action-tf-deploy.yaml

Se ejecuta automáticamente después de un merge a main.

Funciones principales

  • terraform init
  • terraform plan
  • terraform apply -auto-approve

Automatiza completamente el despliegue.

action-tf-destroy.yaml

Permite destruir la infraestructura manualmente.

Funciones principales

  • terraform destroy
  • Eliminación controlada de recursos
  • Optimización de costos

Seguridad y buenas prácticas

GitHub Secrets

Las credenciales AWS deben almacenarse como secretos:

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

Sin embargo, en ambientes modernos se recomienda utilizar:

GitHub OIDC + IAM Roles

Esto elimina credenciales estáticas y mejora significativamente la seguridad.

Protección de rama main

La rama principal debe tener protección habilitada:

  • Pull Requests obligatorios
  • Reviews requeridos
  • Status checks obligatorios
  • Bloqueo de pushes directos

Esto implementa prácticas GitOps reales.

Buenas prácticas recomendadas

  • Utilizar backend remoto en S3
  • Habilitar locking con DynamoDB
  • Evitar state local
  • No almacenar state en Git
  • Ejecutar terraform fmt y validate
  • Integrar análisis de seguridad con tfsec o Checkov
  • Separar ambientes (dev, qa, prod)
  • Utilizar variables por entorno
  • Destruir recursos no utilizados

Consideraciones sobre costos

Este laboratorio despliega recursos reales en AWS:

  • VPC
  • NAT Gateway
  • Elastic Beanstalk
  • CodePipeline
  • Networking asociado

El NAT Gateway genera costos incluso sin tráfico significativo.

Se recomienda destruir la infraestructura al finalizar las pruebas:

terraform destroy
Enter fullscreen mode Exit fullscreen mode

Resultado esperado

Al finalizar este proyecto tendrás:

  • Un pipeline CI/CD funcional
  • Infraestructura desplegada automáticamente
  • Flujo GitOps básico implementado
  • Experiencia práctica con Terraform y GitHub Actions
  • Integración real con AWS

Además, entenderás cómo equipos DevOps modernos automatizan infraestructura cloud utilizando Infrastructure as Code.

Conclusión

Infrastructure as Code no se trata únicamente de automatizar despliegues. Se trata de convertir infraestructura en un activo versionable, auditable y reproducible.

Terraform + GitHub Actions + AWS forman una combinación extremadamente poderosa para construir pipelines modernos, escalables y alineados con prácticas DevOps reales.

Automatizar infraestructura ya no es opcional. Es parte fundamental de cualquier arquitectura cloud moderna.

Top comments (0)