Desenvolvendo regras personalizadas de IaC com a Snyk

Em um mundo cada vez mais nativo da nuvem, a infraestrutura como código (IaC) costuma ser o primeiro ponto de entrada em uma aplicação. E, com tecnologias como Kubernetes e Terraform se tornando cada vez mais populares, a maioria dos desenvolvedores de aplicações vai atualizar pelo menos um recurso de Kubernetes ou Terraform em algum momento da carreira.

Embora atualizar e manter a infraestrutura possa ser tão simples quanto gerenciar alguns arquivos de configuração — ou tão complexo quanto orquestrar uma arquitetura com várias stacks nativas da nuvem —, uma coisa não muda: a segurança da infraestrutura é essencial para a segurança das aplicações. E, embora muitos provedores de nuvem e ferramentas de análise de IaC ofereçam conjuntos de regras de configuração e segurança integrados ou criados pela comunidade, a infraestrutura costuma ser diversa e complexa demais para uma abordagem única que proteja tudo.

Neste artigo, vou mostrar como proteger seu ambiente de infraestrutura com regras personalizadas do Snyk IaC. Com o SDK de regras do Snyk IaC (snyk-iac-rules), você pode criar, testar e empacotar regras de infraestrutura personalizadas para a Snyk CLI.

Ganhe flexibilidade com o Open Policy Agent (OPA)

Nos bastidores, o Snyk IaC usa o Open Policy Agent (OPA), um agente geral de políticas de código aberto, e sua linguagem Rego para definir regras personalizadas. Como agente independente de frameworks, o OPA facilita a adaptação e a aplicação de políticas em toda a stack nativa da nuvem, seja para infraestrutura, autorização de aplicações ou controle de admissão do Kubernetes.

Como as regras são escritas na linguagem de consulta nativa do OPA, elas também podem ser exportadas e reutilizadas fora da Snyk. Isso significa que todo o investimento feito aqui pode ser aproveitado em todo o ecossistema de integrações do OPA.

Para acompanhar este passo a passo, você precisa ter conhecimentos básicos de OPA, além de WebAssembly (Wasm) e artefatos OCI, que usamos para empacotar e distribuir as regras.

Proteja melhor com regras personalizadas

As regras personalizadas permitem atender a cada caso de uso específico e são uma ferramenta poderosa quando combinadas com conjuntos de regras pré-criados e modelados contra ameaças por especialistas em segurança.

Como exemplo de regra personalizada, imagine que sou arquiteto de segurança e tenho um requisito interno específico: todos os recursos Terraform aws_iam_role da nossa aplicação precisam ter tags de proprietário, descrição e tipo.

Isso significa que eu precisaria executar uma regra que:

• Garanta que todos os recursos de função do IAM, existentes ou futuros, tenham tags de proprietário, descrição e tipo

• Notifique os desenvolvedores de aplicações quando esquecerem de adicionar as tags.

Também quero configurar nosso CI/CD para falhar quando uma alteração no código não seguir esse padrão, evitando que ela chegue aos ambientes de produção.

Como fazer isso? Configurando a Snyk CLI para ser executada no meu CI/CD com um conjunto personalizado de regras, que vou criar, empacotar e publicar em um local seguro à minha escolha.

Desenvolvendo uma regra personalizada de IaC com a Snyk

Com o novo SDK de regras do Snyk IaC, posso fazer exatamente isso. Instalo o SDK na minha máquina e, com a ajuda da documentação sobre regras personalizadas, posso aplicar rapidamente meu novo padrão de tags na Snyk CLI.

Veja como exemplo o recurso Terraform a seguir, que quero incluir as tags owner, description e 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}

Seguindo as instruções para começar na documentação sobre regras personalizadas, executo o comando template para gerar uma regra básica:

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

Quero que o padrão de tags seja uma regra de severidade média. Então, ajusto o template e personalizo o título e a mensagem:

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 empacotar e publicar a regra, escrevo alguns testes unitários para verificar seu comportamento e adiciono meu arquivo Terraform de exemplo ao arquivo ./rules/CUSTOM-RULE-8/fixtures/denied2.tf gerado:

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}

