Cómo revisar la seguridad de IaC de Terraform en CI/CD con Regula y Bitbucket Pipelines [Tutorial]

Regula 2.3.0 permite a los equipos de la nube evaluar la infraestructura como código (IaC) de Terraform, CloudFormation, Azure Resource Manager y Kubernetes para detectar problemas de seguridad y cumplimiento antes de la implementación. Integrar Regula en los pipelines de integración continua y entrega continua (CI/CD) va un paso más allá, ya que automatiza la implementación segura de la infraestructura en la nube.

En esta publicación del blog, mostraremos cómo integrar Regula con Bitbucket Pipelines (un servicio de CI/CD integrado en Bitbucket) para probar automáticamente los recursos de Amazon Web Services (AWS) declarados en Terraform. Cuando hagamos un commit en nuestro repositorio de Terraform, activaremos una compilación con Bitbucket Pipelines. Veremos cómo Regula detecta una vulnerabilidad de seguridad y hace que falle la compilación de CI, y cómo corregir el problema para que la compilación se complete correctamente.

Al terminar, el pipeline de CI/CD ejecutará el siguiente flujo:

1. Haces un commit de IaC en una rama (en este ejemplo, haremos el commit en la rama main por simplicidad, pero también puedes hacerlo y personalizarlo para los pull request).

2. Envías los commits y activas una compilación de Bitbucket Pipelines.

3. Bitbucket Pipelines ejecuta Regula en tu repositorio (en este ejemplo, también incluimos verificaciones de formato y validación de Terraform para mostrar las prácticas recomendadas).

4. Si la IaC de tu repositorio pasa todas las verificaciones de Regula, la compilación de Bitbucket Pipelines se completa correctamente. De lo contrario, falla.

Consejo: Aunque cada herramienta de CI/CD es diferente, puedes seguir los pasos anteriores para verificar tu IaC en CI/CD con Regula.

Requisitos previos

Para seguir los pasos, necesitarás lo siguiente:

• Una cuenta de Bitbucket (de Bitbucket cloud o de Bitbucket Server)

• Autenticación multifactor habilitada en tu cuenta de Bitbucket

• Una cuenta de proveedor de nube y credenciales cargadas en Bitbucket como variables del repositorio (para esta demostración, usaré AWS)

• Un repositorio de Bitbucket (clonado localmente) que contenga recursos de nube declarados con Terraform (más abajo puedes ver la estructura de mi repositorio)

¿Qué hay en el repositorio?

Lo que ves arriba es una representación visual de la estructura de archivos del repositorio, que incluye, entre otros, los siguientes elementos:

• main.tf: archivo de Terraform que declara información del proveedor y de la cuenta

• ec2/instance.tf: archivo de Terraform que contiene una vulnerabilidad intencional

• .regula.yaml: archivo de configuración de Regula que declara cómo quiero ejecutar Regula en este repositorio

• bitbucket-pipelines.yml: archivo de configuración de Bitbucket Pipelines

Configurar Bitbucket Pipelines

Ahora configuraremos Bitbucket Pipelines para ejecutar compilaciones en nuestro repositorio. En tu repositorio de Bitbucket, haz clic en “Repository Settings” en el lado izquierdo de la página. Luego, desplázate hasta el final del menú que aparece a la izquierda y busca la sección “Pipelines”. Haz clic en “Settings” y, luego, en el control deslizante junto a “Enable Pipelines” para que se vea verde con una marca de verificación blanca.

Los archivos

Revisemos los archivos individuales de nuestro repositorio, empezando por ec2/instance.tf.

El Terraform vulnerable

El archivo Terraform en HashiCorp Configuration Language (HCL) ec2/instance.tf declara los siguientes recursos de AWS:

• Una instancia de Elastic Compute Cloud (EC2)

• Un rol de administración de identidades y accesos (IAM) para acceder a la instancia EC2 anterior

