Forem: Gabriel de Biasi

Avoid configuration drift on your terraform state when using aws_security_group

Gabriel de Biasi — Tue, 13 Dec 2022 18:13:08 +0000

Terraform is a fantastic tool for provisioning and maintaining infrastructure state, both on-premises and in cloud environments. However, sometimes we go through some situations where we have an expectation that terraform works one way, but terraform ends up working in another way.

That's what happened to me when using the aws_security_group. This resource allows you to create a Security Group within a VPC, which in practice can be applied to other resources, such as EC2 instances, databases, and Kubernetes clusters, to deny connections to specific ports and allow only some specific ports (or none).

My use case was to create a Security Group for an EC2 instance that would work as a simple job processing worker. In summary, because it works in pull-based, this instance would not need to have any ingress (incoming) rules, only one egress (outgoing) rule for any IP.

So, I did it like this:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = aws_vpc.main.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

When running the terraform apply command, I got the following output:

gabriel@machine:~/terraform$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_security_group.sg will be created
  + resource "aws_security_group" "sg" {
      + arn                    = (known after apply)
      + description            = "Managed by Terraform"
      + egress                 = [
          + {
              + cidr_blocks      = [
                  + "0.0.0.0/0",
                ]
              + description      = ""
              + from_port        = 0
              + ipv6_cidr_blocks = []
              + prefix_list_ids  = []
              + protocol         = "-1"
              + security_groups  = []
              + self             = false
              + to_port          = 0
            },
        ]
      + id                     = (known after apply)
      + ingress                = (known after apply)
      + name                   = "my-amazing-security-group"
      + name_prefix            = (known after apply)
      + owner_id               = (known after apply)
      + revoke_rules_on_delete = false
      + tags_all               = (known after apply)
      + vpc_id                 = "vpc-0101010101"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

aws_security_group.sg: Creating...
aws_security_group.sg: Creation complete after 2s [id=sg-0101010101010101]

Excellent! Terraform created the security group and I was able to use it on the EC2 instance I created. However, I realized I had made a mistake while provisioning the EC2 instance and needed to connect to this specific instance using ssh.

To enable this access, I needed to create a new ingress rule on the security group. So, I went directly to the AWS dashboard, and edited the security group manually, allowing connections on port 22 for just my IP Address.

After connecting to the instance and solving the problem, I thought to myself:

I'm gonna run terraform apply again, as terraform will notice the extra rule in the security group and create a plan to remove this rule, right?

So when I ran the command I got the following output:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0101010101010101]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

I was confused. Did terraform not notice the new rule in the security group? I went to the AWS dashboard and saw that the ingress rule was still present! So what?

