Detecte desvios na infraestrutura e recursos não gerenciados com o Snyk IaC

Como desenvolvedor, você provavelmente usa algum provedor de nuvem para sua infraestrutura. E é bem provável que automatize partes dela com infraestrutura como código (IaC), para que as implantações sejam repetíveis, consistentes, fáceis de realizar e, no geral, mais seguras, já que o código deixa os parâmetros mais visíveis.

No fim das contas, todos temos recursos ativos no provedor de nuvem, mas nem sempre conhecemos o estado atual de cada um deles. Alguém alterou manualmente uma configuração de um bucket do S3? Um colega criou um novo caminho na implantação do API Gateway? Como saber se algum recurso padrão está configurado incorretamente? Com o tempo, acabamos com recursos na conta do provedor de nuvem que não aparecem em nenhuma implantação do Terraform, foram modificados ou até mesmo excluídos. Essa diferença entre como achamos que os recursos de nuvem estão configurados e como estão realmente configurados é conhecida como desvio de infraestrutura.

O Snyk Infrastructure as Code (Snyk IaC) agora detecta todos os tipos de desvios na infraestrutura e os reporta como recursos do Terraform, dando aos desenvolvedores visibilidade completa para agir desde cedo.Isso inclui alterações ou exclusões de recursos "gerenciados" (recursos realmente implantados a partir de IaC) e "não gerenciados" (aqueles que ainda não estão sob o controle da IaC). Os relatórios gerados pela Snyk CLI podem ser consultados diretamente no terminal, integrados a um pipeline ou verificação recorrente, ou exportados como HTML para compartilhar com outras pessoas.

A Snyk oferece suporte a todos os estados do Terraform e armazena esses arquivos localmente em qualquer armazenamento de blobs, como Amazon S3, GCS, Azure, HTTPS, Terraform Cloud e outros. É possível combinar armazenamentos para refletir a estrutura da sua IaC, seja com vários repositórios do Terraform distribuídos entre equipes ou com um modelo mais centralizado. Por fim, a solução funciona com todos os principais provedores de nuvem — AWS, GCP e Azure — e exige o mínimo possível de permissões de acesso.

Neste artigo, vamos mostrar alguns dos problemas que o gerenciamento de desvios com o Snyk IaC pode resolver, incluindo:

• Ampliar a cobertura de IaC nos seus ambientes de nuvem

• Identificar desvios na infraestrutura associados a um recurso ou aplicativo

• Detectar desvios em um serviço de nuvem específico

Benefícios do gerenciamento de desvios

Esta é a história de um serviço e muitos recursos. Vamos usar uma implantação do API Gateway como exemplo. Na AWS, a experiência é muito bem integrada ao console da web. No Terraform, ela se divide em 10 a 25 recursos, dependendo da versão do API Gateway. Seus métodos, respostas, modelos, rotas, estágios… cada um deles é um recurso diferente.

Se você está começando a escrever código Terraform a partir de serviços existentes, ter uma lista completa de recursos Terraform não gerenciados, categorizados por serviço de nuvem e tipo de recurso, vai deixar tudo muito mais visível e poupar bastante tempo em comparação com a tarefa de entender como cada funcionalidade de serviço de nuvem é estruturada no Terraform.

Mesmo que já tenhamos o API Gateway sob controle no Terraform, nada impede alguém de adicionar manualmente uma rota ou uma resposta HTTP — e talvez ninguém fique sabendo! A detecção de desvios garante que essas alterações sejam detectadas e reportadas, ajudando a evitar possíveis inconsistências ou problemas de configuração.

Em resumo, queremos deixar os desvios visíveis para:

• Ampliar a cobertura do nosso código, para que ele possa ser analisado em busca de configurações incorretas antes da implantação.

• Agir imediatamente, por exemplo, excluindo o recurso ou revertendo a alteração antes que ocorram danos.

Ampliando a cobertura da sua IaC

