Autorização de Infraestrutura como Código

Entenda os problemas de não possuir um processo de autorização em pipelines de infraestrutra como código e veja uma solução com um bom custo-benefício para mitigar esses problemas

Introdução​

Autorização é sempre um tema delicado, pois envolve a segurança de um software ou processo. Porém, quando falamos de infraestrutura como código, ter guardrails se torna ainda mais importante, pois é possível que um desenvolvedor cometa um erro e acabe expondo dados sensíveis ou até mesmo derrubando um ambiente inteiro.

Pensando em um ambiente corporativo dinâmico, o processo de gerenciamento de software moderno inclui a execução de pipelines de CI/CD para implantação de alterações, tanto de infraestrutura quanto de aplicação. Essas alterações podem ser feitas por desenvolvedores, engenheiros DevOps ou até mesmo por um usuário mal-intencionado.

Com o objetivo de mitigar esses riscos, é possível utilizar ferramentas de autorização que podem ser usadas para validar infraestrutura como código, como por exemplo o Open Policy Agent. O OPA é um motor de políticas open source, leve e de propósito geral, capaz de ser utilizado em diversos cenários como: autorização de APIs e microserviços, admission controller no kubernetes, autorização de tópicos e filas e também autorização de infraestrutura como código.

O problema​

Digamos que você possua em sua empresa um processo de build e deploy, automatizado e bem definido. Para fins demonstrativos, vamos supor que sua pipeline de CI/CD execute usando o Github Actions e esse workflow específico seja responsável de realizar a criação de um bucket s3 em sua conta AWS utilizando Terraform como IaC. Considere este repositório como referência e vamos analisar a estrutura do projeto:

.
├── .github
│   └── workflows
│       └── deploy.yml
└── iac
    ├── .gitignore
    ├── backend.tf
    ├── main.tf
    ├── outputs.tf
    ├── provider.tf
    ├── terraform.tfvars
    └── variables.tf

O diretório .github é responsável por abrigar os workflows de CI/CD, que contem o arquivo de workflow deploy.yml. O diretório iac é responsável por abrigar os arquivos de configuração do Terraform, que são os arquivos backend.tf, main.tf, outputs.tf, provider.tf, terraform.tfvars e variables.tf.

O arquivo deploy.yml é responsável por executar o deploy do bucket s3 na conta AWS. Este workflow é executado quando um push é realizado na branch main. Veja abaixo o conteúdo do arquivo deploy.yml:

name: iac authz example workflow
on:
  push:
    branches:
      - main
    paths-ignore:
      - ".gitignore"
      - "README.md"
permissions:
  id-token: write
  contents: read
env:
  TF_BACKEND: iac-authz-example-tf
  AWS_REGION: ${{ secrets.AWS_REGION }}
defaults:
  run:
    shell: bash
jobs:
  terraform-backend:
    name: Ensure terraform backend
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Create terraform backend
        run: |
          if [[ -z $(aws s3api list-buckets --query 'Buckets[?Name==`${{ env.TF_BACKEND }}`]' --output text) ]]; then
            aws s3 mb s3://${{ env.TF_BACKEND }}
          fi
          aws s3api head-object --bucket bucket-name --key terraform.tfstate || NOT_EXIST=true
          if [ $NOT_EXIST ]; then
            aws s3api put-object --bucket ${{ env.TF_BACKEND }} --key terraform.tfstate            
          fi
  terraform:
    name: Deploy infrastructure
    needs: terraform-backend
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: iac
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Setup terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_wrapper: false
      - name: Terraform fmt
        run: terraform fmt -check
      - name: Terraform init
        run: |
          terraform init -upgrade \
            -backend-config="bucket=${{ env.TF_BACKEND }}" \
            -backend-config="key=terraform.tfstate" \
            -backend-config="region=${{ secrets.AWS_REGION }}"
      - name: Terraform validate
        run: terraform validate -no-color
      - name: Terraform plan
        run: terraform plan -no-color -var-file terraform.tfvars
      - name: Terraform apply
        run: terraform apply -auto-approve -var-file terraform.tfvars
      - name: Terraform outputs
        id: tf-outputs
        run: |
          echo "bucket-arn=`terraform output -raw bucket_arn`" >> $GITHUB_OUTPUT

