O foco desse pequeno artigo é enfatizar os pontos de execução de comandos arbitrários dos quais o Atlantis está sujeito pelo Terraform. Ou seja, RCE. Não temos intenção de abordar as mais variadas ferramentas de análise SAST ou algo do tipo. Mas, aproveitar o recurso presente nas imagens Atlantis: o Conftest.

Intro

O Atlantis possui suporte a Conftest por padrão.

O Conftest suporta o arquivo de mudanças (plan) gerado pelo Terraform. Assim como também suporta os códigos HCL do Terraform, mas o padrão tem sido o arquivo de mudanças.

Esse arquivo de mudanças pode ser gerado como demonstrado abaixo:

terraform init -upgrade
terraform plan -input=false -refresh -out $PLANFILE
terraform show -json $PLANFILE > $SHOWFILE

Feito! O primeiro subsídio está disponível. O arquivo $SHOWFILE será bastante útil.

Conftest

O comando Conftest segue no formato abaixo:

conftest test $SHOWFILE --policy policy/ --all-namespaces

Assim, você pode fazer testes localmente se precisar. Se houver dúvidas, você pode consultar por conftest test --help ou a própria documentação oficial.

No Atlantis, segue no modelo similar:

policy_check:
  steps:
    # ...
    - policy_check:
        extra_args: ["--policy /home/atlantis/policy", "--all-namespaces"]

Confira mais sobre na documentação oficial do Atlantis.

Policies

Mas, qual policy usar?

O Conftest utiliza OPA com policies escritas em REGO (pronuncia-se ray-go).

Atualmente, existem bibliotecas que empoderam a confecção de policies. A síntaxe pode ser bastante distinta. Então, dependendo do grau de profundidade, alguns recursos auxiliares e/ou complementares podem contribuir no seu desenvolvimento.

Um outro ponto muito importante sobre segurança é: o terraform plan não está imune a algumas ações mesmo com a presença das policies. No Atlantis, as policies acontecem posteriormente ao plano de mudanças. Então, pode ser necessário controlar o plano de mudança ou personalizar a step do plano de mudança.

Blocklist de providers

Útil para especificar providers Terraform não permitidos.

package main

blocked_providers = {"registry.terraform.io/hashicorp/external"}

caught_providers[provider] = all {
    some provider
    blocked_providers[provider]
    all := [module |
        module := input.configuration.provider_config[_]
        module.full_name == provider
    ]
}

deny[msg] {
    num_resources := caught_providers[provider]
    num_resources > 0
    msg := sprintf("Provider %s detected in Terraform plan file.", [provider])
}

Allowlist de providers

Pode ser uma alternativa melhor. Assim, apenas providers Terraform autorizados passam. Evitando o risco de providers desconhecidos.

package main

allowed_providers = {"registry.terraform.io/hashicorp/aws"}

deny[msg] {
    filtered := [f | f = input.configuration.provider_config[_].full_name; not allowed_providers[f]]
    count(filtered) > 0
    msg := sprintf("Got %d unauthorized provider(s) like %v.", [count(filtered), filtered[0]])
}

Entre outras infinidades de policies

Acima, são exemplos reais. Você também pode incluir policies para null_resources.

É importante entender a diferença entre policies que conduzem adoção de boas práticas e aquelas que tratam questões pontuais.

Você pode utilizar algumas bibliotecas/frameworks de policies prontas. A Regula é um exemplo. Consulte a documentação sobre Regula e Conftest para saber mais. Também há opção para integrar com GitHub Actions diretamente.

Policy para HCL

Como visto anteriormente, pode ser muito útil verificar o manifesto HCL do Terraform. Aqui vai um exemplo simples:

package main

deny[msg] {
  proto := input.data.external[name]
  count(proto) > 0
  msg = sprintf("External '%v' detected in HCL.", [name])
}

Detecção de HCL para fontes de módulos antes do plano? É possível:

package main

allowed_sources = {
    "git@github.com:business/business.git//modules/"
}

deny[msg] {
    module := input.module[name].source
    finding := [trusted | trusted := allowed_sources[_]; not startswith(module, trusted)]
    count(finding) > 0
    msg = sprintf("Unauthorized module.%s source.", [name])
}

O conceito de allowlist aplica-se perfeitamente aqui.

O plano de mudança está sujeito a execução de comandos arbitrários. Portanto, é interessante a ideia de executar a verificação antes do plano de mudança.

E como funcionaria o comando para Conftest nessa estratégia?

conftest test *.tf --policy policy/ --all-namespaces

Portanto, antes de efetivar o plano de mudança no Terraform, execute o teste.

$ conftest test $SHOWFILE *.tf --policy /home/atlantis/policy -n main --output table

+---------+--------------+-----------+--------------------------------+
| RESULT  |     FILE     | NAMESPACE |            MESSAGE             |
+---------+--------------+-----------+--------------------------------+
| success | outputs.tf   | main      | SUCCESS                        |
| success | outputs.tf   | main      | SUCCESS                        |
| success | tests.tf     | main      | SUCCESS                        |
| failure | tests.tf     | main      | External 'example' detected in |
|         |              |           | HCL.                           |
| success | variables.tf | main      | SUCCESS                        |
| success | variables.tf | main      | SUCCESS                        |
| success | showfile     | main      | SUCCESS                        |
| failure | showfile     | main      | Resource 'null_resource'       |
|         |              |           | detected in Terraform plan     |
|         |              |           | file. Denied.                  |
| success | main.tf      | main      | SUCCESS                        |
| success | main.tf      | main      | SUCCESS                        |
+---------+--------------+-----------+--------------------------------+

Também é possível utilizar o arquivo .terraform.lock.hcl gerado durante terrraform init para verificar providers antes do terraform plan.

conftest test .terraform.lock.hcl -p /home/atlantis/policy

package main

allowed_providers = {
    "registry.terraform.io/hashicorp/aws",
    "registry.terraform.io/hashicorp/random",
    "registry.terraform.io/hashicorp/null"
}

deny[msg] {
    input.provider[name]
    not allowed_providers[name]
    msg = sprintf("Provider '%s' caught.", [name])
}

Veja que é possível combinar os arquivos com as policies de maneiras variadas.

Dessa forma, o plano de mudança não vai acontecer. Pois, com os exemplos acima, retornará um código de saída 1 quando qualquer provider não autorizado for detectado.

If a workflow step returns a non-zero exit code, the workflow will stop.

Esse tipo de medida estabelece uma melhor prevenção.

Ou seja, se o teste ocorrer bem, o plano será executado como esperado. Caso contrário, o risco será mitigado.

Assim, não tem problema ter testes antes do plan e a policy check que acontecerá depois do plan normalmente. As custom workflows de Atlantis são personalizáveis.

Recurso terraform_data

Em poucas palavras, a HashiCorp inseriu o sucessor de null_resource. Esse recurso tem a missão de auxiliar no ciclo de vida de outros recursos. Ele não depende de outros providers, pois vem no embutido.

Na documentação, há duas formas de explorar isso:

• Usando o recurso terraform_data ;

• Usando replace_triggered_by no argumento de lifecycle de outro recurso.

No primeiro caso, fica sujeito ao uso de provisioner como local-exec. O que merece muita atenção. Concorda?

Confeccionando policies

Eu utilizei o The Rego Playground para confeccionar algumas policies REGO.

Na imagem acima, o campo esquerdo é reservado para a policy REGO. No campo Input você cola o conteúdo de $SHOWFILE gerado anteriormente. Lembra-se? E o sucesso da policy pode ser acompanhado nos campos Data e Output sempre que Evaluate for chamado. Acredite, isso pode facilitar a sua vida!

E agora?