Para demostrar lo que Regula puede hacer con facilidad, incluí intencionalmente vulnerabilidades de seguridad (y sugerencias comentadas que indican cómo corregirlas) en la instancia EC2. (Nota: no implementes este Terraform en AWS sin corregir estas infracciones de seguridad). Analicemos estas vulnerabilidades:

resource "aws_instance" "app_server18391111" {
    ami           = "ami-074cce78125f09d61"
    instance_type = "t2.micro"

    # Un-comment below to satisfy FG_R00253
    #iam_instance_profile = aws_iam_instance_profile.test_profile.name

    # Make the below declaration = false to satisfy FG_R00271
    associate_public_ip_address = true

    tags = {
        Name = "ExampleAppServerInstance18391111"
        Team = "dev"
    }
}

• La línea 9 (actualmente comentada) contiene la asociación entre nuestra instancia EC2 y el rol de IAM y el perfil de instancia que deberían usarse para acceder a ella, en lugar de claves de acceso de IAM. Si pasas la información del rol a una instancia EC2 al iniciarla, puedes limitar el riesgo de que se expongan las claves de acceso y ayudar a evitar que un usuario malicioso comprometa la instancia

• La línea 12 declara que la instancia EC2 debe tener asociada una dirección IP pública, lo que podría permitir que usuarios no autorizados accedan a tu instancia EC2, aunque tengas listas de control de acceso a la red o grupos de seguridad

Implementar esta instancia EC2 en producción tal como está nos expondría a actores maliciosos, que podrían detectar y explotar esta vulnerabilidad con herramientas de automatización mucho antes de que siquiera supiéramos que existe. Por suerte, Regula incluye cientos de reglas para analizar nuestra IaC y detectar infracciones de los Benchmarks del Center for Internet Security (CIS).

Configuración de Bitbucket Pipelines

Veamos cómo el archivo bitbucket-pipelines.yml le indica a Bitbucket Pipelines qué hacer cuando se activa una compilación. Primero, le indicamos a Bitbucket que se trata de un pipeline y, de hecho, del pipeline predeterminado (puedes crear un pipeline independiente para los pull request, las distintas ramas del repositorio y otros motivos):

pipelines:
 default:

Elegí ejecutar los siguientes pasos en secuencia, pero también puedo ejecutarlos en paralelo si agrego el comando parallel en la columna a la izquierda de los pasos.

A continuación, declararé mi primer paso, que usa la imagen de HashiCorp Terraform para inicializar Terraform, ajustar el formato de Terraform según los estándares canónicos de HCL y verificar que Terraform sea válido (por ejemplo, confirmar que haya declarado todas mis variables y módulos):

- step:
    name: 1 - Initialize, Format, and Validate Terraform
    image: hashicorp/terraform
    script:
        - terraform init && terraform fmt
        - terraform validate

El segundo paso de mi pipeline aprovecha Regula para detectar automáticamente cualquier archivo de IaC (Terraform, CloudFormation, Azure Resource Manager y manifiestos de Kubernetes) en el directorio raíz o en cualquiera de sus subdirectorios, y analizar todos los archivos de IaC detectados en mi repositorio según los estándares de los Benchmarks CIS (Fugue también ofrece compatibilidad lista para usar con otros marcos de cumplimiento, como SOC 2, HIPAA y NIST 800-53).

