Como verificar a segurança de IaC do Terraform no CI/CD com Regula e Bitbucket Pipelines [Tutorial]

Regula 2.3.0 permite que equipes de cloud avaliem códigos de infraestrutura como código (IaC) em Terraform, CloudFormation, Azure Resource Manager e Kubernetes em busca de violações de segurança e conformidade antes da implantação. Integrar o Regula aos pipelines de integração contínua/entrega contínua (CI/CD) vai além: automatiza a implantação segura da infraestrutura em cloud.

Nesta publicação, vamos demonstrar como integrar o Regula ao Bitbucket Pipelines (serviço de CI/CD integrado ao Bitbucket) para testar automaticamente recursos da Amazon Web Services (AWS) declarados em Terraform. Ao fazer um commit no repositório que contém o Terraform, vamos acionar uma build no Bitbucket Pipelines. Vamos mostrar como o Regula detecta uma vulnerabilidade de segurança e faz a build de CI falhar — e como corrigir a violação para que a build seja aprovada.

Ao final, o pipeline de CI/CD executará o seguinte fluxo:

1. Você faz commit de IaC em uma branch (neste exemplo, faremos commit na branch main por simplicidade, mas também é possível fazer isso — e personalizar o processo — para pull requests).

2. Você envia os commits, acionando uma build no Bitbucket Pipelines.

3. O Bitbucket Pipelines executa o Regula no seu repositório (neste exemplo, também incluímos verificações de formatação e validação do Terraform para demonstrar as melhores práticas).

4. Se a IaC do seu repositório passar em todas as verificações do Regula, a build do Bitbucket Pipelines será bem-sucedida. Caso contrário, falhará.

Dica: Cada ferramenta de CI/CD é diferente, mas você ainda pode seguir as etapas acima para verificar sua IaC no CI/CD com o Regula.

Pré-requisitos

Para acompanhar, você precisará de:

• Uma conta do Bitbucket (na nuvem do Bitbucket ou no Bitbucket Server)

• Autenticação multifator ativada na sua conta do Bitbucket

• Uma conta de provedor de cloud e credenciais adicionadas ao Bitbucket como variáveis do repositório (nesta demonstração, usarei a AWS)

• Um repositório do Bitbucket, clonado localmente, com recursos de cloud declarados em Terraform (veja abaixo a estrutura do meu repositório)

O que há no repositório?

A imagem acima mostra visualmente a estrutura de arquivos do repositório, que contém principalmente:

• main.tf: um arquivo Terraform que declara informações do provedor e da conta

• ec2/instance.tf: um arquivo Terraform que contém uma vulnerabilidade intencional

• .regula.yaml: um arquivo de configuração do Regula que declara como quero executar o Regula neste repositório

• bitbucket-pipelines.yml: um arquivo de configuração do Bitbucket Pipelines

Configurar o Bitbucket Pipelines

Agora vamos configurar o Bitbucket Pipelines para executar builds do nosso repositório. No repositório do Bitbucket, clique em “Repository Settings” no lado esquerdo da página. Em seguida, role até o fim do menu à esquerda até a seção “Pipelines”. Clique em “Settings” e depois no botão ao lado de “Enable Pipelines” para deixá-lo verde, com uma marca de seleção branca.

Os arquivos

Vamos analisar os arquivos do nosso repositório, começando por ec2/instance.tf.

O Terraform vulnerável

O arquivo Terraform em linguagem HashiCorp Configuration Language (HCL) ec2/instance.tf declara os seguintes recursos da AWS:

• Uma instância do Elastic Compute Cloud (EC2)

• Uma função do Identity and Access Management (IAM) para acessar a instância EC2 acima

Para demonstrar a simplicidade e o poder do Regula, incluí intencionalmente vulnerabilidades de segurança na instância EC2, além de comentários com dicas para corrigi-las. (Observação: não implante este Terraform na AWS sem corrigir as violações de segurança.) Vamos analisar essas vulnerabilidades:

resource "aws_instance" "app_server18391111" {
    ami           = "ami-074cce78125f09d61"
    instance_type = "t2.micro"

    # Un-comment below to satisfy FG_R00253
    #iam_instance_profile = aws_iam_instance_profile.test_profile.name

    # Make the below declaration = false to satisfy FG_R00271
    associate_public_ip_address = true

    tags = {
        Name = "ExampleAppServerInstance18391111"
        Team = "dev"
    }
}

• A linha 9 (atualmente comentada) associa nossa instância EC2 à função do IAM e ao perfil da instância que devem ser usados para acessá-la, em vez de chaves de acesso do IAM. Se você passar as informações da função para uma instância EC2 durante a inicialização, poderá limitar o risco de exposição das chaves de acesso e ajudar a impedir que um usuário mal-intencionado comprometa a instância

• A linha 12 declara que a instância EC2 deve ter um endereço IP público associado. Isso pode permitir que usuários não autorizados acessem sua instância EC2, mesmo com listas de controle de acesso à rede ou grupos de segurança

Implantar esta instância EC2 em produção sem alterações nos deixaria expostos a agentes mal-intencionados, que poderiam detectar e explorar a vulnerabilidade usando ferramentas de automação muito antes de sequer sabermos que ela existe! Felizmente, o Regula inclui centenas de regras para analisar nossa IaC em busca de violações dos benchmarks do Center for Internet Security (CIS).

Configuração do Bitbucket Pipelines