Você encontra esta regra e outras no nosso repositório público no GitHub.

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

Depois de executar os testes e confirmar que foram aprovados, empacoto a regra usando o SDK e também posso testá-la localmente com a Snyk CLI, usando a flag --rules. Primeiro, confirmo que estou autenticado em uma organização test-org, onde pretendo fazer todos os meus testes com regras personalizadas daqui em diante:

1$ snyk auth

Em seguida, crio o pacote das minhas regras personalizadas e o passo para a flag --rules para confirmar que os problemas de IaC são sinalizados:

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

Depois de confirmar que a Snyk CLI consegue interpretar minha regra, envio-a para um registro OCI — neste caso, o DockerHub — e identifico-a como a primeira versão das minhas regras personalizadas. Assim, se eu fizer alterações incompatíveis no futuro, poderei implementá-las gradualmente usando uma nova tag:

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

Por fim, aplico a nova regra personalizada a todas as equipes do meu departamento, configurando as definições de IaC do meu grupo Snyk pela API pública de configurações de IaC do grupo.

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}'

Automatizei todas essas etapas usando um workflow de GitHub Actions, como você pode ver no nosso repositório público no GitHub. Agora, qualquer desenvolvedor de aplicações ou pipeline de CI/CD autenticado em uma organização do meu grupo usará minha regra personalizada. Para saber mais sobre como integrar a Snyk CLI e o SDK de regras do Snyk IaC ao GitHub, consulte nossa documentação.

Se decidirmos aplicar regras personalizadas diferentes em partes distintas da empresa, também podemos substituir as configurações de regras personalizadas no nível da organização e executar um conjunto diferente de regras somente para ela. Por exemplo, para continuar usando a flag --rules e testar minhas regras personalizadas com a Snyk CLI, configurei minha organização test-org para desativar as configurações de regras personalizadas. Assim, posso fornecer minhas próprias regras personalizadas localmente:

No futuro, posso decidir que a equipe de Plataforma precisa de um conjunto de regras personalizadas mais restritivo. Nesse caso, vou configurar a organização dela para usar outro pacote de regras personalizadas, armazenado em um artefato OCI diferente.

Aproveitando os benefícios das regras personalizadas do Snyk IaC

Vimos como eu, na função de arquiteto de segurança, usei o SDK de regras do Snyk IaC para configurar novos padrões de segurança para meu departamento. Agora, vamos ver como eu, como desenvolvedor de aplicações, me beneficio desse recurso durante o desenvolvimento.

Imagine que estou adicionando um novo recurso aws_iam_role à infraestrutura Terraform da nossa aplicação para configurar uma nova função do 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}

Testei tudo localmente e confirmei que minha função do IAM foi configurada corretamente. Porém, esqueci que meu departamento exige tags muito rigorosas para todos os recursos. Quando vou abrir um PR, percebo que o repositório para o qual estou enviando as alterações foi configurado para executar a GitHub Action do Snyk IaC e que ela está falhando.

Analiso os resultados e percebo que meu novo arquivo está fazendo a verificação do PR falhar. Mais especificamente, está faltando a tag owner, description e type no meu recurso.

Volto ao código e adiciono as tags que faltavam. Agora, depois que envio minha alteração e a verificação do PR é executada novamente, posso enviar o novo recurso ao nosso ambiente de produção com segurança e confiança!

Proteja suas aplicações com o Snyk IaC

O Snyk Infrastructure as Code (Snyk IaC) ajuda você a desenvolver com rapidez e segurança, oferecendo aos desenvolvedores inteligência de segurança e correções em linha para Terraform, CloudFormation, configurações de Kubernetes e modelos ARM, que podem ser incorporadas diretamente ao código.

O Snyk IaC se integra às ferramentas que os desenvolvedores já usam, como Terraform Cloud e ferramentas de CI/CD, além de ferramentas para desenvolvedores, como sistemas de gerenciamento de código-fonte (GitHub, GitLab, Bitbucket) e IDEs.

Comece agora gratuitamente a usar o Snyk IaC na nossa plataforma ou baixe a versão mais recente da Snyk CLI.