- step:
    name: 2 - Scan Terraform Locally for Security and Compliance with CIS Benchmarks
    image: fugue/regula
    script:
        # Run in root directory first
        - regula run ./
        # Run in child directories next
        - regula run ./*/

El paso final vuelve a inicializar Terraform y usa de nuevo la imagen de HashiCorp Terraform porque cada paso del pipeline de Bitbucket se ejecuta en un contenedor Docker independiente, por lo que las dependencias declaradas no se transfieren de un paso a otro. Luego, el paso final crea un plan de Terraform y lo aplica:

- step:
    name: 3 - Plan and Apply Secure, Valid Terraform
    image: hashicorp/terraform
    deployment: Production
    trigger: manual
    script:
        - terraform init
        - terraform plan
        - terraform apply -auto-approve

Iniciar una compilación

Probar una compilación (y ver cómo falla): comienzo ingresando los siguientes comandos en mi terminal después de editar mi repositorio que contiene archivos de IaC:

git add 
git commit -m "initiating the bitbucket pipeline"
git push

Cuando detecte el nuevo commit en mi repositorio (o se le indique manualmente que lo haga), Bitbucket Pipelines activará el pipeline descrito en el archivo .yml anterior. A continuación, puedes ver qué ocurre cuando intento hacer un commit en la rama main del repositorio con Terraform que infringe los Benchmarks CIS:

Corregir problemas de configuración con Regula

Ahora que sé que mis archivos de Terraform tienen configuraciones incorrectas, puedo volver a mi repositorio y ejecutar Regula localmente para corregirlas. Configuré este repositorio para que sea fácil quitar los comentarios del código de Terraform corregido, pero configurar correctamente tu infraestructura es tan sencillo como hacer clic en el enlace a la documentación de corrección de reglas de Fugue que aparece con cada infracción después de ejecutar regula. A continuación, puedes ver cómo corregí las reglas de Fugue FG_R00253 y FG_R00271 y luego volví a verificar mi infraestructura con una última ejecución de regula.

Probar una compilación (¡con éxito!)

Con mi infraestructura configurada correctamente, volveré a hacer un commit en mi repositorio de Bitbucket para aprovechar al máximo la automatización que ofrece el pipeline de Bitbucket que configuré.

Volveré a ejecutar los comandos que usé al principio…

git add 
git commit -m "initiating the bitbucket pipeline"
git push

…y obtendré una compilación exitosa:

¡Y eso es todo! Ahora tenemos un pipeline de Regula y Bitbucket para automatizar de forma segura la implementación de infraestructura en la nube con Terraform.

Ejecutar Regula localmente

Por suerte, no tienes que esperar a que Bitbucket Pipelines (u otras herramientas de CI/CD) encuentre los errores. Puedes ejecutar Regula localmente antes de hacer commit y enviar tus cambios; de hecho, te lo recomendamos. Mi opción favorita es el hook de pre-commit de Regula, que pone en práctica la defensa en profundidad al exigir que los desarrolladores corrijan los problemas de seguridad y cumplimiento antes de hacer commit con su código. Al detectar los problemas más temprano en el ciclo de desarrollo, aplicas la seguridad desde etapas anteriores, aceleras el desarrollo y ahorras tiempo, dinero y frustraciones más adelante.

Primero, instala Regula localmente. Es un único archivo binario independiente, así que no necesitas instalar requisitos previos. Solo sigue los pasos de la documentación correspondientes a tu sistema operativo.

Luego, desde la raíz de tu repositorio, ejecuta el mismo comando que ejecuta Bitbucket Pipelines:

regula run

Verás el mismo resultado que aparece en los registros de Bitbucket Pipelines, pero al ejecutar esto localmente evitarás consumir minutos de compilación y distribuirás las responsabilidades de los equipos de seguridad entre los desarrolladores, lo que reduce (¡o incluso elimina!) los cuellos de botella relacionados con la seguridad antes de la implementación.

Próximos pasos

¿Quieres saber más sobre Regula? Consulta nuestro repositorio de GitHub y la documentación. Regula evalúa Terraform HCL, Terraform plan JSON, CloudFormation YAML/JSON, manifiestos YAML de Kubernetes y plantillas de Azure Resource Manager para detectar problemas de seguridad y cumplimiento. Regula también admite excepciones, reglas personalizadas, habilitar o deshabilitar reglas y mucho más.

¿Te interesan otras formas de automatizar la implementación segura de infraestructura en la nube? Lee nuestra publicación del blog sobre la integración de Regula y Travis CI.