Kitchen-Terraform para Testing: Guía de Mantenimiento Legacy y Migración

TL;DR

• Kitchen-Terraform fue archivado en octubre 2024—no lo uses para proyectos nuevos
• Si heredaste un codebase con Kitchen-Terraform, esta guía te ayuda a mantenerlo mientras planificas la migración
• Los patrones de compliance de InSpec siguen siendo valiosos—migra a tests nativos de Terraform o InSpec standalone

Ideal para: Equipos manteniendo configuraciones legacy de Kitchen-Terraform o planificando migración Omitir si: Empiezas desde cero—usa tests nativos de Terraform o Terratest Tiempo de lectura: 10 minutos

Abordemos el elefante en la habitación: Kitchen-Terraform está deprecado y archivado. El repositorio se volvió solo-lectura el 22 de octubre de 2024, tras el lanzamiento del framework de tests nativo de Terraform 1.6.

Pero la realidad es: miles de organizaciones todavía ejecutan Kitchen-Terraform en producción. Si heredaste uno de estos codebases, necesitas entender cómo funciona, mantenerlo operativo y planificar tu migración. Para eso es esta guía.

Entendiendo la Arquitectura de Kitchen-Terraform

Kitchen-Terraform combinaba tres herramientas:

El flujo era: Test Kitchen orquesta → Terraform provisiona → InSpec verifica.

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Test Kitchen  │────▶│    Terraform    │────▶│     InSpec      │
│   (Orquestar)   │     │  (Provisionar)  │     │   (Verificar)   │
└─────────────────┘     └─────────────────┘     └─────────────────┘

Prerrequisitos para Mantenimiento Legacy

Si estás manteniendo una configuración existente de Kitchen-Terraform:

• Ruby 2.7+ con Bundler
• Terraform < 2.0 (Kitchen-Terraform soporta >= 0.11.4, < 2.0.0)
• gem kitchen-terraform (versión 7.x fue el último release mayor)
• InSpec 4.x o 5.x

Verifica tus versiones actuales:

ruby --version
terraform version
bundle exec kitchen version
inspec version

Anatomía de un Proyecto Kitchen-Terraform

Una estructura típica:

terraform-module/
├── main.tf
├── variables.tf
├── outputs.tf
├── kitchen.yml              # Configuración de Test Kitchen
├── Gemfile                  # Dependencias Ruby
└── test/
    └── integration/
        └── default/
            ├── controls/
            │   └── example.rb   # Controles InSpec
            └── inspec.yml       # Perfil InSpec

El Archivo kitchen.yml

driver:
  name: terraform
  root_module_directory: .
  parallelism: 4

provisioner:
  name: terraform

verifier:
  name: terraform
  systems:
    - name: default
      backend: aws
      controls:
        - example

platforms:
  - name: terraform

suites:
  - name: default
    driver:
      variables:
        instance_type: t3.micro
        environment: test

Ejemplo de Control InSpec

# test/integration/default/controls/example.rb

control 's3-bucket-encryption' do
  impact 1.0
  title 'S3 bucket must have encryption enabled'
  desc 'Verify that the S3 bucket has server-side encryption configured'

  describe aws_s3_bucket(bucket_name: input('output_bucket_name')) do
    it { should exist }
    it { should have_default_encryption_enabled }
  end
end

control 's3-bucket-versioning' do
  impact 0.7
  title 'S3 bucket should have versioning enabled'

  describe aws_s3_bucket(bucket_name: input('output_bucket_name')) do
    it { should have_versioning_enabled }
  end
end

Observa cómo los outputs de Terraform (con prefijo output_) se convierten automáticamente en inputs de InSpec.

Ejecutando Tests Legacy

El flujo de trabajo de Kitchen-Terraform:

# Instalar dependencias
bundle install

# Crear infraestructura y ejecutar tests
bundle exec kitchen test

# O paso a paso:
bundle exec kitchen create    # Inicializar Terraform
bundle exec kitchen converge  # Aplicar Terraform
bundle exec kitchen verify    # Ejecutar tests InSpec
bundle exec kitchen destroy   # Limpiar

Debugging de Tests Fallidos

# Mantener infraestructura después de fallo
bundle exec kitchen verify --destroy=never

# Ejecutar suite específica
bundle exec kitchen test default-terraform

# Salida verbosa
bundle exec kitchen test -l debug

Por Qué la Migración es Necesaria

Más allá del estado archivado, Kitchen-Terraform tiene limitaciones prácticas:

Ruta de Migración 1: Tests Nativos de Terraform

Para la mayoría de equipos, migra al framework de tests integrado de Terraform (Terraform 1.6+).

Antes (Kitchen-Terraform InSpec)

# test/integration/default/controls/s3.rb
control 's3-encryption' do
  describe aws_s3_bucket(bucket_name: input('output_bucket_name')) do
    it { should have_default_encryption_enabled }
  end
end

Después (Test Nativo de Terraform)

# tests/s3_bucket.tftest.hcl
run "create_s3_bucket" {
  command = apply

  assert {
    condition     = aws_s3_bucket_server_side_encryption_configuration.this.rule[0].apply_server_side_encryption_by_default[0].sse_algorithm == "AES256"
    error_message = "S3 bucket must have AES256 encryption enabled"
  }
}

run "verify_versioning" {
  command = apply

  assert {
    condition     = aws_s3_bucket_versioning.this.versioning_configuration[0].status == "Enabled"
    error_message = "S3 bucket versioning must be enabled"
  }
}

Ejecuta con:

terraform test

Patrón de Script de Migración

#!/bin/bash
# migrate-kitchen-to-native.sh

# 1. Extraer controles InSpec
CONTROLS_DIR="test/integration/default/controls"

