Herramientas para detectar la desviación de infraestructura

Predecir las desviaciones de infraestructura es como predecir las nevadas en invierno… sabes que ocurrirán en algún momento, pero no puedes saber exactamente cuándo. Y, al igual que con las nevadas, contar con una forma de detectarlas lo antes posible te permitirá estar mejor preparado y proteger más tu infraestructura.

En este artículo, exploraremos los principios de la detección de desviaciones, sus distintos tipos y causas, y las herramientas que ayudan a detectarlas con un ejemplo sencillo.

¿Qué es la detección de desviaciones?

Para entender por qué necesitas herramientas de detección de desviaciones, primero debes comprender qué es la desviación de infraestructura. En pocas palabras, puedes pensar en ella como una diferencia entre toda tu infraestructura y tu archivo de configuración.

Para esta publicación, nos centraremos en HashiCorp Terraform como herramienta de software de infraestructura como código (IaC) para implementar recursos en la nube. En el mundo de Terraform, hay una desviación cuando el archivo de estado no coincide con lo que implementaste en tu proveedor de nube.

Aquí es donde las herramientas adecuadas para detectar esas desviaciones pueden mejorar significativamente tu postura de seguridad. Imagina un mundo perfecto en el que recibes alertas si alguien cambia manualmente tu grupo de seguridad en lugar de usar Terraform. Y, además, ¿no sería fantástico recibir alertas sobre recursos nuevos creados fuera de Terraform?

Recursos administrados y no administrados

Para ilustrar ese mundo perfecto, distinguiremos dos tipos de desviaciones:

Desviaciones en recursos administrados por IaC

Como contamos con los archivos de configuración y de estado de todos los recursos implementados en tu proveedor de nube, tu herramienta de IaC suele ser muy útil para detectar cambios realizados fuera de ella o que aún no se han aplicado.

Desviaciones en recursos no administrados por IaC

Por otro lado, este tipo de desviación es difícil de detectar, ya que esos recursos no están definidos en tu archivo de configuración ni en el de estado.

¿Por qué ocurren las desviaciones?

Las desviaciones ocurren por muchas razones obvias, pero HashiCorp lo explica mejor que nadie:

«En el contexto de tu configuración, ocurre cuando agregas o eliminas recursos o cambias sus definiciones. Fuera de tu configuración, el desvío se produce cuando los recursos se dan de baja o fallan, y cuando se hacen cambios manualmente o mediante otras herramientas de automatización».

Veamos ejemplos reales de los dos tipos de desviación y su impacto. Una desviación en un recurso administrado podría ocurrir si alguien cambia manualmente el control de versiones de tu bucket de Amazon S3 configurado con Terraform. En cambio, una desviación en un recurso no administrado podría ocurrir si alguien agrega manualmente un bucket de S3 fuera de Terraform (por ejemplo, desde la consola de AWS). (Consulta nuestro artículo anterior para obtener consejos para administrar las desviaciones causadas por cambios manuales.)

¿Qué herramientas pueden ayudarnos a detectar esas desviaciones?

Ahora, centrémonos en las herramientas que te ayudan a detectar desviaciones en recursos administrados y no administrados. Para el resto de esta publicación, usaremos el mismo ejemplo sencillo de Terraform que explicamos antes:

1resource "aws_s3_bucket" "example" {
2        bucket = "drift-example-managed-resource"
3        versioning {
4                enabled = true
5        }
6}

Solo cambiaremos en la consola el atributo de control de versiones a false para generar una desviación. Además, crearemos manualmente el mismo bucket de S3 desde la consola de AWS.

Ahora veamos tres herramientas para administrar las desviaciones:

1. terraform plan

2. CloudQuery

3. driftctl

1. terraform plan

El comando terraform plan describe de forma sencilla qué se debe aplicar para obtener la implementación deseada. Veamos el resultado de este comando en nuestra infraestructura actual:

1$ terraform plan
2
3aws_s3_bucket.example: Refreshing state... [id=drift-example-managed-resource]
4
5Note: Objects have changed outside of Terraform
6
7Terraform detected the following changes made outside of Terraform since the last "terraform apply":
8
9  # aws_s3_bucket.example has changed
10  ~ resource "aws_s3_bucket" "example" {
11        id                          = "drift-example-managed-resource"
12        # (10 unchanged attributes hidden)
13
14      ~ versioning {
15          ~ enabled    = true -> false
16            # (1 unchanged attribute hidden)
17        }
18    }
19
20Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes.
21
22────────────────────────────────────────────────────────────
23Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
24  ~ update in-place
25
26Terraform will perform the following actions:
27
28  # aws_s3_bucket.example will be updated in-place
29  ~ resource "aws_s3_bucket" "example" {
30        id                          = "drift-example-managed-resource"
31        # (10 unchanged attributes hidden)
32
33      ~ versioning {
34          ~ enabled    = false -> true
35            # (1 unchanged attribute hidden)
36        }
37    }
38
39Plan: 0 to add, 1 to change, 0 to destroy.
40
41────────────────────────────────────────────────────────────
42
43Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

Terraform indica que encontró una desviación en el recurso administrado y explica en qué consistió el cambio (por ejemplo, el control de versiones pasó de true a false). Después, muestra qué hará si decidimos aplicar el plan (por ejemplo, volverá a establecer el control de versiones en true).

Ventajas:

• Forma consistente de detectar desviaciones en recursos administrados

• Admite todos los recursos de Terraform

Desventajas:

• No permite detectar desviaciones en recursos no administrados

• No admite ejecutar planes en varios archivos de estado

2. CloudQuery

CloudQuery es un inventario de activos en la nube de código abierto basado en SQL. De forma predeterminada, extrae todos tus recursos de los proveedores de nube que elijas, les da formato y los carga en PostgreSQL. Luego, incorpora un comando de detección de desviaciones para «convertir este problema de desviación en un problema de datos», como dicen ellos.

Una vez instalado el CLI de CloudQuery, volvamos a detectar las desviaciones de nuestro bucket de S3.

1$ cloudquery fetch
2
3Initializing CloudQuery Providers...
4
5✓ cq-provider-aws@v0.10.10 verified    0s  100 %
6
7Finished provider initialization...
8
9Upgrading CloudQuery providers aws
10
11✓ Upgraded provider aws to latest successfully.
12
13Finished upgrading providers...
14
15Starting provider fetch...
16
17✓ cq-provider-aws@latest fetch complete   15s   Finished Resources: 129/129
18
19Provider fetch complete.
20
21Provider aws fetch summary: ✓ Total Resources fetched: 523 ⚠️ Warnings: 0 ❌ Errors: 0

El primer comando, como explicamos antes, obtiene todos mis recursos de los proveedores de nube y los almacena en una tabla de PostgreSQL.

1$ cloudquery drift scan --deep --debug terraform.tfstate
2
3Initializing CloudQuery Providers...
4
5⌛cq-provider-aws@v0.10.11 downloading...                           4s  100 %
6
7Finished provider initialization...
8
9Using profile drift-example
10Starting module...
11DIFF RESOURCE: s3.buckets:drift-example-managed-resource
12+------------------------------------------+-----------+---------------+-------------------------+
13|                 AWS EXPR                 |  AWS VAL  | TERRAFORM VAL |     TERRAFORM EXPR      |
14+------------------------------------------+-----------+---------------+-------------------------+
15| COALESCE("c"."versioning_status",'')     | Suspended | <nil>         | versioning_status       |
16| COALESCE("c"."versioning_mfa_delete",'') | Disabled  | <nil>         | versioning_mfa_delete   |
17| "c"."block_public_acls"                  | true      | <nil>         | block_public_acls       |
18| "c"."block_public_policy"                | true      | <nil>         | block_public_policy     |
19| "c"."ignore_public_acls"                 | true      | <nil>         | ignore_public_acls      |
20| "c"."restrict_public_buckets"            | true      | <nil>         | restrict_public_buckets |
21+------------------------------------------+-----------+---------------+-------------------------+
22Matching attributes "region", "logging_target_prefix", "logging_target_bucket", "policy", "tags", "replication_role", "arn", "ownership_controls"
23+-----------------------+---------------------------------------------------------+
24|       ATTRIBUTE       |                     MATCHING VALUE                      |
25+-----------------------+---------------------------------------------------------+
26| region                | us-west-2                                               |
27| logging_target_prefix |                                                         |
28| logging_target_bucket |                                                         |
29| policy                | <nil>                                                   |
30| replication_role      |                                                         |
31| arn                   | arn:aws:s3:::drift-example-managed-resource             |
32| ownership_controls    | <nil>                                                   |
33+-----------------------+---------------------------------------------------------+
34Module output:
35=== DRIFT RESULTS  ===
361 Resources not managed by Terraform
37  aws:s3.buckets:
38    - drift-example-un-managed-resource
391 Resources managed by Terraform but drifted
40  aws:s3.buckets:
41    - drift-example-managed-resource
42=== SUMMARY ===
43Total number of resources: 2
44 - 1 not managed by Terraform
45 - 1 managed by Terraform but drifted
46 - 50% covered by Terraform
47Finished module

