Automatizar la seguridad de Terraform en implementaciones de Scalr con Regula [Tutorial]

Introducción a la integración de Regula y Scalr

Regula

Regula permite que los equipos de la nube evalúen Terraform, CloudFormation, Azure Resource Manager y la infraestructura como código (IaC) de Kubernetes para detectar problemas de seguridad y cumplimiento antes de la implementación. Regula es una implementación de código abierto de Rego, el lenguaje de consulta que utiliza el proyecto Open Policy Agent (OPA). Cuando corresponde, las políticas de Regula se han asociado con los benchmarks del Center for Internet Security (CIS) para Amazon Web Services (AWS), Azure, Google Cloud y Kubernetes Foundation, de modo que los usuarios puedan aplicar estas políticas a la IaC antes de la implementación.

La capacidad de Regula para analizar la IaC y detectar configuraciones incorrectas antes de la implementación extiende la responsabilidad de la seguridad y el cumplimiento en la nube a los equipos de desarrollo de una manera sencilla para los desarrolladores, y así elimina el cuello de botella de seguridad al implementar infraestructura en la nube con IaC. El equipo de ingeniería de Fugue mantiene Regula.

Scalr

Scalr es un software de automatización y colaboración para Terraform (TACO) que admite la automatización de pull request, la CLI nativa de Terraform y los flujos de trabajo basados en módulos. Scalr ayuda a organizaciones de todos los tamaños a crecer gracias a su modelo jerárquico, que centraliza operaciones administrativas como RBAC, el control de políticas mediante OPA, las vistas operativas y un registro privado de módulos. Esto permite una descentralización controlada de las operaciones de Terraform y que los desarrolladores ejecuten flujos de trabajo de Terraform de forma independiente dentro de sus entornos.

Objetivo

Combinar las prácticas capacidades de análisis de IaC de Regula con las capacidades de automatización y colaboración de Terraform de Scalr para demostrar cómo las organizaciones pueden automatizar la implementación segura de infraestructura en la nube con Terraform.

Requisitos previos

Si quieres seguir los pasos, necesitarás lo siguiente:

• Una cuenta de Scalr con custom hooks habilitados (nota: esta función es de pago). Más abajo se explica cómo configurarlos.

• Un workspace configurado en tu cuenta de Scalr. En un workspace se almacenan y administran todos los objetos relacionados con los recursos gestionados por Terraform.

• Credenciales del proveedor de nube agregadas a tu cuenta de Scalr (para esta demostración, usaré AWS).

• Un proveedor de sistema de control de versiones (VCS) configurado en tu cuenta de Scalr (para esta demostración, usaré GitHub).

• Asigna scripts/security.bash como custom hook “Before plan” y scripts/validate.bash como custom hook “After plan”.

• La versión más reciente de Regula en tu directorio /usr/local/bin (nuestro script security.bash la descargará y ejecutará dentro del pipeline de Scalr, pero tenerla instalada localmente te permitirá evaluar el código antes de confirmarlo).

Si quieres, también puedes clonar mi repositorio para ahorrarte trabajo. Ejecuta el siguiente comando en la Terminal:

git clone https://github.com/fugue/fugue-scalr-integration.git

¿Qué hay en el repositorio?

Lo que ves arriba es una representación visual de la estructura de archivos de mi repositorio, que contiene principalmente:

• main.tf: un archivo de Terraform que declara información sobre proveedores y módulos

• s3/: un subdirectorio con archivos de Terraform que contienen vulnerabilidades intencionales

• waivers.rego: un archivo que exime de ciertas reglas y las deshabilita

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

• scripts/: un subdirectorio que contiene el custom hook descrito arriba

Aquí puedes ver mejor el contenido del módulo S3, junto con una superposición del estado de configuración de toda la infraestructura (las infracciones de los benchmarks CIS aparecen en rojo):

Configurar custom hooks de Scalr

Los custom hooks sirven para personalizar el flujo de trabajo principal de Terraform, ya sea con comandos, scripts o llamadas a la API. Además de usar Regula para analizar la seguridad y el cumplimiento, los scripts de shell de esta demostración comprueban el formato y la validez de Terraform.

Puedes agregar custom hooks al crear un workspace o en cualquier momento después, desde la configuración del workspace, donde especificas qué se debe ejecutar antes y después de plan, y antes y después de apply. A continuación, se muestra cómo configurar custom hooks:

En las opciones “Advanced” de la página “Settings”, Scalr permite elegir la ruta relativa en la que se ejecutarán los comandos de Terraform (para este ejemplo, seleccioné el directorio s3/), por lo que la ruta a los scripts lleva el prefijo “./../”.

