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

No desenvolvimento, você usa algum provedor de nuvem de infraestrutura. E é provável que você automatize partes da infraestrutura usando a infraestrutura como código (IaC), de forma que as implantações sejam repetíveis, consistentes, facilmente implantáveis e mais seguras em geral, já que o código torna os parâmetros mais visíveis.

No final, todos nós acabamos com recursos ativos no provedor de nuvem, mas podemos ou não saber o estado atual de todos eles. Alguém alterou manualmente uma configuração de bucket do S3? Uma pessoa da equipe criou um novo caminho na implantação do API Gateway? Como saber se alguns recursos padrão não estão configurados incorretamente? E, no final das contas, você acaba com recursos residentes na conta do provedor de nuvem indisponíveis na implantação do Terraform ou que foram modificados ou excluídos completamente. Essa lacuna entre como pensamos que os recursos de nuvem estão configurados e como realmente estão é conhecida como descompasso de infraestrutura.

O Snyk Infrastructure as Code (Snyk IaC) agora detecta todos os tipos de desvios de infraestrutura e os relata como recursos do Terraform para que os desenvolvedores obtenham visibilidade completa e possam remediá-los logo no início. Isso inclui alterações ou exclusões de recursos “gerenciados” (recursos realmente implantados pela IaC) e “não gerenciados” (aqueles que ainda não estão sob o controle da IaC).  Os relatórios gerados pelo Snyk CLI podem ser lidos diretamente no terminal, integrados a um pipeline ou uma verificação recorrente ou exportados como HTML para compartilhamento com outras pessoas.

A Snyk oferece suporte a todos os estados do Terraform e armazena esses arquivos localmente em todos os armazenamentos blob, como Amazon S3, GCS, Azure, HTTPS, Terraform Cloud e muitos outros. O armazenamento pode ser combinado para refletir a estrutura da sua IaC, quer você tenha vários repositórios do Terraform em várias equipes, quer um modelo mais centralizado.  Por fim, ele funciona em todos os principais provedores de nuvem (AWS, GCP e Azure) e requer o mínimo de direitos de acesso possível.

Neste post, vamos alguns dos problemas que o gerenciamento de desvios do Snyk IaC é capaz de resolver, entre eles:

• Aumentar a cobertura da IaC nos seus ambientes de nuvem

• Informar desvios de infraestrutura em um recurso ou aplicativo

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

Benefícios do gerenciamento de desvios

Este relato envolve um serviço e vários recursos. Vamos usar uma implantação do API Gateway como um exemplo fácil. Na AWS, a experiência é perfeitamente integrada ao console da Web. No Terraform, ela é dividida em 10 a 25 recursos, dependendo da versão do API Gateway. Seus métodos, suas respostas, os modelos, as rotas e os estágios... todos eles são recursos diferentes.

Isso significa que, se você está começando a escrever o código do Terraform a partir de serviços existentes, ter uma lista completa de recursos não gerenciados pelo Terraform categorizados por serviço de nuvem e tipo de recurso os tornará muito visíveis e poupará bastante do seu tempo, já não será preciso observar como a funcionalidade de cada serviço de nuvem está estruturada no Terraform.

Se já temos nosso API Gateway sob controle no Terraform, nada impede que alguém adicione uma rota ou uma resposta HTTP manualmente, e talvez ninguém sequer venha a saber disso. A detecção de desviosgarante que essas alterações sejam detectadas e relatadas para atenuar possíveis inconsistências ou problemas de configuração.

Resumindo, queremos tornar os desvios visíveis para:

• Melhorar a cobertura de código para que o código possa ser analisado em busca de erros de configuração antes da implantação.

• Tomar medidas imediatas, como excluir o recurso ou reverter a alteração antes que os danos possam se materializar.

Aumentar sua cobertura de IaC

Se a sua empresa é como muitas outras por aí, provavelmente você ainda não tem tudo coberto nos muitos repositórios do Terraform que utiliza e compartilha entre as equipes. Então, como funciona a detecção de recursos não gerenciados no Snyk IaC?

O Snyk IaC combina em um grande mapa agregado todos os estados do Terraform que você fornece para ele e os compara com o que ele encontra na sua conta da AWS. A diferença são desvios, relatados como recursos do Terraform.

O comando describe do Snyk IaC com a opção --only-unmanaged nos ajuda a fazer essa comparação:

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%

Os desenvolvedores podem aproveitar o resultado sem dificuldade:

• Sabemos desde o princípio que a cobertura de código é de 44%, o que facilita o acompanhamento do progresso na jornada para a IaC.

• Existem dois buckets do S3 (digite: aws_s3_bucket) que não estão no Terraform e recebemos seus nomes. Podemos optar por importá-los ou excluí-los.

• Existem algumas inconsistências na configuração do IAM: 

  • Um usuário do IAM “labs” foi criado manualmente (digite: aws_iam_user_policy). – O que este usuário está fazendo?

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

  • Uma política do IAM completa foi adicionada manualmente (digite aws_iam_user_policy). Quem controla seu conteúdo caso alguém o altere?

Informar o que mudou desde a última implantação

Outro caso de uso comum para desenvolvedores é o gerenciamento de desvios em um escopo específico. Muitas vezes, os desenvolvedores são responsáveis por uma determinada funcionalidade com um escopo de infraestrutura bem definido. Precisamos detectar o que mudou no escopo do conteúdo definido, mas sem receber feedback de toda a conta da nuvem.

Uma primeira oportunidade aqui é simplesmente inserir todos os estados do Terraform no Snyk IaC e descobrir quais recursos estão faltando ou 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%

Esse relatório nos traz algumas informações interessantes:

• Podemos agregar todos os estados do Terraform que usamos, mas obter informações de desvios apenas para esse perímetro.

• O relatório mostra em qual estado do Terraform cada descompasso ou alteração se encontra.

• Esse recurso é leve, pois requer apenas os direitos de acesso mínimos na conta da nuvem. Não use mais as credenciais de implantação de CI/CD do Terraform!

Detectar recursos ausentes em um serviço de nuvem

Os desenvolvedores podem ter interesse em verificar apenas um serviço de nuvem com mais precisão. Vamos supor que seja o “S3” ou o “IAM”. Podemos usar os filtros de recursos do Snyk IaC para isso (--filter="aws_resource_name"), mas essa abordagem nos obriga a conhecer e listar todos para manter a lista atualizada. Que saco! É nessa hora que usamos a opção --service para incluir um serviço completo sem a necessidade de 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.

Nesse caso de uso, obteremos um relatório de qualquer coisa encontrada no serviço AWS IAM. São dezenas de recursos do Terraform facilmente cobertos de uma só vez (chaves de acesso, grupos, anexos, políticas, funções, etc.).

Gerenciamento de desvios agora disponível no Snyk IaC

Mesmo que você ainda esteja dando os primeiros passos no desenvolvimento com a IaC ou faça parte de uma equipe experiente com fluxos da IaC estabelecidos e sofisticados, o gerenciamento de desvios no Snyk IaC pode a aumentar a visibilidade do que está realmente em execução nas suas contas de nuvem e também ajudar a tomar medidas rapidamente, usando os direitos de acesso mais baixos possíveis.

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

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