Desarrollo de reglas de IaC personalizadas con Snyk

En un mundo cada vez más nativo de la nube, la infraestructura como código (IaC) suele ser el primer punto de entrada a una aplicación. Y, dado que tecnologías como Kubernetes y Terraform son cada vez más populares, la mayoría de los desarrolladores de aplicaciones actualizarán al menos un recurso de Kubernetes o Terraform en algún momento de su carrera.

Aunque actualizar y mantener la infraestructura puede ser tan sencillo como administrar unos cuantos archivos de configuración, o tan complejo como orquestar una arquitectura compleja con varias pilas nativas de la nube, hay algo que siempre se cumple: la seguridad de la infraestructura es fundamental para la seguridad de las aplicaciones. Y aunque muchos proveedores de nube y herramientas de análisis de IaC incluyen conjuntos de reglas de configuración y seguridad, ya sea integrados o aportados por la comunidad, la infraestructura suele ser demasiado diversa y compleja para aplicar un enfoque único que proteja todo.

En este artículo, te guiaré para proteger tu entorno de infraestructura con reglas personalizadas de Snyk IaC. Con el SDK de reglas de Snyk IaC (snyk-iac-rules), ahora puedes escribir, probar y empaquetar reglas de infraestructura personalizadas para la CLI de Snyk.

Mayor flexibilidad con Open Policy Agent (OPA)

En segundo plano, Snyk IaC usa Open Policy Agent (OPA), un agente general de políticas de código abierto, y su lenguaje Rego para definir reglas personalizadas. Como agente independiente de cualquier framework, OPA facilita que los equipos modifiquen y apliquen políticas en toda su pila nativa de la nube, ya sea para la infraestructura, la autorización de aplicaciones o el control de admisión de Kubernetes.

Como las reglas se escriben en el lenguaje de consulta nativo de OPA, también se pueden exportar y reutilizar fuera de Snyk. Esto significa que cualquier inversión que hagas aquí se puede aprovechar en todo el ecosistema de integraciones de OPA.

Para seguir esta guía, necesitarás conocimientos básicos de OPA, así como de WebAssembly (Wasm) y los artefactos OCI, que usamos para empaquetar y distribuir las reglas.

Protege mejor con reglas personalizadas

Las reglas personalizadas te permiten adaptarte a cada caso de uso específico, por lo que son una herramienta poderosa cuando se combinan con conjuntos de reglas predefinidas y modeladas frente a amenazas por expertos en seguridad.

Como ejemplo de una regla personalizada, supongamos que soy arquitecto de seguridad y tengo un requisito interno específico: todos los recursos Terraform aws_iam_role de nuestra aplicación deben incluir las etiquetas owner, description y type.

Esto significa que quisiera ejecutar una regla que:

• Verifique que todos los recursos de roles de IAM actuales o futuros tengan las etiquetas owner, description y type

• Notifique a los desarrolladores de aplicaciones cuando olviden agregar etiquetas.

También quisiera configurar nuestro proceso de CI/CD para que falle cuando se realice un cambio de código que no cumpla con este estándar, y así evitar que llegue a nuestros entornos de producción.

¿Cómo lo haría? La respuesta es configurar la CLI de Snyk para que se ejecute en mi proceso de CI/CD con un conjunto personalizado de reglas que escribo, empaqueto y publico en un lugar seguro de mi elección.

Desarrollar una regla de IaC personalizada con Snyk

Con el nuevo SDK de reglas de Snyk IaC, puedo hacerlo exactamente así. Lo instalo en mi equipo y, con ayuda de la documentación sobre reglas personalizadas, puedo aplicar rápidamente mi nuevo estándar de etiquetado en la CLI de Snyk.

Tomemos como ejemplo el siguiente recurso de Terraform, que quiero que incluya las etiquetas owner, description y type:

1resource "aws_iam_role" "denied" {
2  name = "denied"
3  assume_role_policy = jsonencode({
4      Version   = "2012-10-17"
5      Statement = [
6        {
7          Action    = "sts:AssumeRole"
8          Effect    = "Allow"
9          Sid       = ""
10          Principal = {
11            Service = "ec2.amazonaws.com"
12          }
13        },
14      ]
15  })
16  tags = {
17    description = "a tag that describes something"
18  }
19}