Como muitas equipes, provavelmente você ainda não cobre tudo nos vários repositórios do Terraform que usa e compartilha entre equipes. Então, como funciona a detecção de recursos não gerenciados no Snyk IaC?

O Snyk IaC combina todos os estados do Terraform que você fornecer em um único mapa agregado e os compara com o que encontra na sua conta da AWS. As diferenças são desvios, reportados como recursos do Terraform.

Usar describe do Snyk IaC com a opção --only-unmanaged ajuda a fazer exatamente isso:

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 desenvolvedores, podemos aproveitar facilmente esse resultado:

• Primeiro, sabemos que a cobertura do nosso código é de 44%, o que facilita acompanhar o progresso rumo à adoção da IaC.

• Há dois buckets do S3 (tipo: aws_s3_bucket) que não estão no Terraform, e seus nomes são exibidos. Podemos optar facilmente por importá-los ou excluí-los.

• Há algumas inconsistências na nossa configuração do IAM:

  • Um usuário do IAM chamado "labs" foi criado manualmente (tipo: aws_iam_user_policy). O que esse usuário está fazendo?

  • Uma política de acesso "Administrator" foi anexada manualmente a um usuário do IAM gerenciado chamado "user1-84i30k" (tipo:aws_iam_policy_attachment). As equipes entendem as consequências disso?

  • Uma política completa do IAM foi adicionada manualmente (tipo aws_iam_user_policy). Quem controla o conteúdo dela se alguém fizer alterações?

Saiba o que mudou desde sua última implantação

Outro caso de uso comum para desenvolvedores é gerenciar desvios em um escopo específico. Muitas vezes, os desenvolvedores são responsáveis por um recurso com um escopo de infraestrutura bem definido. Precisamos detectar o que mudou dentro do escopo definido, sem receber informações sobre a conta de nuvem inteira.

Uma primeira opção é simplesmente fornecer todos os estados do Terraform ao Snyk IaC para descobrir quais recursos estão ausentes e quais foram alterados:

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%

Este relatório traz informações interessantes:

• Podemos agregar todos os estados do Terraform que usamos e obter informações sobre desvios apenas dentro desse escopo.

• O relatório mostra em qual estado do Terraform cada desvio ou alteração foi encontrado.

• Esse recurso é leve e exige apenas as permissões mínimas de acesso à conta de nuvem. Não use mais as credenciais de implantação do Terraform no CI/CD!

Detectando recursos ausentes em um serviço de nuvem

Como desenvolvedores, talvez queiramos analisar com mais precisão apenas um serviço de nuvem, como "S3" ou "IAM". Podemos usar os filtros de recursos do Snyk IaC para isso (--filter="aws_resource_name"), mas precisaríamos conhecer e listar todos eles, além de manter a lista atualizada. Que trabalho! É aí que usamos a opção --service para incluir um serviço inteiro sem precisar saber quantos recursos estão envolvidos.

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.

Neste caso de uso, vamos receber um relatório de tudo o que for encontrado no serviço AWS IAM. São dezenas de recursos do Terraform cobertos de uma só vez (chaves de acesso, grupos, anexos, políticas, funções e muito mais).

O gerenciamento de desvios já está disponível no Snyk IaC

Seja você um desenvolvedor que está começando a trabalhar com IaC ou parte de uma equipe experiente, com fluxos de trabalho de IaC estabelecidos e sofisticados, o gerenciamento de desvios no Snyk IaC pode ajudar a aumentar a visibilidade do que está realmente em execução nas suas contas de nuvem e permitir que você aja rapidamente, com o mínimo possível de permissões de acesso.

O gerenciamento de desvios do Snyk IaC pode ser executado localmente nos laptops dos desenvolvedores sob demanda, usando a CLI, em pipelines de CI/CD ou como tarefas cron agendadas para gerar relatórios específicos (a partir da versão 1.918.0).

O gerenciamento de desvios está disponível em todos os planos da Snyk, incluindo o plano Free. Comece hoje mesmo a proteger sua infraestrutura como código.