Este resultado es bastante interesante, ya que podemos ver que encontró mis dos buckets de S3: uno administrado y otro no administrado. Además, detectó una desviación en mi bucket administrado, pero el análisis resulta bastante extraño: indica que el bucket de S3 no tiene control de versiones en AWS, pero que ese dato es desconocido en mi archivo de estado. Probablemente sea un error en la forma en que interpreta los atributos de Terraform. Los otros atributos desviados me hacen preguntarme qué pasaría si tuviera un bucket administrado sin desviaciones.

Volví a aplicar la configuración inicial de mi bucket con terraform apply y ejecuté otra vez cloudquery fetch y cloudquery drift scan --deep --debug terraform.tfstate:

1$ terraform plan
2
3aws_s3_bucket.example: Refreshing state... [id=drift-example-managed-resource]
4
5No changes. Your infrastructure matches the configuration.
6
7Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
8
9$ cloudquery drift scan --deep --debug terraform.tfstate
10
11...
12
13DIFF RESOURCE: s3.buckets:drift-example-managed-resource
14+------------------------------------------+----------+---------------+-------------------------+
15|                 AWS EXPR                 | AWS VAL  | TERRAFORM VAL |     TERRAFORM EXPR      |
16+------------------------------------------+----------+---------------+-------------------------+
17| COALESCE("c"."versioning_status",'')     | Enabled  | <nil>         | versioning_status       |
18| COALESCE("c"."versioning_mfa_delete",'') | Disabled | <nil>         | versioning_mfa_delete   |
19| "c"."block_public_acls"                  | true     | <nil>         | block_public_acls       |
20| "c"."block_public_policy"                | true     | <nil>         | block_public_policy     |
21| "c"."ignore_public_acls"                 | true     | <nil>         | ignore_public_acls      |
22| "c"."restrict_public_buckets"            | true     | <nil>         | restrict_public_buckets |
23+------------------------------------------+----------+---------------+-------------------------+
24…

CloudQuery siguió detectando una desviación en mi bucket, aunque en su tabla de datos el estado del control de versiones había cambiado. Se trata claramente de un falso positivo que no debería tenerse en cuenta, ya que el control de versiones está habilitado en mi bucket desde la consola de AWS.

Ventajas:

• Enumeración muy rápida de mis recursos en la nube con el comando fetch

• Detecta recursos no administrados con el sencillo comando drift scan

• Admite analizar varios archivos de estado

Desventajas:

• Resultados poco confiables para los atributos con desviaciones de buckets de S3 con el comando drift scan --deep --debug

• Solo admite algunos backends para almacenar los archivos de estado (por ejemplo, S3 y almacenamiento local)

• No admite todos los recursos de Terraform

• Requiere una base de datos SQL

3. driftctl

driftctl es una herramienta CLI de código abierto y gratuita que alerta sobre desviaciones de infraestructura. Ayuda a detectar, rastrear y generar alertas sobre desviaciones en recursos administrados y no administrados. Probémosla con nuestro ejemplo. Nota: driftctl es el motor de detección de desviaciones de código abierto de Snyk.

1$ driftctl scan --deep
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_s3_bucket:
6    - drift-example-un-managed-resource
7Found changed resources:
8  From tfstate://terraform.tfstate
9    - drift-example-managed-resource (aws_s3_bucket.example):
10        ~ versioning.0.enabled: true => false
11Found 2 resource(s)
12 - 50% coverage
13 - 1 resource(s) managed by Terraform
14     - 1/1 resource(s) out of sync with Terraform state
15 - 1 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider
17Scan duration: 17s
18Provider version used to scan: 3.74.3. Use --tf-provider-version to use another version.

Este resultado nos indica que driftctl encontró nuestros dos recursos. En el administrado encontró un atributo con una desviación: el estado del control de versiones. El otro recurso es nuestro bucket de S3 no administrado.

Ventajas:

• Detecta atributos desviados en recursos administrados con el driftctl scan --deep command

• Detecta desviaciones en recursos no administrados con el driftctl scan command

• Admite analizar varios archivos de estado