Siguiendo la guía de inicio de la documentación sobre reglas personalizadas, ejecuto el comando template para generar una regla básica:

1$ snyk-iac-rules template --rule CUSTOM-RULE-8

Quiero que el estándar de etiquetado sea una regla de severidad media, así que modifico la plantilla y personalizo el título y el mensaje:

1package rules
2
3aws_iam_role_tags_missing(resource) {
4    not resource.tags.owner
5}
6
7aws_iam_role_tags_missing(resource) {
8    not resource.tags.description
9}
10
11aws_iam_role_tags_missing(resource) {
12    not resource.tags.type
13}
14
15deny[msg] {
16    resource := input.resource.aws_iam_role[name]
17    aws_iam_role_tags_missing(resource)
18
19    msg := {
20        "publicId": "CUSTOM-RULE-8",
21        "title": "IAM Role missing one of the required tags: owner, description or type",
22        "severity": "medium",
23        "msg": sprintf("input.resource.aws_iam_role[%s].tags", [name]),
24        "issue": "",
25        "impact": "",
26        "remediation": "",
27        "references": [],
28    }
29}

Antes de empaquetar y publicar la regla, escribo algunas pruebas unitarias para verificar su comportamiento y coloco mi archivo de ejemplo de Terraform en el archivo generado ./rules/CUSTOM-RULE-8/fixtures/denied2.tf:

1package rules
2
3import data.lib
4import data.lib.testing
5
6test_CUSTOM_RULE_8 {
7        # array containing test cases where the rule is allowed
8        allowed_test_cases := []
9
10        # array containing cases where the rule is denied
11        denied_test_cases := [{
12            "want_msgs": ["input.resource.aws_iam_role[denied].tags"],
13            "fixture": "denied2.tf",
14        }]
15
16        test_cases := array.concat(allowed_test_cases, denied_test_cases)
17        testing.evaluate_test_cases("CUSTOM-RULE-8", "./rules/CUSTOM-RULE-8/fixtures", test_cases)
18}

Puedes encontrar esta regla y otras más en nuestro repositorio público de GitHub.

1$ snyk-iac-rules test
2PASS: 1/1

Cuando ejecuto las pruebas y confirmo que todas pasan, empaqueto la regla con el SDK e incluso puedo probarla localmente con la CLI de Snyk mediante la marca --rules. Primero, me aseguro de haber iniciado sesión en una organización test-org, desde la que ejecutaré todos mis experimentos con reglas personalizadas de ahora en adelante:

1$ snyk auth

Luego, compilo el paquete de reglas personalizadas y lo paso a la marca --rules para asegurarme de que se detecten mis problemas de IaC:

1$ snyk-iac-rules build .
2Generated bundle: bundle.tar.gz
3
4$ snyk iac test --rules=bundle.tar.gz ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
5
6Testing ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf...
7
8Infrastructure as code issues:
9  ✗ IAM Role missing one of the required tags: owner, description or type [Medium Severity] [CUSTOM-RULE-8]
10    introduced by input > resource > aws_iam_role[denied] > tags
11
12Organization:      test-org
13Type:              Terraform
14Target file:       ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
15Project name:      fixtures
16Open source:       no
17Project path:      ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
18
19Tested ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf for known issues, found 1 issues

Cuando confirmo que la CLI de Snyk puede interpretar mi regla, la envío a un registro OCI, en este caso DockerHub, y la etiqueto como la primera versión de mis reglas personalizadas. Así, si en el futuro introduzco cambios incompatibles, puedo implementar las reglas gradualmente usando una etiqueta nueva:

1$ snyk-iac-rules push --r docker.io/snykgoof/oci-example:v1 bundle.tar.gz

Por último, aplico el uso de mi nueva regla personalizada en todos los equipos de mi departamento. Para ello, configuro los ajustes de IaC de mi grupo de Snyk mediante la API pública de ajustes de IaC para grupos.