É importante fazer um refinamento para chegar em um número maior de itens a serem verificados.

Mas, não seja limitado aos testes em si. É importante abranger a segurança para as outras camadas de infraestrutura.

Uma tendência é o uso de registry Terraform privado para módulos e/ou providers. Há opções como Citizen, Terrareg etc.

Conhece mais dicas para evitar instruções arbitrárias?

Enfim, espero que tenham gostado e mantenham-se sempre vigilantes.

Referências

• Atlantis - https://www.runatlantis.io/

• Conftest - https://www.conftest.dev/

• OPA - https://www.openpolicyagent.org/docs/latest/terraform/

• go-getter - https://pkg.go.dev/github.com/hashicorp/go-getter

• The Rego Playground - https://play.openpolicyagent.org/

• Terraform Plan RCE - https://alex.kaskaso.li/post/terraform-plan-rce

• Regula - https://regula.dev/

• HackTricks Cloud - https://cloud.hacktricks.xyz/pentesting-ci-cd/terraform-security#terraform-apply

• Atlantis Hardening and Review Fatigue - https://doordash.engineering/2023/12/05/atlantis-hardening-and-review-fatigue/

• Use Conftest to Audit IaC - https://www.fairwinds.com/blog/how-to-kubernetes-use-conftest-to-audit-infrastructure-as-code

O assunto dessa publicação é, simplesmente, contribuir para quem precisa de provisionar um volume Kubernetes usando um serviço Network File System (NFS) como backend.

Vamos lá?

A priori, a Google Cloud (GCP) não disponibiliza Persistent Volume com ReadWriteMany de maneira nativa. Atualmente, é necessário contratar uma solução gerenciada chamada Filestore.

O ReadWriteMany é útil quando mais de um workload precisa ler e escrever num mesmo volume, mesmo estando em nós diferentes. Por exemplo, se você tem um Deployment com cinco réplicas e cada Pod precisa de escrever no mesmo volume.

Dito isso, a criação de um serviço NFS para disponibilizar um share é um meio disponível. Na prática, o custo de uma VM e um disco persistente. Ou até mesmo um serviço no próprio cluster.

Nessa publicação, espera-se que você já tenha um share de NFS pronto e disponível.

Crie os seguintes objetos Kubernetes:

PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: share
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  mountOptions:
    - nfsvers=4.2
  nfs:
    server: "nfs.domain.tld"
    path: "/my-share"
    readOnly: false
  # Se você quiser tornar esse PV exclusivo ao PVC
  # claimRef:
  #   name: 
  #   namespace:

PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: share
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: ""
  volumeName: share

Perceba que ambos possuem storageClassName com uma string vazia. Isso acontece para evitar que ele adote por um armazenamento diferente do que estamos buscando.

E, além disso, o PVC buscará pelo PV através de volumeName. Sendo parte da técnica de binding.

Por sua vez, o PV também pode fazer binding ao PVC através de claimRef. Isso seria a técnica completa. Se preferir, pode definir o claimRef para o nome e namespace do PVC. Nesse exemplo, não foi necessário.

O PV precisa do bloco nfs configurado com server e path com o serviço NFS disponível. Ou seja, defina o endereço IP ou nome DNS no campo spec.nfs.server e defina o caminho do share no campo spec.nfs.path.

Essa é a configuração de utilizar um serviço NFS por trás de um PV.

Assim, é possível você definir o volume no seu Deployment por exemplo:

  ...
  containers:
  - image: busybox
    name: teste
    volumeMounts:
    - mountPath: /opt/teste
      name: volume-compartilhado
  volumes:
  - name: volume-compartilhado
    persistentVolumeClaim:
      claimName: share

Simples?

Em caso de problemas, verifique se o serviço NFS tem regras de firewall permitindo a rede do nó, ou se há alguma restrição com permissão de usuários sobre o diretório utilizado no servidor.

Usually, you need to run some services in cheaper regions like USA and keep some others in southamerica-east1.