No arquivo deploy.yml, temos dois jobs, o primeiro é responsável por criar o bucket s3 que será utilizado como backend do Terraform, enquanto o segundo é responsável por executar o deploy do do terraform do projeto em si, neste caso o bucket s3.

Agora, vamos pensar em algumas regras básicas de segurança quando tratamos buckets s3 corporativamente:

• Necessidade de garantir que os buckets sejam privados
• Necessidade de garantir que os buckets sejam criptografados
• Necessidade de garantir que os buckets tenham versionamento habilitado

Podemos denominar que estas regras em conjunto caracterizam uma baseline de segurança especificamente para o recurso s3 da AWS. Não possuir uma autorização na pipeline de infraestrutura que garanta que essas regras estejam sendo aplicadas pode resultar em arquivos sensíveis sendo expostos, perda de arquivos, danos de imagem, danos financeiros e entre outros.

Aplicando autorização de IaC​

Com o entendimento da estrutura do projeto e o problema exposto, vamos partir para uma solução que mitiga estes riscos. A ideia é ter um step no workflow onde podemos validar o plano do terraform a ser executado e aplicar a baseline de segurança.

Política de autorização​

O primeiro passo aqui seria expressar a baseline de segurança do s3 que definimos acima em políticas na linguagem rego, por questões de simplicidade, iremos embutir as políticas de segurança no mesmo repositório do exemplo. Entretanto tenha em mente que em um ambiente corporativo, as políticas de segurança devem ser mantidas em um repositório separado, para que possam ser versionadas, auditadas e fora do alcance de alterações não autorizadas.

Vamos criar um diretório chamado policy e dentro dele um arquivo chamado main.rego com o seguinte conteúdo:

package main

import data.baseline.aws.common
import data.baseline.aws.s3
import future.keywords.if

default allow := false

allow if {
    s3.baseline_valid
}

result["allowed"] := allow
result["violations"] := s3.violations

E também vamos criar um diretório chamado baseline e dentro dele um diretório chamado aws e um arquivo chamado s3.rego que contem a baseline de segurança do s3, com o conteúdo a seguir:

package baseline.aws.s3

import future.keywords.if
import input as tfplan

baseline_valid if {
    s3_bucket_public_access__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_public_access_block"]
    s3_bucket_server_side_encryption_configuration__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_server_side_encryption_configuration"]
    s3_bucket_versioning__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_versioning"]
    s3__public_access_disabled(s3_bucket_public_access__changes)
    s3__bucket_cryptography_enabled(s3_bucket_server_side_encryption_configuration__changes)
    s3__bucket_versioning_enabled(s3_bucket_versioning__changes)
}

violations["S3 - Bucket should block all public access"] {
    s3_bucket_public_access__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_public_access_block"]
    not s3__public_access_disabled(s3_bucket_public_access__changes)
}

violations["S3 - Bucket should be encrypted"] {
    s3_bucket_server_side_encryption_configuration__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_server_side_encryption_configuration"]
    not s3__bucket_cryptography_enabled(s3_bucket_server_side_encryption_configuration__changes)
}

violations["S3 - Bucket should be versioned"] {
    s3_bucket_versioning__changes := [r | r := tfplan.resource_changes[_]; r.type == "aws_s3_bucket_versioning"]
    not s3__bucket_versioning_enabled(s3_bucket_versioning__changes)
}

########################################################
# Baseline: S3 - Bucket should block all public access #
########################################################
s3__public_access_disabled(s3_bucket_public_access__changes) if {
    s3_bucket_public_access__changes[_].change.after.block_public_acls == true
    s3_bucket_public_access__changes[_].change.after.block_public_policy == true
    s3_bucket_public_access__changes[_].change.after.ignore_public_acls == true
    s3_bucket_public_access__changes[_].change.after.restrict_public_buckets == true
}

#############################################
# Baseline: S3 - Bucket should be encrypted #
#############################################
s3__bucket_cryptography_enabled(s3_bucket_server_side_encryption_configuration__changes) if {
    s3_bucket_server_side_encryption_configuration__changes[_].change.after.rule[_].apply_server_side_encryption_by_default[_].sse_algorithm == "AES256"
}