Automatizar los análisis de seguridad por el camino de menor resistencia

El camino de menor resistencia a la nube a través de IaC lleva tanto a principiantes como a expertos a usar código de Terraform que encuentran en Internet o que comparten colegas y equipos, con la suposición de que es seguro y cumple con las normas. Ese código puede superar todas las comprobaciones disponibles de formato, linting y validación, pero exponer a quienes lo usan a vulnerabilidades potencialmente devastadoras.

Exponer vulnerabilidades latentes: analizar la infraestructura con Regula

Para esta demostración, elegí intencionalmente este camino de menor resistencia y busqué código de Terraform que me permitiera implementar un bucket de S3 lo más rápido posible. Primero te mostraré lo vulnerable que es este código de Terraform. Para ello, ejecutaré regula run localmente en este repositorio:

Al ejecutar este comando, Regula:

• detectará automáticamente los archivos de IaC compatibles en todo el repositorio

• analizará la seguridad y el cumplimiento de todos los archivos de IaC compatibles que detecte

• mostrará los resultados del análisis en orden descendente de gravedad, con la siguiente información:

  • ID y título de la regla de Fugue (por ejemplo, FG_R00099)

  • Gravedad de la regla (por ejemplo, [High])

  • Enlace a los pasos para corregir la regla (por ejemplo, https://docs.fugue.co/FG_R00099.html)

  • Ubicación de la infracción de la regla, indicada por archivo de IaC

Los resultados del análisis anterior deberían preocupar tanto a los ingenieros de DevOps como a los de seguridad. Al copiar, pegar e implementar código vulnerable, nos exponemos a hackers que usan la automatización para detectar y explotar estas vulnerabilidades. Además, hice este análisis voluntariamente, sin integrarlo en un pipeline (como el de Scalr): ¡no es precisamente el camino de menor resistencia! Las brechas de seguridad del pasado nos enseñan que los hackers de la nube encuentran vulnerabilidades mediante la automatización y luego las usan (por ejemplo, un bucket de S3 vulnerable) como punto de entrada para atacar la infraestructura y los datos que más debemos proteger. Si no usamos una automatización similar para configurar correctamente los recursos antes de que lleguen a la nube, estos ataques se vuelven cuestión de “cuándo”, no de “si ocurrirán”.

Analicemos más a fondo estas infracciones de reglas con un fragmento de código (si sigues los pasos, el código de abajo corresponde a las líneas 18 a 26 de s3/bucket.tf, con la sangría ajustada hacia la izquierda para que sea más fácil de ver):

18server_side_encryption_configuration {
19  rule {
20    apply_server_side_encryption_by_default {
21      #Un-comment below to satisfy FG_R00099
22      #kms_master_key_id = aws_kms_key.mykey.arn
23      #sse_algorithm     = "aws:kms"
24    }
25  }
26}

Agregué comentarios junto a las vulnerabilidades intencionales de este código como pistas sobre cómo modificarlo para cumplir con las reglas numeradas que incluye Regula de forma predeterminada. Tal como está escrito ahora, el código de arriba infringe la regla FG_R00099 (una infracción de gravedad alta según los benchmarks CIS): si se implementa sin corregirla, este bucket de Amazon Simple Storage Service (S3) expondría los datos almacenados. Para quienes recién empiezan y leen esta publicación, sería como dejar abierta la bóveda de un banco y una caja de seguridad. Aunque hicieras un depósito en un camión blindado (cifrado en tránsito, en esta analogía), no cerrar la bóveda ni la caja de seguridad (aplicar cifrado del lado del servidor) podría volver inútiles esos intentos de proteger los datos.

Lo preocupante de este ejemplo es que la documentación de Terraform de la que obtuve el código explica cómo implementar un bucket de S3 de la manera más sencilla posible (como suele ocurrir con la documentación), y prioriza los ejemplos de parámetros obligatorios. Los parámetros opcionales (¡entre ellos, el cifrado del lado del servidor!) quedan para las últimas secciones de la documentación, donde es fácil pasarlos por alto. Al fin y al cabo, configurar tus recursos en la nube es tu responsabilidad: el proveedor de nube solo te proporciona los medios para implementar y usar la infraestructura en la nube de forma segura.

¿Por qué dejar la seguridad al azar si puedes automatizarla tan fácilmente?

Flexibilidad aplicada: eximir y deshabilitar reglas

A veces, las necesidades críticas del negocio entran en conflicto con reglas de gravedad baja o media. Por ejemplo, es comprensible que un negocio que depende de entregar contenido mediante un bucket de S3 que aloja un sitio web estático se canse de ver que ese bucket infringe la regla FG_R00229 (los buckets de S3 deben tener habilitadas todas las opciones de “block public access”). Los usuarios de Regula pueden eximir recursos específicos de reglas determinadas o deshabilitar ciertas reglas por completo. Para esta demostración, decidí eximir mi bucket de registros de la regla FG_R00274 y deshabilitar por completo la regla de Fugue FG_R00275 mediante mi documento de exenciones (waivers.rego). A continuación, verás lo sencillo que es eximir y deshabilitar reglas con Regula:

package fugue.regula.config

waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}

rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

Poner en práctica la seguridad de IaC: impedir que las configuraciones incorrectas lleguen a la nube

Ahora veamos cómo Regula se integra con el backend de operaciones y estado remoto de Terraform de Scalr para impedir que se implemente infraestructura mal configurada en la nube.

El primer script de custom hook (security.bash) descarga, extrae, mueve y ejecuta la versión más reciente de Regula; analiza todos los archivos de Terraform (planes en HashiCorp Configuration Language (HCL) o JavaScript Object Notation (JSON) de Terraform) y genera un código de salida distinto de cero y un mensaje que detienen la compilación de Scalr, o un código de salida cero que permite que continúe.

El siguiente script de custom hook (validate.bash) comprueba que Terraform en este repositorio sea válido y tenga el formato correcto según los estándares canónicos de HCL. Si Terraform no es válido, el script genera un código de salida distinto de cero. Si es válido, Scalr ejecuta el resto de la compilación y ejecuta automáticamente terraform plan y terraform apply. Así, implementa tu infraestructura en la nube y mantiene el estado de Terraform en su interfaz fácil de usar.

Probar una compilación (y fallar)

Ahora te mostraré cómo se ve cuando confirmo código de Terraform vulnerable en mi repositorio de GitHub. Primero ejecuto los siguientes comandos (<files> es un marcador de posición para los archivos que se deben confirmar y subir a GitHub):

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

Scalr detectará que confirmé cambios en mi repositorio y usará los scripts que proporcioné para analizar mi código de Terraform en busca de problemas de seguridad y cumplimiento:

Resolver problemas de configuración con Regula

Ahora que sé que mis archivos de Terraform tienen configuraciones incorrectas, puedo volver a mi repositorio en VSCode y ejecutar regula run localmente para resolver esos problemas (también podría exportar los resultados de la ejecución de regula run en Scalr). Configuré este repositorio para poder descomentar fácilmente las correcciones de mi código de Terraform, pero configurar correctamente tu infraestructura es tan sencillo como hacer clic en el hipervínculo que aparece junto a cada regla después de ejecutar regula run. Observa que las dos reglas que estoy corrigiendo (FG_R00036 y FG_R00101) se resuelven con una sola línea de código cada una. Estas líneas se extraen directamente de los pasos para corregir la regla que contiene el hipervínculo incluido en los resultados de este comando. Difícil encontrar algo más sencillo para los desarrolladores.

Probar una compilación (¡y tener éxito!)

Con mi infraestructura bien configurada, volveré a confirmar cambios en mi repositorio de GitHub para aprovechar al máximo las capacidades de automatización de Terraform de Scalr. Esto volverá a ejecutar mis scripts de custom hook y, si se ejecutan correctamente, Scalr ejecutará terraform plan y terraform apply.

Para demostrarlo, volveré a ejecutar los comandos que ejecuté al principio:

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

...¡y la compilación se completó correctamente!

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

Próximos pasos

El ejemplo anterior muestra cómo proteger tu IaC de acuerdo con los benchmarks de CIS. Si necesitas otras familias de cumplimiento (como HIPAA, SOC2, ISO 27001, NIST 800-53, GDPR, PCI DSS, AWS WAF o CSA), visita www.fugue.co. El ejemplo también muestra hooks personalizados (una función de pago de Scalr). Si quieres funciones que faciliten el trabajo, como estimaciones de costos de infraestructura en la nube, agentes autohospedados, SSO o vistas previas de políticas, visita https://www.scalr.com/.

¿Quieres obtener más información sobre Regula? Consulta nuestro repositorio de GitHub y la documentación. Regula evalúa Terraform HCL, Terraform plan JSON, YAML/JSON de CloudFormation, manifiestos YAML de Kubernetes y plantillas de Azure Resource Manager para detectar problemas de seguridad y cumplimiento. Regula también admite exenciones, reglas personalizadas, la activación o desactivación de 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 o la publicación sobre la integración de Regula y Bitbucket Pipelines.