Usa Snyk IaC para detectar desviaciones de infraestructura y recursos no gestionados

En tu trabajo de desarrollo, seguro usas alguna empresa proveedora de infraestructura en la nube. Es muy probable que automatices ciertas secciones de la infraestructura con IaC, por lo que las implementaciones se repiten, son coherentes, sencillas y, en general, más seguras porque gracias al código los parámetros están más visibles.

En definitiva, los recursos están vivos en la empresa proveedora de la nube, pero quizá no sabemos el estado real de todos ellos. ¿Alguien modificó manualmente el estado de la configuración de un bucket de S3? ¿Algún colega creó una nueva ruta en la implementación de API Gateway? ¿Cómo podemos saber si la configuración de los recursos predeterminados no es incorrecta? Con el tiempo, hay recursos en la cuenta de la empresa proveedora de nube que no aparecen en ninguna implementación de Terraform, se modificaron o se eliminaron. Esta diferencia entre cómo creemos que es la configuración de los recursos de nube y cómo realmente están configurados se denomina desviación de infraestructura.

Ahora Snyk Infrastructure as Code (Snyk IaC) detecta todas las clases de desviaciones de infraestructura y las informa como recursos de Terraform, a fin de que los desarrolladores obtengan visibilidad total y puedan remediarlas a tiempo. Esto incluye cambios o eliminaciones de recursos “gestionados” (los implementados de IaC) y “no gestionados” (los que aún no se controlan con IaC).  La CLI de Snyk genera informes que pueden leerse directamente desde la terminal, integrarse al pipeline o verificación recurrente, o exportarse como HTML para compartirlos con otras personas.

Snyk admite todos los estados de Terraform y almacena los archivos de forma local en almacenamientos blob, como Amazon S3, GCS, Azure, HTTPS y Terraform Cloud, entre otros. El almacenamiento puede combinarse para reflejar la estructura de la IaC, ya sea que tengas varios repositorios de Terraform en diferentes equipos o un modelo más centralizado.  Por último, funciona en las principales empresas proveedoras de nube (AWS, GCP y Azure) y solo exige requisitos mínimos de acceso.

En esta publicación de blog, veremos algunos de los problemas de gestión de desviaciones que Snyk IaC puede abordar, entre ellos:

• El aumento de la cobertura de IaC en entornos de nube.

• El informe de desviaciones de infraestructura dentro de una función o aplicación.

• La detección de desviaciones en un servicio de nube específico.

Ventajas de la gestión de desviaciones

Esta es la historia de un servicio y muchos recursos… Para ver un ejemplo sencillo, pensemos en una implementación de API Gateway. En AWS, la experiencia está integrada en la consola web y no hay inconvenientes. En Terraform, se divide en 10 a 25 recursos, según la versión de API Gateway. Los métodos, las respuestas, los modelos, las rutas y las etapas son todos diferentes recursos.

Esto significa que si comienzas a escribir código de Terraform desde servicios existentes, tener una lista completa de recursos de Terraform no gestionados clasificada según el tipo de recurso y de servicio de nube los hará visibles y te permitirá ahorrar mucho tiempo. Ya no deberás buscar cómo se estructura cada funcionalidad de servicio en la nube en Terraform.

Si ya controlas API Gateway en Terraform, nada evitará que alguien agregue una ruta o una respuesta de HTTP manualmente, ¡y nadie se enterará! La detección de desviacionesgarantiza que estos cambios se detecten y se informen a fin de mitigar cualquier posible inconsistencia o problema de configuración.

En definitiva, queremos visibilizar las desviaciones para lograr los siguientes objetivos:

• Mejorar la cobertura del código de modo que este pueda analizarse en busca de configuraciones incorrectas antes de una implementación.

• Actuar de inmediato; por ejemplo, para eliminar el recurso o revertir el cambio antes de provocar algún daño.

Cómo aumentar la cobertura de IaC

La mayoría de los equipos, y quizá tú no eres la excepción, no tienen cobertura sobre todos los repositorios de Terraform que usan y comparten entre los equipos. Entonces, ¿cómo es que funciona la detección de recursos no gestionados en Snyk IaC?

Snyk IaC combinará todos los estados de Terraform que alimentas en un gran mapa de agregación y lo comparará con lo que encuentre en la cuenta de AWS. Las diferencias halladas serán desviaciones, y se informarán como recursos de Terraform.

Con la función describe de Snyk IaC y la opción --only-unmanaged, veremos algo similar a esto:

1$ snyk iac describe --only-unmanaged
2[...]
3Snyk Scanning Infrastructure As Code Discrepancies...
4
5  Info:    Resources under IaC, but different to terraform states.
6  Resolve: Reapply IaC resources or update into terraform.
7
8Unmanaged resources: 5
9
10Service: aws_iam [ Unmanaged Resources: 3 ]
11
12  Resource Type: aws_iam_policy_attachment
13    ID: user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
14
15  Resource Type: aws_iam_user
16    ID: labs
17
18  Resource Type: aws_iam_user_policy
19    ID: dat-user:manuals3policy
20
21Service: aws_s3 [ Unmanaged Resources: 2 ]
22
23  Resource Type: aws_s3_bucket
24    ID: manual-bucket-2022
25    ID: test-resource-exposure-caxyxllsajfrzbwe
26
27Test Summary
28
29  Managed Resources: 4
30  Unmanaged Resources: 5
31
32  IaC Coverage: 44%