Vamos entender como o arquivo bitbucket-pipelines.yml indica ao Bitbucket Pipelines o que fazer quando uma build é acionada. Primeiro, informamos ao Bitbucket que este é um pipeline e, especificamente, o pipeline padrão (você pode criar pipelines separados para pull requests, diferentes branches do repositório e outros casos):

pipelines:
 default:

Optei por executar as etapas abaixo em sequência, mas também posso executá-las em paralelo adicionando o comando parallel à coluna à esquerda das etapas.

Em seguida, declaro a primeira etapa, que usa a imagem do HashiCorp Terraform para inicializar o Terraform, ajustar a formatação ao padrão canônico de HCL e verificar se o Terraform é válido (por exemplo, confirmando que declarei todas as variáveis e os módulos):

- step:
    name: 1 - Initialize, Format, and Validate Terraform
    image: hashicorp/terraform
    script:
        - terraform init && terraform fmt
        - terraform validate

A segunda etapa do pipeline aproveita o Regula para detectar automaticamente todos os arquivos de IaC (Terraform, CloudFormation, Azure Resource Manager e manifestos do Kubernetes) no diretório raiz ou em qualquer subdiretório e analisar cada arquivo encontrado no repositório segundo os padrões de benchmark do CIS (Fugue oferece suporte integrado a outras estruturas de conformidade, como SOC 2, HIPAA e NIST 800-53).

- step:
    name: 2 - Scan Terraform Locally for Security and Compliance with CIS Benchmarks
    image: fugue/regula
    script:
        # Run in root directory first
        - regula run ./
        # Run in child directories next
        - regula run ./*/

A etapa final inicializa o Terraform novamente e usa mais uma vez a imagem do HashiCorp Terraform, porque cada etapa no pipeline do Bitbucket é executada em um contêiner Docker separado e, por isso, as dependências declaradas não são mantidas entre as etapas. Por fim, essa etapa cria um plano do Terraform e o aplica:

- step:
    name: 3 - Plan and Apply Secure, Valid Terraform
    image: hashicorp/terraform
    deployment: Production
    trigger: manual
    script:
        - terraform init
        - terraform plan
        - terraform apply -auto-approve

Iniciar uma build

Testando uma build (e vendo-a falhar) — depois de editar meu repositório com arquivos de IaC, começo inserindo os seguintes comandos no terminal:

git add 
git commit -m "initiating the bitbucket pipeline"
git push

Ao detectar um novo commit no meu repositório (ou receber um comando manual), o Bitbucket Pipelines aciona o pipeline descrito no arquivo .yml acima. Veja o que acontece quando tento fazer commit na branch main do repositório com um Terraform que viola os benchmarks do CIS:

Corrigir problemas de configuração com o Regula

Agora que sei que há configurações incorretas nos meus arquivos Terraform, posso voltar ao repositório e executar o Regula localmente para corrigi-las. Configurei este repositório para facilitar a reativação dos comentários no código Terraform com as correções, mas configurar corretamente sua infraestrutura é tão simples quanto clicar no link da documentação de correção da regra Fugue, exibido após cada violação quando você executa regula. Veja como corrigi as regras Fugue FG_R00253 e FG_R00271 e depois verifiquei novamente minha infraestrutura com uma última execução do regula.

Testando uma build (e vendo-a ser aprovada!)

Com a infraestrutura configurada corretamente, vou fazer outro commit no meu repositório do Bitbucket para aproveitar ao máximo a automação oferecida pelo pipeline que configurei.

Vou executar novamente os comandos que usei no início…

git add 
git commit -m "initiating the bitbucket pipeline"
git push

…e a build será aprovada:

E pronto! Agora temos um pipeline do Regula com Bitbucket para automatizar com segurança a implantação da infraestrutura em cloud usando Terraform.

Executar o Regula localmente

Felizmente, você não precisa esperar o Bitbucket Pipelines (ou outra ferramenta de CI/CD) encontrar os erros. Você pode executar o Regula localmente antes de fazer commit e enviar suas alterações — e recomendamos que faça isso! Meu favorito é o hook de pre-commit do Regula, que coloca em prática a defesa em profundidade, exigindo que os desenvolvedores corrijam violações de segurança e conformidade antes de fazer commit do código. Ao detectar problemas mais cedo no ciclo de desenvolvimento, você antecipa a segurança, acelera o desenvolvimento e economiza tempo, dinheiro e frustração mais adiante.

Primeiro, instale o Regula localmente. Ele é um binário independente e autocontido, então não é necessário instalar pré-requisitos. Basta seguir as etapas da documentação para seu sistema operacional.

Em seguida, no diretório raiz do repositório, execute o mesmo comando usado pelo Bitbucket Pipelines:

regula run

Você verá a mesma saída dos logs do Bitbucket Pipelines. Mas, ao executar localmente, você economiza minutos de build e distribui as responsabilidades das equipes de segurança entre os desenvolvedores, reduzindo — ou até eliminando — gargalos de segurança antes da implantação.

Próximos passos

Quer saber mais sobre o Regula? Confira nosso repositório no GitHub e a documentação. O Regula avalia arquivos Terraform HCL, JSON de planos do Terraform, YAML/JSON do CloudFormation, manifestos YAML do Kubernetes e modelos do Azure Resource Manager em busca de problemas de segurança e conformidade. O Regula também oferece suporte a exceções, regras personalizadas, ativação ou desativação de regras e muito mais.

Quer conhecer outras maneiras de automatizar a implantação segura da infraestrutura em cloud? Confira nossa publicação sobre a integração do Regula ao Travis CI.