# 2. Crear directorio de tests Terraform
mkdir -p tests

# 3. Generar reporte de migración
echo "Controles a migrar:"
grep -r "^control" $CONTROLS_DIR | while read line; do
  echo "  - $line"
done

# 4. Recordatorio
echo ""
echo "Pasos manuales requeridos:"
echo "1. Convertir cada control InSpec a bloques assert de Terraform"
echo "2. Mapear input('output_*') a atributos de recursos Terraform"
echo "3. Eliminar dependencias de kitchen.yml y Gemfile"

Ruta de Migración 2: InSpec Standalone

Si tus controles InSpec son complejos o prueban más que el estado de Terraform, ejecuta InSpec independientemente:

# Instalar InSpec
gem install inspec-bin

# Ejecutar contra infraestructura desplegada
inspec exec test/integration/default \
  --input output_bucket_name=my-bucket-name \
  --target aws://us-west-2

Crea un script wrapper para CI/CD:

#!/bin/bash
# run-compliance-tests.sh

# Desplegar con Terraform
terraform init
terraform apply -auto-approve

# Extraer outputs para InSpec
BUCKET_NAME=$(terraform output -raw bucket_name)

# Ejecutar tests de compliance InSpec
inspec exec ./compliance \
  --input output_bucket_name=$BUCKET_NAME \
  --target aws://$AWS_REGION \
  --reporter cli json:reports/compliance.json

# Limpiar
terraform destroy -auto-approve

Migración Asistida por IA

En 2026, las herramientas de IA pueden acelerar tu migración significativamente.

Lo que la IA hace bien:

• Convertir sintaxis Ruby de InSpec a assertions HCL de Terraform
• Identificar atributos equivalentes de recursos Terraform para checks de InSpec
• Generar checklists de migración desde archivos kitchen.yml
• Escribir scripts wrapper para ejecución standalone de InSpec

Lo que aún necesita humanos:

• Decidir qué controles siguen siendo relevantes
• Entender los requisitos de compliance detrás de cada control
• Validar que los tests migrados mantienen la misma cobertura
• Manejar recursos InSpec personalizados sin equivalente en Terraform

Prompt útil:

Convierte este control InSpec a un test nativo de Terraform:

control 'ec2-instance-type' do
  impact 1.0
  title 'EC2 instance must use approved instance type'

  describe aws_ec2_instance(name: input('output_instance_id')) do
    its('instance_type') { should be_in ['t3.micro', 't3.small'] }
    its('image_id') { should match /^ami-/ }
  end
end

El recurso Terraform está definido como:
resource "aws_instance" "main" {
  ami           = var.ami_id
  instance_type = var.instance_type
}

Genera el archivo .tftest.hcl equivalente con las assertions apropiadas.

Framework de Decisión

Mantén Kitchen-Terraform Si:

• Tienes extensos recursos InSpec personalizados
• El timeline de migración es 12+ meses
• El equipo tiene fuerte experiencia en Ruby
• Los frameworks de compliance requieren específicamente reportes InSpec

Migra a Tests Nativos Si:

• Estás probando configuración Terraform, no estado de la nube
• Quieres ejecución más rápida de tests
• Estás reduciendo dependencias de CI/CD
• Empiezas de cero o refactorizas de todas formas

Migra a InSpec Standalone Si:

• Necesitas reportes de compliance CIS benchmark
• El testing va más allá de recursos gestionados por Terraform
• Requisitos regulatorios exigen InSpec
• Infraestructura multi-herramienta (no solo Terraform)

Midiendo el Éxito de la Migración

Señales de que la migración no funciona:

• Tests pasan pero auditorías de compliance fallan — gaps de cobertura
• Tiempo de ejecución aumentó — assertions sobre-complicadas
• Más falsos positivos — assertions demasiado estrictas

Errores Comunes

1. Perder Cobertura de Compliance

# MAL: Solo verifica estado Terraform
assert {
  condition = aws_s3_bucket.this.bucket != ""
  error_message = "Bucket must exist"
}

# MEJOR: Verifica configuración real
assert {
  condition = aws_s3_bucket_versioning.this.versioning_configuration[0].status == "Enabled"
  error_message = "Versioning must be enabled for compliance"
}

2. Ignorar el Testing de Estado Cloud de InSpec

Los tests nativos de Terraform verifican estado, no realidad. Para verificación real en la nube, mantén InSpec o usa Terratest:

# InSpec prueba recursos AWS reales
inspec exec compliance/ --target aws://

# Tests de Terraform verifican estado de Terraform
terraform test

3. Apresurar la Migración

Migra incrementalmente:

1. Primero: Ejecuta AMBOS Kitchen-Terraform Y tests nativos en paralelo
2. Luego: Verifica paridad de cobertura
3. Finalmente: Elimina Kitchen-Terraform

Próximos Pasos

Si estás manteniendo Kitchen-Terraform, comienza tu plan de migración ahora. El framework no recibirá nuevas features, y la compatibilidad con Terraform 2.x es incierta.

Para proyectos nuevos, omite Kitchen-Terraform completamente. Usa tests nativos de Terraform para validación de configuración y Terratest o InSpec standalone para verificación de infraestructura real.

Los patrones de InSpec que aprendiste siguen siendo valiosos—el pensamiento de compliance-as-code se transfiere directamente a cualquier framework de testing.

Artículos relacionados:

• Estrategias de Testing y Validación en Terraform
• Terratest: Testing de Infraestructura como Código
• Mejores Prácticas de Testing en Pulumi
• Estrategia de la Pirámide de Automatización de Tests

Recursos externos:

• Kitchen-Terraform GitHub (Archivado)
• Documentación de Terraform Test
• Documentación de Chef InSpec