Desventajas:

• El análisis en modo --deep puede tardar mucho, ya que enumera todos los recursos de una cuenta y obtiene los detalles de cada uno

• Pueden ocurrir errores de limitación de solicitudes de la API durante el análisis, porque depende mucho de la API del proveedor de nube para recopilar toda la información

• No admite todos los recursos de Terraform

Consideraciones sobre las herramientas para detectar desviaciones

Estas tres herramientas hacen muy bien su trabajo. Veamos qué las hace destacar en situaciones específicas.

El terraform plan comando es una herramienta muy eficaz que puedes usar en una canalización programada para todos tus archivos de estado. Además de permitirte cubrir todos los recursos con la herramienta, ofrece una forma universal y bastante fácil de leer de mostrar los atributos desviados. Su única desventaja es que no puedes agrupar todos tus archivos de estado y ejecutar el comando en un solo lugar para comprobar si hay recursos desviados. Aunque informar sobre recursos no administrados no sea el objetivo de la herramienta, es una función esencial.

Los resultados de la herramienta de línea de comandos de CloudQuery son variados. Por un lado, su comando de enumeración (fetch) es una maravilla tecnológica. Te ofrece gratis una alternativa de código abierto para obtener visibilidad detallada de tu infraestructura en la nube, con SQL como motor de consultas y políticas. Por otro lado, su comando de detección de desviaciones es bastante limitado. Según mis pruebas, no puedes confiar en que encuentre desviaciones en recursos administrados. Además, solo puedes usar esta herramienta para encontrar recursos no administrados si tienes una situación sencilla: puedes acceder al archivo de estado de forma local (la mayoría de las veces, para probar la herramienta) o mediante un bucket de S3 (la práctica recomendada si quieres probarla en una CI). Por suerte, su comando de detección de desviaciones todavía está en fase alfa, así que tengo muchas ganas de ver cómo evoluciona esta herramienta de línea de comandos.

Si integras driftctl en tu CI y lo ejecutas a diario, tendrás una forma continua de recibir alertas sobre desviaciones en recursos administrados y no administrados. La variedad de backends compatibles para almacenar archivos de estado la convierte en una buena opción para la mayoría de las infraestructuras. Además, al igual que con CloudQuery, puedes filtrar u omitir los recursos que no te interesan para obtener un informe a tu medida. Una debilidad importante, relacionada con el diseño de driftctl, es que puede ser difícil ejecutarlo sin problemas en infraestructuras grandes debido a la limitación de solicitudes de la API. Por último, el tiempo de ejecución en modo --deep puede ser molesto al hacer pruebas locales en infraestructuras grandes; en una canalización de CI es menos problemático.

Por último, pero no menos importante: los permisos. Ni driftctl ni CloudQuery necesitan tu código de Terraform para funcionar; solo necesitan el archivo de estado, lo que simplifica las cosas. Ambas respetan la práctica recomendada de usar el mínimo de permisos necesarios para analizar todo tu proveedor de nube, así que para ejecutar cualquiera de los dos comandos solo necesitas una política de solo lectura. Obviamente, esto no aplica al comando de Terraform, ya que requiere permisos de lectura y escritura para crear, actualizar y eliminar tu infraestructura, y debe leer tu código para saber qué implementar o quitar.

Lo que sigue para Snyk IaC

Si te interesa incorporar los recursos no administrados al control de IaC y, al mismo tiempo, detectar desviaciones en los recursos administrados, Snyk te ayuda a hacerlo. La administración de desviaciones en Snyk IaC te permite proteger la infraestructura más rápido al informar sobre problemas y soluciones directamente a los desarrolladores, con términos fáciles de entender. Al crear un ciclo de retroalimentación más rápido entre los equipos de seguridad en la nube y desarrollo, los desarrolladores podrán hacerse cargo de su Terraform, desde el código hasta la nube, y proteger las configuraciones de infraestructura después de su implementación. Además, muestra los recursos no administrados en distintos entornos de nube, para que puedas incorporarlos al control de IaC y reducir el riesgo de desviaciones desde el inicio.

Recursos adicionales sobre la administración de desviaciones

Para seguir aprendiendo sobre la administración de desviaciones en Terraform, publicamos algunos artículos más en nuestro blog:

• Administrar varias versiones de Terraform

• Administrar varios entornos de Terraform

• Importar infraestructura existente a Terraform

• Detectar y prevenir desviaciones de configuración