1curl --location --request PATCH 'https://api.snyk.io/v3/groups/<group_id>/settings/iac/?version=2021-11-03~beta' \
2--header 'Content-Type: application/vnd.api+json' \
3--header 'Authorization: token <API key from Snyk>' \
4--data-raw '{
5   "data": {
6         "type": "iac_settings",
7         "attributes": {
8           "custom_rules": {
9             "oci_registry_url": "https://registry-1.docker.io/snykgoof/oci-example",
10             "oci_registry_tag": "v1",
11             "is_enabled": true
12           }
13       }
14   }
15}'

Automaticé todos estos pasos con un flujo de trabajo de GitHub Actions, como puedes ver en nuestro repositorio público de GitHub. Ahora, cualquier desarrollador de aplicaciones o proceso de CI/CD autenticado con una organización dentro de mi grupo usará mi regla personalizada. Para obtener más información sobre cómo integrar la CLI de Snyk y el SDK de reglas de Snyk IaC con GitHub, consulta nuestra documentación.

Si decidimos aplicar distintas reglas personalizadas en diferentes partes de la empresa, también podemos hacerlo mediante la configuración de reglas personalizadas a nivel de organización, para que solo esa organización ejecute un conjunto distinto de reglas. Por ejemplo, para seguir usando la marca --rules y probar mis reglas personalizadas con la CLI de Snyk, configuré mi organización test-org para desactivar los ajustes de reglas personalizadas. Así puedo proporcionar mis propias reglas personalizadas de forma local:

Quizás más adelante decida que el equipo de Platform necesita un conjunto más restrictivo de reglas personalizadas. En ese caso, configuraré su organización para que use otro paquete de reglas personalizadas, almacenado en un artefacto OCI diferente.

Aprovecha las ventajas de las reglas personalizadas de Snyk IaC

Vimos cómo usé el SDK de reglas de Snyk IaC como arquitecto de seguridad para configurar un nuevo conjunto de estándares de seguridad para mi departamento. Ahora veremos cómo me beneficia esta función durante el desarrollo cuando trabajo como desarrollador de aplicaciones.

Supongamos que agrego un nuevo recurso aws_iam_role a la infraestructura Terraform de nuestra aplicación para configurar un nuevo rol de IAM:

1resource "aws_iam_role" "new_role" {
2  name               = "new_role"
3  assume_role_policy = jsonencode({
4    Version   = "2021-11-18"
5    Statement = [
6      {
7        Action    = "sts:AssumeRole"
8        Effect    = "Allow"
9        Sid       = ""
10        Principal = {
11          Service = "ec2.amazonaws.com"
12        }
13      },
14    ]
15  })
16}

Lo probé localmente y confirmé que mi rol de IAM estaba configurado correctamente. Sin embargo, olvidé que mi departamento exige etiquetas muy estrictas para todos nuestros recursos. Cuando voy a abrir una solicitud de incorporación de cambios (PR), veo que el repositorio al que envío los cambios está configurado para ejecutar la acción de GitHub de Snyk IaC, y la verificación falla.

Reviso los resultados y veo que mi nuevo archivo hace que falle la verificación de la PR; más específicamente, a mi recurso le faltan las etiquetas owner, description y type.

Vuelvo a mi código y agrego las etiquetas que faltan. Ahora, después de enviar el cambio y de que se vuelva a ejecutar la verificación de la PR, ¡puedo incorporar el nuevo recurso a nuestro entorno de producción de forma segura y con confianza!

Protege tus aplicaciones con Snyk IaC

Snyk Infrastructure as Code (Snyk IaC) te ayuda a desarrollar rápido sin dejar de protegerte, ya que ofrece a los desarrolladores inteligencia de seguridad y correcciones en línea para Terraform, CloudFormation, configuraciones de Kubernetes y plantillas de ARM que se pueden integrar directamente al código.

Snyk IaC se integra en las herramientas que usan los desarrolladores: sistemas como Terraform Cloud y herramientas de CI/CD, además de herramientas de desarrollo como la administración del código fuente (GitHub, GitLab y Bitbucket) y los IDE.

Puedes comenzar gratis ahora a usar Snyk IaC en nuestra plataforma o descargar la versión más reciente de la CLI de Snyk.