s3__bucket_cryptography_enabled(s3_bucket_server_side_encryption_configuration__changes) if {
    s3_bucket_server_side_encryption_configuration__changes[_].change.after.rule[_].apply_server_side_encryption_by_default[_].sse_algorithm == "aws:kms"
    s3_bucket_server_side_encryption_configuration__changes[_].change.after.rule[_].apply_server_side_encryption_by_default[_].kms_master_key_id != ""
}

s3__bucket_cryptography_enabled(s3_bucket_server_side_encryption_configuration__changes) if {
    s3_bucket_server_side_encryption_configuration__changes[_].change.after.rule[_].apply_server_side_encryption_by_default[_].sse_algorithm == "aws:kms:dsse"
    s3_bucket_server_side_encryption_configuration__changes[_].change.after.rule[_].apply_server_side_encryption_by_default[_].kms_master_key_id != ""
}

#############################################
# Baseline: S3 - Bucket should be versioned #
#############################################
s3__bucket_versioning_enabled(s3_bucket_versioning__changes) if {
    lower(s3_bucket_versioning__changes[_].change.after.versioning_configuration[_].status) == "enabled"
}

Com a política escrita, agora precisamos integrar ao workflow.

Integração com o workflow​

O próximo passo é integrar as políticas criadas no passo anterior com o workflow do Github Actions e forçar a falha caso alguma das políticas não seja atendida. Para isso, precisamos primeiramente realizar a instalação do OPA no workflow, portanto, vamos utilizar o OPA Setup Github Action, conforme abaixo:

- name: Setup OPA
  uses: open-policy-agent/setup-opa@v2
  with:
    version: latest

Em seguida a ideia é obter o resultado enviado pela política de autorização, interpretar e falhar a pipeline caso a política sinalize, conforme a seguir:

- name: Terraform Authz
  run: |
    RESULT=`opa exec --decision main/result --bundle ../policy/ tfplan.json`
    ALLOWED=`echo $RESULT | jq -r '.result[0].result.allowed'`
    VIOLATIONS=`echo $RESULT | jq -r '.result[0].result.violations'`
    if [ "$ALLOWED" == "true" ]; then
      echo "Terraform authz success"          
    else
      echo "Terraform authz failed"
      echo "Security violations: $VIOLATIONS"
      exit 1
    fi

Validando a solução​

Primeiramente, vamos realizar o teste quebrando alguma regra da baseline de segurança. Para isto iremos manipular o arquivo main.tf quebrando as regras a seguir:

• Necessidade de garantir que os buckets sejam privados
• Necessidade de garantir que os buckets tenham versionamento habilitado

Portanto o código ficaria desta maneira:

resource "aws_s3_bucket" "this" {
  bucket = "my-tf-test-bucket-${random_id.this.hex}"
  tags = var.tags
}

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Disabled" # quebrando a baseline
  }
}

resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.this.id
  block_public_acls       = false # quebrando a baseline
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "random_id" "this" {
  byte_length = 8
}

A execução da pipeline se dará desta maneira:

Imagem mostra uma execução de pipeline do github actions com falha no passo Terraform Authz devido as violações encontradas no terraform

Note que a policy executou, identificou problemas de autorização no plano do terraform e impediu que a esteira continuasse com a criação dos recursos. Caso os recursos de acesso público e versionamento não fossem declarados, a pipeline também iria falhar.

Por fim, vamos testar a autorização de IaC com sucesso, para isso, vamos corrigir os problemas de segurança no arquivo main.tf e executar a pipeline novamente:

resource "aws_s3_bucket" "this" {
  bucket = "my-tf-test-bucket-${random_id.this.hex}"
  tags = var.tags
}

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = "Enabled" # corrigir problema de segurança
  }
}

resource "aws_s3_bucket_public_access_block" "this" {
  bucket = aws_s3_bucket.this.id
  block_public_acls       = true # corrigir problema de segurança
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "random_id" "this" {
  byte_length = 8
}

A execução da pipeline se dará desta maneira:

A imagem mostra uma execução de pipeline no github actions com sucesso

Conclusão​

Neste artigo foi apresentado como é possível autorizar infraestrutura como código utilizando o OPA e Github Actions. A solução abordada tem um investimento de tempo relativamente baixo, desta maneira, tem um ótimo custo-benefício para empresas que estão iniciando ou querem iniciar a jornada de autorização de infraestrutura como código.