via GIPHY

So, what's the point?

We can distribute some workloads on cheaper regions at GCP. The South Carolina region is the best option for.

Especially, if you need to run Cloud Interconnect as quoted below:

South Carolina (us-east1) enables customers in South America to receive an SLA of 99.99% for their Cloud Interconnect configurations, since it is the closest North American region to South America.

Source at here.

So, don't choose random regions anymore.

Aren't you convinced? Check it out on Google Cloud Pricing Calculator and do some math.

Extra

Verify the network latency closest to you at https://gcping.com/

What about a HIDS tool for your managed Kubernetes cluster? It has an easy way to do that by using Falco with eBPF probe. One out of three available options. Also, it is a GKE recommendation:

We suggest using the eBPF driver for running Falco on GKE.

Falco is a CNCF solution and you can check it on: https://falco.org/

Requirements

In official documentation, the requirements to use eBPF probe are:

1. CONFIG_BPF_JIT enabled
2. FALCO_BPF_PROBE environment variable value set to empty
3. net.core.bpf_jit_enable set to "1"

Before, let's look at current kernel version:

$ uname -r
5.4.170+

✅ Great! It supports.

Checking CONFIG_BPF_JIT:

$ grep CONFIG_BPF_JIT /boot/config-$(uname -r)
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT=y

✅ Okay, it's enabled.

Checking FALCO_BPF_PROBE:

{{- if .Values.ebpf.enabled }}
  - name: FALCO_BPF_PROBE
    value: {{ .Values.ebpf.path }}
{{- end }}

✅ Okay, the template solves that by default.

Checking net.core.bpf_jit_enable:

$ sudo sysctl net.core.bpf_jit_enable
net.core.bpf_jit_enable = 1

✅ Okay, it's enabled.

Setup

The following Helm Chart command will do the needed setup:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --set ebpf.enabled=true

Wherein you can put other parameters to enable Falcosidekick with WebUI on the same Helm Chart:

  ...
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Check out the available parameters at here.

Ps.: you could load the Yaml manifest with parameter -f values.yaml instead of.

And a Falcosidekick output list at here like Google Cloud Storage, Slack, webhooks etc.

You can look at the created objects with:

$ kubectl get all -n falco

Ready

What's happening right now?

Run a Port Forward to access the UI:

kubectl port-forward svc/falco-falcosidekick-ui 2802:2802 -n falco

Done! Go to the browser: http://localhost:2802/ui