Como desarrolladores, podemos aprovechar este resultado:

• Sabemos que la cobertura del código es de 44 %, lo que facilita el control del progreso a IaC.

• Existen dos buckets de S3 (type: aws_s3_bucket) que no están en Terraform, y nos dan los nombres. Será sencillo si deseamos importarlos o eliminarlos.

• La configuración de IAM tiene algunas inconsistencias: 

  • Se creó un usuario de IAM “labs” manualmente (type: aws_iam_user_policy). ¿Qué hace este usuario?

  • Se adjuntó manualmente una política de acceso “Administrator” al usuario de IAM gestionado llamado “user1-84i30k” (type:aws_iam_policy_attachment). ¿Comprenden los equipos qué consecuencias conlleva esto?

  • Se agregó manualmente una política de IAM completa (type aws_iam_user_policy). ¿Quién controla el contenido si alguien lo modifica?

Cómo informar cambios desde la última implementación

Existe otro caso de uso frecuente para los desarrolladores: la gestión de desviaciones en un alcance específico. Con frecuencia, los desarrolladores son responsables de una determinada función en un alcance bien definido de la infraestructura. Necesitamos detectar los cambios en el alcance definido, no necesitamos recibir comentarios de toda la cuenta en la nube.

En primer lugar, podemos ingresar todos los estados de Terraform en Snyk IaC y descubrir qué recursos faltan y, en algunos casos, cuáles de ellos se modificaron:

1$ snyk iac describe --only-managed
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Changed resources: 1
8
9State: tfstate://terraform.tfstate [ Changed Resources: 1 ]
10
11  Resource Type: aws_s3_bucket
12    ID: somebucket-84i30k
13    ~ versioning.0.enabled: false => true
14
15Missing resources: 1
16
17State: Generated [ Missing Resources: 1 ]
18
19  Resource Type: aws_iam_policy_attachment
20    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
21
22Test Summary
23
24  Managed Resources: 3
25  Changed Resources: 1
26  Missing Resources: 1
27
28  IaC Coverage: 75%

La información de este informe es bastante interesante:

• Podemos juntar todos los estados de Terraform que usamos, pero obtener los datos de desviaciones solo de ese perímetro.

• En el informe, se detalla en qué estado de Terraform aparece cada desviación o cambio.

• La función es liviana, ya que solo necesita mínimos derechos de acceso a la cuenta de la nube. Ya no debes usar las credenciales de implementación CI/CD en Terraform.

Cómo detectar recursos faltantes en un servicio de nube

Como desarrolladores, probablemente solo tengamos un único servicio de nube que queremos analizar en detalle, quizá “S3” o “IAM”. Podemos usar los filtros de Snyk IaC para recursos (--filter="aws_resource_name"), pero para ello deberíamos conocer y enumerar todos, y luego mantener la lista actualizada. ¡Es muy aburrido! Por eso usamos la opción --service para incluir el servicio completo sin necesidad de saber cuántos recursos implica.

1$ snyk iac describe --only-managed --service=aws_iam
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Missing resources: 1
8
9State: Generated [ Missing Resources: 1 ]
10
11  Resource Type: aws_iam_policy_attachment
12    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
13
14Test Summary
15
16  Managed Resources: 2
17  Missing Resources: 1
18
19  IaC Coverage: 66%
20  Info: To reach full coverage, remove resources or move it to Terraform.

En este caso de uso, recibiremos un informe de todo lo que se encuentre en el servicio de IAM en AWS. De esta forma, abarcamos varios recursos de Terraform de una sola vez: claves de acceso, grupos, adjuntos, políticas, roles, etc.

La gestión de desviaciones ahora está disponible en Snyk IaC

Sin importar si eres un desarrollador que recién comienza a utilizar IaC o formas parte de un equipo experto que tiene flujos de trabajo de IaC sofisticados y establecidos, con la gestión de desviaciones de Snyk IaC, podrás aumentar la visibilidad de lo que en verdad se ejecuta en las cuentas de nube y podrás actuar rápidamente, aprovechando los mínimos derechos de acceso posibles.

La gestión de desviaciones de Snyk IaC puede ejecutarse de forma local en las computadoras de los desarrolladores según lo necesiten en la CLI, en pipelines CI/CD o como una tarea cron programada para recibir informes específicos (a partir de la versión 1.918.0).

La gestión de desviaciones está disponible en todos los planes de Snyk, incluso en el plan Gratis, por lo que puedes comenzar a proteger la infraestructura como código hoy mismo.