Then I dig a little further and I understood that the aws_security_group does not maintain the state of the rules, if this is not explicit. That is, we need to make it explicit in the resource definition that we don't want any ingress rules. Correcting our code, it would look like this:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = data.aws_vpc.main.id

  ingress = []    # no ingress rules allowed

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Note that the ingress attribute takes an empty list. This makes it explicit to terraform that we don't want any ingress rules for this security group. Then, running the terraform apply command again, we can finally have the guaranteed state:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0110522c7ec4870d0]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_security_group.sg will be updated in-place
  ~ resource "aws_security_group" "sg" {
        id                     = "sg-0110522c7ec4870d0"
      ~ ingress                = [
          - {
              - cidr_blocks      = [
                  - "169.169.169.169/32",
                ]
              - description      = "My IP"
              - from_port        = 22
              - ipv6_cidr_blocks = []
              - prefix_list_ids  = []
              - protocol         = "tcp"
              - security_groups  = []
              - self             = false
              - to_port          = 22
            },
        ]
        name                   = "my-amazing-security-group"
        tags                   = {}
        # (7 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

aws_security_group.sg: Modifying... [id=sg-0110522c7ec4870d0]
aws_security_group.sg: Modifications complete after 0s [id=sg-0110522c7ec4870d0]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Now, terraform guarantees that this security group does not gain new rules through the AWS dashboard and maintains this state for us!

Automatic SSO in Kubernetes workloads using a sidecar container

Gabriel de Biasi — Mon, 12 Dec 2022 13:01:06 +0000

⚠ This post assumes you have a pretty good knowledge of Kubernetes, Helm, and creating your helm charts by yourself. ⚠

For security reasons, it is quite common the need to protect our workloads in Kubernetes with some kind of authentication, or even using basic auth, for example. However, some applications don't offer this option natively.

We have the basic structure of an application that has to be exposed to the Internet, but still without authentication.

To achieve that, we'll need an Identity Provider and a sidecar container to handle this process for us, without the need to make modifications to our own application. But, how is this possible?? 😧

An IdP provides us the identities to be used. It might be OIDC, AD, Google Workspace, GitHub, Auth0, among others. In this example, we will use a Keycloak instance, which has an IdP configuration with Google Workspace.

The star here is oauth2-proxy. This project provides a super small Docker image (~12.8 MB) that can serve static files directly, or upstream to another web server.

This proxy is fully configurable using environment variables. We can now define, within our helm chart templates, the default settings to use. In this example, if the developer wants to enable this functionality, he can set this value in the values.yaml file as follows:

# chart/values.yaml
authProxy:
  enabled: true

We're gonna need to change the template of the Deployment and the Service. First, let's see what the changes in the Deployment look like.

# chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "chart.fullname" . }}
  labels:
    {{- include "chart.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "chart.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "chart.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: nginx
          image: nginx:1.19
          ports:
            - name: http
              containerPort: {{ .Values.containerPort }}
              protocol: TCP
          envFrom:
            - configMapRef:
                name: {{ include "chart.fullname" . }}
            - secretRef:
                name: {{ include "chart.fullname" . }}
       # ---
       # changes start HERE!
       # ---
       {{- if .Values.authProxy.enabled }}
        - name: auth
          image: quay.io/oauth2-proxy/oauth2-proxy:v7.3.0
          ports:
            - name: auth
              containerPort: 5001
              protocol: TCP
          env:
            - name: OAUTH2_PROXY_HTTP_ADDRESS
              value: ":5001"
            - name: OAUTH2_PROXY_UPSTREAMS
              value: {{ print "http://127.0.0.1:" .Values.containerPort }}
            - name: OAUTH2_PROXY_COOKIE_SECRET
              value: {{ randAlphaNum 32 | quote }}
            - name: OAUTH2_PROXY_COOKIE_NAME
              value: {{ include "chart.fullname" . }}
            - name: OAUTH2_PROXY_SKIP_PROVIDER_BUTTON
              value: "true"
            - name: OAUTH2_PROXY_AUTH_LOGGING
              value: "true"
            - name: OAUTH2_PROXY_REQUEST_LOGGING
              value: "false"
            - name: OAUTH2_PROXY_FORCE_CODE_CHALLENGE_METHOD
              value: "S256"
          envFrom:
            - configMapRef:
                name: {{ include "chart.fullname" . }}
            - secretRef:
                name: {{ include "chart.fullname" . }}
        {{- end }}

Note that if authProxy.enabled is true, a new container is included in the Deployment, called "auth". This container already has some environment variables configured, however, some environment variables are still needed, depending on which provider we use to authenticate.

In this example, we define the environment variables using a mix of ConfigMaps and Secrets, which are referenced in configMapRef and secretRef. You can see all the environment variables available to use in the project documentation.

Now, let's see the changes that we need to do in the Service.

# chart/templates/service.yaml
{{- $targetPort := .Values.authProxy.enabled | ternary "auth" "http") }}
apiVersion: v1
kind: Service
metadata:
  name: {{ include "chart.fullname" . }}
  labels:
    {{- include "chart.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - name: http
      port: {{ .Values.service.port }}
      targetPort: {{ $targetPort | quote }}
      protocol: TCP
  selector:
    {{- include "chart.selectorLabels" . | nindent 4 }}

In the first line, we create a new variable called $targetPort. This variable changes its value depending on the value of authProxy.enabled.

In a nutshell, we switch the value of spec.ports[0].targetPort between http or auth, depending if authProxy.enabled is true or not.

Let's see how these modifications work out together.

Notice that we don't need to make any modifications in the original container, as we are simply proxying the traffic using the sidecar container.

Now, whenever outsider users try to access our application, they are gonna see the Keycloak login page first.

What do you think about this solution? 🤔
Thank you for reading!
🍀🍀🍀

Como a Trybe corrige mais de 20 mil avaliações por semana!

Gabriel de Biasi — Tue, 29 Mar 2022 18:06:46 +0000

Para quem não conhece a Trybe, é uma escola de desenvolvimento web que tem comprometimento genuíno com o sucesso profissional de quem estuda conosco. Com o Modelo de Sucesso Compartilhado (MSC) ofertado pela Trybe Fintech, a pessoa estudante tem a opção de pagar apenas quando já estiver trabalhando, você acredita nesse nível de confiança?

E para isso precisamos ter um infraestrutura para avaliar todos os projetos enviados pelas pessoas estudantes! Hoje utilizamos GitHub Actions, entretanto, usar os executores oferecidos pelo próprio GitHub Cloud não é o suficiente, pois esgotaríamos os minutos oferecidos pelo plano rapidamente.

Simulação de uma pessoa estudante esperando pela sua avaliação

Logo, optamos por manter nossa própria infraestrutura de self-hosted runners, e melhor ainda, tudo orquestrado usando Kubernetes!

Veja na imagem abaixo como é o esquema de funcionamento. Após isso, temos o passo-a-passo explicando o fluxo.

Passo 1: A pessoa estudante envia seu projeto como um pull request no repositório.

Passo 2: De acordo com a configuração do workflow, o trigger é acionado e uma nova avaliação é inserida na fila de workflows do repositório;

Passo 3: Os self-hosted runners funcionam como pull-based, ou seja, eles fazem pulling no GitHub API aguardando por jobs à serem executados.

É possível que não haja runners disponíveis no momento. Então, nós temos um controller que se comunica com o GitHub API sobre a condição atual dos runners. Se não houver runners disponíveis no momento, o controler aciona o Horizontal Runner Autoscaler para escalar para cima o número de runners em nossa infraestrutura.

Ao mesmo tempo, nosso controler também verifica se não temos "runners demais": Se mais de 50% dos runners atuais estão em idle, isso significa que podemos diminuir o número de runners para melhorarmos nossos custos com infraestrutura. O controler aciona o Horizontal Runner Autoscaler para escalar para baixo o número de runners em nossa infraestrutura.

Passo 4: A avaliação é feita utilizando uma série de actions implementados pelo time da Trybe. Essas actions envolvem linters de arquivos, execução do cypress, testes unitários, etc.

Passo 5: Após executar a avaliação, a última action do workflow envia o resultado obtido para o nosso backend de avaliações, para ser armazenado em nosso banco de dados.

Passo 6: Como muitas pessoas estudantes enviam suas avaliações ao mesmo tempo, foi implementado uma solução utilizando Amazon MQ, para enfilieirar o processo de avaliação e também evitar um possível rate limit na API do GitHub.

Passo 7-8: Após processar a avaliação que estava na fila de mensageria, o backend de avaliação faz um comentário no PR da pessoa estudante, informando o resultado!

Bem simples, né? O processo parece ser complicado, mas é necessário pelo tamanho da demanda que temos em corrigir mais de 20 mil avaliações por semana. Agora veja todo o processo em apenas uma figura:

Processo de correção

Gostou do que viu? Quer ajudar a Trybe a manter esta infraestrutura? Venha pois temos várias vagas abertas!!

Evite configuration drift no seu estado de terraform ao usar aws_security_group

Gabriel de Biasi — Tue, 08 Mar 2022 11:02:37 +0000

O terraform é uma ferramenta fantástica para provisionar e manter o estado de uma infraestrutura, tanto on-premises quanto nos ambientes de cloud. Entretanto, algumas vezes passamos por algumas situações que nós temos uma expectativa de que o terraform funcione de uma maneira, porém o terraform acaba funcionando de outra forma.

Foi o que aconteceu comigo ao utilizar o recurso aws_security_group. Este recurso permite criar um Security Group dentro de uma VPC, que na prática pode ser aplicado a outros recursos, como instâncias EC2, banco de dados, clusters Kubernetes, para fechar portas de conexão e liberar apenas algumas portas específicas (ou nenhuma).

Meu caso de uso foi criar um Security Group para uma instância EC2 que iria trabalhar como um worker, ou seja, essa instância iria obter os jobs através de uma fonte externa, realizar o processamento e enviar o resultado. Em resumo, por trabalhar em pull-based, essa instância não precisaria ter nenhuma regra de ingresso (entrada), apenas uma regra de egresso (saída) para qualquer IP.

Logo, fiz o recurso da seguinte maneira:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = aws_vpc.main.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ao executar o comando terraform apply, obtive a seguinte saída:

gabriel@machine:~/terraform$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_security_group.sg will be created
  + resource "aws_security_group" "sg" {
      + arn                    = (known after apply)
      + description            = "Managed by Terraform"
      + egress                 = [
          + {
              + cidr_blocks      = [
                  + "0.0.0.0/0",
                ]
              + description      = ""
              + from_port        = 0
              + ipv6_cidr_blocks = []
              + prefix_list_ids  = []
              + protocol         = "-1"
              + security_groups  = []
              + self             = false
              + to_port          = 0
            },
        ]
      + id                     = (known after apply)
      + ingress                = (known after apply)
      + name                   = "my-amazing-security-group"
      + name_prefix            = (known after apply)
      + owner_id               = (known after apply)
      + revoke_rules_on_delete = false
      + tags_all               = (known after apply)
      + vpc_id                 = "vpc-0101010101"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

aws_security_group.sg: Creating...
aws_security_group.sg: Creation complete after 2s [id=sg-0101010101010101]

Ótimo! O terraform criou o security group e eu pude utilizar na instância EC2 que criei. Entretanto, percebi que tinha cometido um erro ao provisionar a instância EC2 e eu precisava me conectar nessa instância usando ssh.

Para possibilitar o acesso, eu precisava criar a regra de ingresso no security group. Logo, fui diretamente no dashboard da AWS, editei o security group manualmente liberando a porta 22 para apenas o meu IP.

Após me conectar na instância e resolver o problema, pensei: “Vou simplesmente executar terraform apply, pois o terraform irá perceber a regra extra no security group e criar um plano para remover esta regra”. Então, ao executar o comando, obtive a seguinte saída:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0101010101010101]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Na hora fiquei confuso. O terraform não percebeu a regra nova no security group? Fui no dashboard da AWS e vi que a regra de ingresso ainda estava presente! E agora?

Pesquisando melhor, entendi que o recurso aws_security_group não mantém o estado das regras, se isso não for explícito. Ou seja, precisamos deixar explícito na definição do recurso que não queremos nenhuma regra de ingresso. Corrigindo nosso código, ficaria assim:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = data.aws_vpc.main.id

  ingress = []    # explicitamente nenhuma regra de ingresso

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Perceba que o atributo ingress recebe uma lista vazia. Isto deixa explícito que não queremos nenhuma regra de ingresso para este security group. Logo, executando o comando terraform apply novamente, finalmente podemos ter o estado garantido:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0110522c7ec4870d0]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_security_group.sg will be updated in-place
  ~ resource "aws_security_group" "sg" {
        id                     = "sg-0110522c7ec4870d0"
      ~ ingress                = [
          - {
              - cidr_blocks      = [
                  - "169.169.169.169/32",
                ]
              - description      = "My IP"
              - from_port        = 22
              - ipv6_cidr_blocks = []
              - prefix_list_ids  = []
              - protocol         = "tcp"
              - security_groups  = []
              - self             = false
              - to_port          = 22
            },
        ]
        name                   = "my-amazing-security-group"
        tags                   = {}
        # (7 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

aws_security_group.sg: Modifying... [id=sg-0110522c7ec4870d0]
aws_security_group.sg: Modifications complete after 0s [id=sg-0110522c7ec4870d0]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Ufa! Agora sim o terraform nos garante que este security group não ganhe novas regras através do dashboard da AWS e mantenha este estado pra gente.