Then, you`ll see a page like this:

The default ruleset is applied on. You can custom your settings as you prefer.

Enjoy! Thanks.

EXTRAS

If you need to send events to outside through PubSub (log sink), then it's useful.

Parameters for Falcosidekick

falcosidekick:
  enabled: "true"
  gcp:
    pubsub:
      minimumpriority: "error"

Terraform for Google PubSub

module "falcosidekick_pubsub_output" {
  source  = "terraform-google-modules/pubsub/google"
  version = "~> 3.2.0"

  topic      = "falco-topic"
  project_id = "projeto-id"
  push_subscriptions = [
    {
      name                 = "falco-subscription"
      push_endpoint        = "https://gcp-intake.logs.datadoghq.com/api/v2/logs?dd-api-key=${local.falco_api_key}&dd-protocol=gcp"
      ack_deadline_seconds = 20
      x-goog-version       = "v1beta1"
    }
  ]
}

Já pensou em uma ferramenta HIDS para o seu Kubernetes gerenciado? Há uma maneira pouco dramática para implantá-la utilizando Falco com suporte a eBPF. É uma das três alternativas disponibilizadas. Além disso, é uma recomendação para GKE:

We suggest using the eBPF driver for running Falco on GKE.

Falco é uma solução CNCF e você pode conhecer mais no site: https://falco.org/

Requisitos

Na documentação oficial, os requisitos para utilizar eBPF probe são:

1. CONFIG_BPF_JIT habilitado
2. valor da variável de ambiente FALCO_BPF_PROBE para vazio
3. net.core.bpf_jit_enable definida para 1 (habilita BPF JIT Compiler)

Antes, vamos verificar a versão de kernel atual:

$ uname -r
5.4.170+

✅ Bom! É uma versão com suporte.

Verificando CONFIG_BPF_JIT:

$ grep CONFIG_BPF_JIT /boot/config-$(uname -r)
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT=y

✅ Sim, está habilitado.

Verificando FALCO_BPF_PROBE:

{{- if .Values.ebpf.enabled }}
  - name: FALCO_BPF_PROBE
    value: {{ .Values.ebpf.path }}
{{- end }}

✅ Sim, o template se encarrega disso.

Verificando net.core.bpf_jit_enable:

$ sudo sysctl net.core.bpf_jit_enable
net.core.bpf_jit_enable = 1

✅ Sim, está habilitado.

Instalação

O comando abaixo utilizando Helm Chart fará a instalação necessária:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --set ebpf.enabled=true

Você pode conferir os objetos criados com:

$ kubectl get all -n falco

Onde você pode incrementar outros parâmetros para habilitar Falcosidekick com WebUI no mesmo Helm Chart:

  ...
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Confira os parâmetros disponíveis aqui.

E uma lista de outputs disponíveis para Falcosidekick aqui como Google Cloud Storage, Slack, webhooks etc.

Obs.: você pode usar um manifesto Yaml com parâmetro -f values.yaml se preferir.

Pronto

O que está acontecendo agora?

Você pode fazer um Port Forward para a UI:

kubectl port-forward svc/falco-falcosidekick-ui 2802:2802 -n falco

Feito! Vá ao nevegador: http://localhost:2802/ui

Então, você verá uma página como essa:

O conjunto de regras padrão é aplicado. Você pode evoluir a sua configuração como necessário.

Se divirta! Obrigado.

I tried to sync a new Redis version and just.

But I ended up with an error like this:

Sync operation to failed: ComparisonError: rpc error: code = Unknown desc = helm pull --destination /tmp/helm875598576 --version 15.5.2 --repo https://charts.bitnami.com/bitnami redis failed signal: killed

Yes. I've already had others. But, it doesn't go on at this time.

Why?

Look, we're aimed to follow the Kubernetes best practices and apply some rules. Say so 😅

The ArgoCD pods have not restarted in each and every sync error. It led me to believe it couldn't be any out of memory...

My bad! It's OOM issue.

Of course, I solved this OOM issue by increasing the RAM limit.

If you have it managed by Helm Chart, change this value to fit your needs:

repoServer:
  resources:
    limits:
      memory: 1Gi # look at here

Apply with some helm upgrade --install...

Done. The ArgoCD settings are improved and the wanted app is ready to be synced one more time right now.

All right. Thanks!

Sabendo-se disso, fica o meu conselho: aproveitem a oportunidade para conhecer e se qualificar com esse provedor de nuvem pública sensacional!

Até 12/09, no horário de Beijing (GMT+8), você pode responder a uma enquete de como a Alibaba Cloud pode desenvolver a sua carreira. Assim, concorrer a um ano de acesso gratuito à plataforma Academy. Clique aqui para responder ao formulário.

Não para por aí. Você pode participar do desafio e ganhar um voucher para certificação "na faixa". Escolha uma das trilhas e complete os seus desafios. Terá duas rodadas:

• 31 de agosto a 13 de setembro;
• 14 de setembro a 27 de setembro.

A proposta é cumprir o desafio em 14 dias. Para mais informações, confira a página oficial e comece o quanto antes: https://edu.alibabacloud.com/certification/aca_cloud

Toda informação foi disponibilizada publicamente pela Alibaba Cloud e é sob responsabilidade da mesma. Confira as regras oficiais nas páginas oficiais.