DEV Community: Marcelo Andrade

Entendendo Kubernetes Ingress Controllers e as vulnerabilidades recentemente anunciadas do Nginx

Marcelo Andrade — Mon, 31 Mar 2025 08:34:16 +0000

Recentemente, uma série de vulnerabilidades foi anunciada para o Nginx Ingress Controller, algo bem preocupante, levando em consideração que este é o Ingress Controller "padrão" para a maioria das pessoas que estão começando com Kubernetes. Uma delas, em particular, recebeu um score de 9.8, pois não exige basicamente nenhum privilégio especial, bastando o usuário ter conectividade com o componente vulnerável.

Fui torpedeado com várias dúvidas a respeito essa semana no trabalho e fora dele a respeito, e acredito que vale a pena compartilhar algumas delas por aqui.

O que é Ingress?

Ingress é um tipo de recurso do Kubernetes que permite descrever como sua aplicação pode ser acessada usando definições de protocolo de alto nível ("camada 7").

Diferentemente dos Services do tipo LoadBalancer, que configuram um balanceador de carga camada 4 para encaminhar todo tráfego recebido para um conjunto de Pods normalmente associados a um único Deployment, o Ingress permite que várias aplicações diferentes sejam servidas a partir de um mesmo domínio ou balanceador:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: subs-devsres-com
spec:
  rules:
  - host: "subs.devsres.com"
    http:
      paths:
      - pathType: Prefix
        path: "/admin"
        backend:
          service:
            name: admin-module
            port:
              number: 8080
      - pathType: Prefix
        path: "/assets"
        backend:
          service:
            name: assets
            port:
              number: 8080
      - pathType: Prefix
        path: "/esskay"
        backend:
          service:
            name: uwu
            port:
              number: 8080

As requisições ao domínio subs.devsres.com serão encaminhadas para os módulos da minha aplicação admin, assets ou esskay, dependendo do path acessado na URL.

Eu descrevo neste post como usar Ingress pode ser o que viabiliza um projeto por minimizar o número de balanceadores instanciados em uma nuvem pública.

O que é um Ingress Controller?

Controllers são a base do funcionamento do Kubernetes, e correspondem a programas que executam de maneira contínua para garantir que o que você descreve em seus arquivos yaml sejam criados e continuem existindo.

Controllers instanciam seus Pods ao criar um Deployment, e garantem que iniciarão novamente caso a aplicação dê um crash, ou sejam recriados caso alguma máquina do cluster Kubernetes falhe.

Um Ingress Controller é um programa que lê os objetos Ingress do cluster e viabiliza sua implementação em algum lugar.

A descrição acima ("em algum lugar") é bastante genérica porque, diferentemente da grande maioria dos outros recursos nativos, como Pods, Services ou Deployments, clusters Kubernetes não vêm com Controllers para o objeto Ingress na sua instalação padrão. E isso é algo mais comum do que parece: Services do tipo LoadBalancer também podem não funcionar, dependendo de onde seu cluster é criado; NetworkPolicies dependem do plugin CNI escolhido e podem não funcionar; PersistentVolumes também precisam de configuração de componentes externos... Isso contribui com a percebida complexidade de uso do Kubernetes, que nem mesmo soluções gerenciadas de nuvem conseguem apaziguar.

A pior parte: muitos dos componentes sem Controllers nativos não são "opcionais" para a maioria dos usos da tecnologia!

O que é o Ingress Nginx Controller?

O projeto Kubernetes mantém três subprojetos de Ingress sob sua guarda; um deles é o Ingress Nginx Controller, e os demais são específicos para clouds públicas (AWS e GCP).

Os dois Ingress Controllers de nuvens públicas operam como o esperado, traduzindo o que é descrito nos yamls de Ingress para configurações das ofertas de balanceadores de carga.

Já o Ingress Nginx Controller executa um Nginx como proxy reverso e gera configurações para este Nginx a partir dos seus objetos Ingress.

Embora a documentação liste uns trinta controllers diferentes, é bastante comum pensar que o Ingress Nginx Controller é a principal oferta disponível para Kubernetes fora das principais nuvens, e sua ampla adoção reflete este pensamento.

Ingress NGINX Controller ou NGINX Ingress Controller?

Parece piada, mas não é. Mas o Ingress NGINX Controller não tem nada em comum com o NGINX Ingress Controller além do NGINX no nome.

O primeiro, que é o assunto em ênfase deste post, é um subprojeto mantido pelo próprio Kubernetes. O segundo é mantido pelos próprios mantenedores do NGINX, cuja empresa foi comprada pela F5.

São softwares diferentes, mantidos por pessoas diferentes, com parametrizações e funcionalidades diferentes e - o mais importante - incompatíveis entre si. Não é tão raro assim ver usuários instalando a segunda solução pensando ser a primeira, e se perguntando porque as configurações aplicadas não estão funcionando!

E aqui vem um dos aspectos mais importantes do entendimento de Ingress no Kubernetes: por ser um objeto exageradamente simples, e balanceamento de carga em camada 7 ser algo extremamente complexo, existe um volume absurdo de configurações que dependem de implementação, e são ativados de maneiras diferentes. Ingress Controllers, via de regra, não são facilmente intercambiáveis, especialmente se você fizer uso de funcionalidades avançadas. E certas configurações, mesmo que disponíveis em outros Controllers (como o encaminhamento de certificados TLS para a aplicação), podem exigir reescrita do código da sua aplicação porque são implementadas de maneira diferentes por cada um.

Quais os problemas do Ingress NGINX Controller?

Componentes de software de infraestrutura geralmente precisam executar com privilégios especiais em clusters Kubernetes.

E aqui está um dos principais problemas do Ingress NGINX Controller:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-nginx
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - nodes
  - pods
  - secrets
  - namespaces
  verbs:
  - list
  - watch
...

A instalação padrão, que imagino ser usada por 99,99% dos usuários, dá permissão para acessar todos os Secrets de um cluster. Isso geralmente é necessário porque uma das funcionalidades do objeto Ingress costuma ser ler certificados TLS a partir de Secrets:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: devsres-tls
spec:
  tls:
  - hosts:
      - subs.devsres.com
    secretName: subs-devsres-com
  rules:
  - host: subs.devsres.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: devsres
            port:
              number: 8080

Um atacante capaz de comprometer o Ingress Controller daria acesso não só a todos os certificados (e chaves privadas destes), como outras credenciais importantes normalmente salvas em Secrets (de bancos de dados, serviços, chaves de API).

Além disso, se você criar um token de ServiceAccount persistente, aos moldes do que era comum no Kubernetes até a versão 1.22, o atacante também poderia acessá-los e potencialmente escalar privilégios.

Como todo componente de infraestrutura, entender sobre a segurança do Ingress Controller é essencial, em especial pelo fato de ser este geralmente o único componente exposto na Internet.

"Validating Webhook Configuration"

Existe um objeto nativo do Kubernetes chamado validatingwebhookconfiguration que entrega para os usuários uma funcionalidade interessante: a de inspecionar as operações em recursos na API.

O Ingress NGINX Controller faz uso desse recurso para monitorar a criação e atualização dos objetos Ingress:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: ingress-nginx-admission
...
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: ingress-nginx-controller-admission
      namespace: ingress-nginx
      path: /networking/v1/ingresses
      port: 443
  failurePolicy: Fail
  matchPolicy: Equivalent
  name: validate.nginx.ingress.kubernetes.io
  namespaceSelector: {}
  objectSelector: {}
  rules:
  - apiGroups:
    - networking.k8s.io
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - ingresses
    scope: '*'
  sideEffects: None
  timeoutSeconds: 10

Para que ele faz isso? Para evitar conflito entre configurações.

Como o objeto Ingress define um conjunto bastante simplório de configurações e sua implementação fica ao encargo de outro software, é possível que as configurações definidas sejam incompatíveis entre si.

Inclusive, uma infelicidade do Ingress é que uma configuração em uma Namespace pode impactar negativamente aplicações em outra Namespace - é o único caso em todo o Kubernetes em que consigo imaginar algo desse tipo de ser possível!

Por exemplo, caso definamos o seguinte objeto Ingress para receber as conexões feitas ao balanceador sem escopo definido:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: aplicacao1
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 8080

Este segundo objeto define uma configuração que conflita diretamente com a primeira: elas não podem existir no mesmo cluster!

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: desastre
  namespace: aplicacao2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: desastre
            port:
              number: 8080

O resultado final de conflitos de configurações deste tipo é imprevisível: pode ser que a segunda substitua a primeira, ou que o Controller identifique o conflito e escolha o mais antigo, ou o pior dos casos, que costuma ser a geração de uma configuração inválida que faz com que o Nginx não consiga mais atualizar suas configurações, deixando o Ingress "estagnado" e inconsistente com o ambiente, incapaz de executar as reconciliações necessárias para um ambiente super dinâmico.

Para evitar isso, o Ingress NGINX Controller implementa essa validação antes da criação ou modificação de objetos, fazendo com que o Kubernetes encaminhe o objeto para um programa (que, no caso, é o próprio ingress-nginx-controller):

$ kubectl create -f ingress2.yaml
Error from server (AlreadyExists): error when creating "ingress2.yaml": ingresses.networking.k8s.io "ingress1" already exists

Problemas do Webhook

O principal problema é o fato do Controller estar acessível pela rede:

# Dentro do container, você pode ver o processo que escuta na porta 8443:
$ netstat -nptlwev | fgrep 8443
tcp6       0      0 :::8443                 :::*                    LISTEN      101        174698     7/nginx-ingress-controller

Um atacante que consiga comprometer um Pod qualquer em execução (ou criar um, ainda que sem qualquer privilégio especial) terá acesso livre ao Webhook:

$ kubectl run shellhacker  --image=shellhacker
pod/shellhacker created

$ kubectl exec -it shellhacker -- /bin/bash
root@shellhacker:/# curl -kv https://ingress-nginx-controller-admission.ingress-nginx:443
*   Trying 10.100.66.184:443...
* Connected to ingress-nginx-controller-admission.ingress-nginx (10.100.66.184) port 443 (#0)
> Host: ingress-nginx-controller-admission.ingress-nginx
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 400 Bad Request
< Date: Mon, 31 Mar 2025 07:35:47 GMT
< Content-Length: 0
<
* Connection #0 to host ingress-nginx-controller-admission.ingress-nginx left intact

Felizmente, a maior parte das instalações padrão não expõe o acesso ao Controller diretamente na Internet, apenas internamente ao cluster:

$ kubectl -n ingress-nginx get services
NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.100.246.156   a26b9332b9a154edc9b6d741dc759fdd-1876731234.us-west-2.elb.amazonaws.com   80:32691/TCP,443:31242/TCP   85m
ingress-nginx-controller-admission   ClusterIP      10.100.66.184    <none>                                                                    443/TCP                      85m

Mas pode acontecer que usuários mais desavisados acabem por expô-lo também! Mais uma coisa para prestar atenção nas suas instalações!

Vulnerabilidade CVE 2025-1974 e demais

O uso do Ingress NGINX Controller na forma de webhook para este recurso de validação é justamente o assunto da vulnerabilidade mais grave - a CVE 2025-1974.

As outras vulnerabilidades dependem da criação de objetos Ingresses no cluster formatadas de maneira maliciosa; essa operação é considerada privilegiada e a maior parte dos workloads em execução em um cluster não tem permissão para fazê-lo, tornando-as perigosas mas mais difíceis de explorar.

A CVE 2025-1974 é muito mais grave que as outras porque você não precisa da permissão para criar Ingresses; basta ter acesso de rede ao Controller com acesso ao Webhook para enviar um objeto Ingress devidamente formatado que pode, entre outras coisas, gerar execução de código malicioso.

Como remediar?

As correções já saíram e os ambientes já podem ser atualizados.

Caso a atualização não seja possível, o importante é ao menos bloquear os acessos ao Controller pela rede de Pods. A maneira mais comum de fazer isso é simplesmente removendo o ValidatingWebhookconfiguration ingress-nginx-admission, mas também pode ser feito por meio do uso de NetworkPolicies.

O uso de NetworkPolicies, costumeiramente ignorado, é uma excelente solução para mitigar este tipo de risco. Nenhum software, por mais maduro que seja, está livre de falhas desta natureza. O importante, neste caso, é sempre se antecipar e impedir ser pego de surpresa por algo desta gravidade.

From which Kubernetes pod (and namespace!) is this process that I see on my host?

Marcelo Andrade — Fri, 16 Aug 2024 05:28:01 +0000

So you figured out that the pids of your Kubernetes (or Docker) containers show up on your host:

$ ps auxw | fgrep python
root       11282  0.0  0.0  94628 24372 ?        Ss   04:53   0:00 python app.py
root       11439  0.0  0.0  41968 13072 ?        Ss   04:53   0:00 python event-simulator.py
root       12527  0.0  0.0   6796  2292 pts/0    S+   04:57   0:00 grep -F --color=auto python

But what Kubernetes pod owns these processes?

As far as my knowledge extends, there is not a trivial way to use a native command to figure it out. You have to put the pieces of the puzzles by yourself.

The usual "hack" I see most people do is:

$ nsenter -t 11282 -u hostname
webapp-color

$ nsenter -t 11439 -u hostname
e-com-1123

But that does not give me the Kubernetes namespace.

I did some random googling and couldn't figure out someone else that is as annoyed as myself for this, so I decided to write this blog post.

TL:DR edition:

$ for i in 11282 11439; do crictl inspect --output go-template --template '{{index .status.labels "io.kubernetes.pod.namespace" }}:{{index .status.labels "io.kubernetes.pod.name" }}'  $( head -n1 /proc/$i/cgroup | cut -f5 -d':' ) ; done
default:webapp-color
e-commerce:e-com-1123

If you want to learn how and why it works, keep reading.

You probably read somewhere that what makes containers real are two Linux resources: cgroups and namespaces.

Let's go back to the "hack":

$ nsenter -t 11439 -u hostname
e-com-1123

The Linux command nsenter allows you to run a command inside the namespace of another process:

$ nsenter -h
Run a program with namespaces of other processes.
...
 -u, --uts[=<file>]     enter UTS namespace (hostname etc)
...

So, the hack uses nsenter -u, which in turns run a command inside the Linux UTS Namespace, which allows us to set hostnames and domain names without affecting the rest of the system.

The UTS namespace is definitely not exactly the most recognizable; when people think of namespaces, usually they remember the PID namespace, responsible to provide an isolated process ID space for the container, or the Network namespace, which in turn provides an isolated network stack. But yeah, there are a bunch of other ones, as you can check out on the links in this paragraph. Or in case you're lazy, here is an extended output of the nsenter -h output:

$ nsenter -h
Usage:
 nsenter [options] [<program> [<argument>...]]

Run a program with namespaces of other processes.
...
 -a, --all              enter all namespaces
 -t, --target <pid>     target process to get namespaces from
 -m, --mount[=<file>]   enter mount namespace
 -u, --uts[=<file>]     enter UTS namespace (hostname etc)
 -i, --ipc[=<file>]     enter System V IPC namespace
 -n, --net[=<file>]     enter network namespace
 -p, --pid[=<file>]     enter pid namespace
 -C, --cgroup[=<file>]  enter cgroup namespace
 -U, --user[=<file>]    enter user namespace
 -T, --time[=<file>]    enter time namespace

That was a fun one! But what about cgroups?

Well, cgroups allow us to limit the use of system resources like CPU, memory and network bandwith.

You can see the cgroups of a process with an easy ps*:

$ ps -wwo cgroup= 11439
12:hugetlb:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,11:cpu,cpuacct:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,10:memory:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,9:perf_event:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,8:net_cls,net_prio:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,7:cpuset:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,6:pids:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,5:blkio:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,4:devices:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,3:rdma:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,2:freezer:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a,1:name=systemd:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a

Ouch, that was ugly. Let's prettify the output:

ps -wwo cgroup= 11439 | tr , '\n'
12:hugetlb:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
11:cpu
cpuacct:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
10:memory:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
9:perf_event:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
8:net_cls
net_prio:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
7:cpuset:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
6:pids:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
5:blkio:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
4:devices:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
3:rdma:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
2:freezer:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
1:name=systemd:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a

Much better.

But truth be told, it is basically the same output of this simple cat command:

$ cat /proc/11439/cgroup 
12:hugetlb:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
11:cpu,cpuacct:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
10:memory:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
9:perf_event:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
8:net_cls,net_prio:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
7:cpuset:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
6:pids:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
5:blkio:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
4:devices:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
3:rdma:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
2:freezer:/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
1:name=systemd:/system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
0::/

What each of them do? Well, you can read this from the Linux Kernel itself, and that's not the focus of today's post.

We need to figure out which Kubernetes pod (and it namespace!) is the owner of that proces!

If you pay attention, you'll notice an interesting pattern on the cgroups naming:

$ cat /proc/11439/cgroup | cut -f3- -d':' | sort | uniq  -c 
      1 /
      6 /kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
      6 /system.slice/containerd.service/kubepods-besteffort-pod86811ae3_b633_4eb8_a508_e3eae190f6ce.slice:cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a

Lets discard the part of the hierarchy that we do not care that much about:

$ cat /proc/11439/cgroup | cut -f4- -d':' | sort | uniq  -c 
      1 
     12 cri-containerd:da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a

That character sequence after the ':' seems awfully familiar:

$ crictl ps --id da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD
da1bdd84c8b25       ee4be8f9dfd10       7 minutes ago       Running             simple-webapp       0                   48ee11c897fa8       e-com-1123

Here it is! The pod name!

But what about its namespace?

I'm not sure if there is an easy way to make crictl return this to you. I know the annoying one: formatting its output using go-template!

Let's see what we have:

$ crictl inspect da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a | jq '. | keys'
[
  "info",
  "status"
]

Let's go deeper:

$ crictl inspect da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a | jq '.info | keys'
[
  "config",
  "pid",
  "removing",
  "runtimeOptions",
  "runtimeSpec",
  "runtimeType",
  "sandboxID",
  "snapshotKey",
  "snapshotter"
]

$ crictl inspect da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a | jq '.status | keys'
[
  "annotations",
  "createdAt",
  "exitCode",
  "finishedAt",
  "id",
  "image",
  "imageId",
  "imageRef",
  "labels",
  "logPath",
  "message",
  "metadata",
  "mounts",
  "reason",
  "resources",
  "startedAt",
  "state"
]

I have a hunch we want to see what is stored on .status.labels:

$ crictl inspect da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a | jq '.status.labels'
{
  "io.kubernetes.container.name": "simple-webapp",
  "io.kubernetes.pod.name": "e-com-1123",
  "io.kubernetes.pod.namespace": "e-commerce",
  "io.kubernetes.pod.uid": "86811ae3-b633-4eb8-a508-e3eae190f6ce"
}

Oh yeah! That is what we want! We have a pod called e-com-1123 running the process. It is in the Kubernetes namespace e-commerce!

Let's create a go-template from it. This is how you access the members of a map:

$ crictl inspect --output go-template --template '{{.status.labels}}' da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
map[io.kubernetes.container.name:simple-webapp io.kubernetes.pod.name:e-com-1123 io.kubernetes.pod.namespace:e-commerce io.kubernetes.pod.uid:86811ae3-b633-4eb8-a508-e3eae190f6ce]

As you can imagine, if a member of a map has a '.' on its name, you'll incurr into problems:

$ crictl inspect --output go-template --template '{{.status.labels.io.kubernetes.pod.name}}' da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
FATA[0000] getting the status of the container "da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a": failed to template data: template: tmplExecuteRawJSON:1:9: executing "tmplExecuteRawJSON" at <.status.labels.io.kubernetes.pod.name>: map has no entry for key "io"

No worries, just use one of the very few builtin go-template functions:

$ crictl inspect --output go-template --template '{{index .status.labels "io.kubernetes.pod.name" }}' da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
e-com-1123

We are halfway there:

$ crictl inspect --output go-template --template '{{index .status.labels "io.kubernetes.pod.namespace" }}:{{index .status.labels "io.kubernetes.pod.name" }}' da1bdd84c8b25938081afe48da7075e2a211d2b1a62e01c894b4e5f3ffab670a
e-commerce:e-com-1123

And now, turning into a one-liner:

$ for i in $( pgrep python -d ' ' ); do crictl inspect --output go-template --template '{{index .status.labels "io.kubernetes.pod.namespace" }}:{{index .status.labels "io.kubernetes.pod.name" }}'  $( head -n1 /proc/$i/cgroup | cut -f5 -d':' ) ; done
default:webapp-color
e-commerce:e-com-1123

Here is the answer I've been looking: how to figure out from which namespace and pod a process on my host is running.

I admit making it a oneliner didn't help all that much with legibility, so I will write a script in hopes to make it easier to understand:

$ cat which-pod-am-i.sh 
#!/bin/bash

# This is NOT a production script!
# This was made just to make the techniques legible!

# Pieces of go templates.
# We need to retrieve two fields from .status.labels:
# .status.labels."io.kubernetes.pod.namespace" 
NAMESPACE_TMPL='{{index .status.labels "io.kubernetes.pod.namespace" }}'
# .status.labels."io.kubernetes.pod.name"
POD_TMPL='{{index .status.labels "io.kubernetes.pod.name" }}'

# I'm passing the process name from command line: 
for i in $( pgrep ${1?Parameter not passed} -d ' ' ); do 

  # Get the container ID from the cgroups:
  CONTAINER_ID=$( head -n1 /proc/$i/cgroup | cut -f5 -d':' )

  # Inspect with go templates:   
  crictl inspect --output go-template \
                 --template "$NAMESPACE_TMPL:$POD_TMPL" \
                 ${CONTAINER_ID:?Container not found}
done

$ ./which-pod-am-i.sh python
default:webapp-color
e-commerce:e-com-1123

By the way, all these commands were run on KodeKloud Sandbox provided with their Udemy CKAD course. Shout out to them for providing an incredibly
affordable and non-expirable hands-on resource to study for CNCF CKA/CKAD certifications.

Terraform, OpenTofu e criptografia de estado

Marcelo Andrade — Tue, 02 Jul 2024 03:49:25 +0000

TLDR: o OpenTofu agora conta com criptografia de State files (e de Plan files também!) sem depender do backend remoto. O Terraform não - e talvez nunca suporte em sua versão gratuita.

É de extrema importância conhecer bem as ferramentas que você pretende usar para ser capaz de desenhar bons fluxos de trabalho e, especialmente, mapear os riscos envolvidos.

Quem usa Terraform já está familiarizado com a relevância do State File e que é de extrema importância garantir não só a resiliência do arquivo como também o controle de acesso.

No post abaixo, vamos fazer um estudo de caso demonstrando os problemas de ter um arquivo de State File em texto claro disponível em buckets S3.

Vamos supor que você criou uma variável no AWS Secrets Manager com Terraform:

$ aws sts get-caller-identity
{
    "UserId": "AIDA2UC3CSEZOOZQXHZCN",
    "Account": "730335449394",
    "Arn": "arn:aws:iam::730335449394:user/cloud_user"
}

$ aws secretsmanager get-secret-value --secret-id senha_root
{
    "ARN": "arn:aws:secretsmanager:us-east-1:730335449394:secret:senha_root-qiNJDs",
    "Name": "senha_root",
    "VersionId": "terraform-20240701215533811100000001",
    "SecretString": "z0mgp4ssw0rd",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2024-07-01T18:55:32.978000-03:00"
}

Um usuário hacker não vai ter acesso à variável, a menos que alguém dê acesso explícito para ele:

$ aws sts get-caller-identity
{
    "UserId": "AIDA2UC3CSEZLYNWRDSTL",
    "Account": "730335449394",
    "Arn": "arn:aws:iam::730335449394:user/hacker"
}

$ aws secretsmanager get-secret-value --secret-id senha_root

An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:iam::730335449394:user/hacker is not authorized to perform: secretsmanager:GetSecretValue on resource: senha_root because no identity-based policy allows the secretsmanager:GetSecretValue action

Observe que o erro é claramente permissão:

no identity-based policy allows the secretsmanager:GetSecretValue action

Caso o hacker consiga comprometer um usuário que conte com acesso ao Secrets Manager, ainda é possível usar criptografia de uma chave KMS específica (e não a padrão do Secrets Manager), o que adiciona uma segunda camada de segurança:

# Agora o hacker conseguiu comprometer um usuário com acesso ao SM!
# Isso deu a ele a chance de acessar secrets menos importantes:
$ aws secretsmanager get-secret-value --secret-id senha_menos_importante
{
    "ARN": "arn:aws:secretsmanager:us-east-1:730335449394:secret:senha_menos_importante-Y4reR7",
    "Name": "senha_menos_importante",
    "VersionId": "e919b63c-6937-44ca-81b9-b8b2172c6b33",
    "SecretString": "{\"SENHA\":\"menos_importante\"}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2024-07-01T20:22:02.007000-03:00"
}

# A senha_root, entretanto, está criptografada com uma chave KMS não padrão:
$ aws secretsmanager get-secret-value --secret-id senha_root

An error occurred (AccessDeniedException) when calling the GetSecretValue operation: Access to KMS is not allowed

Aqui, a mensagem de erro mudou:

Access to KMS is not allowed

Para acessar a senha importante, é necessário não só acesso ao serviço Secrets Manager, mas também ao serviço de gestão de chaves KMS, que normalmente conta com Resource Policies mais restritas de acordo com a finalidade.

Só que... Geralmente guardamos arquivos de Terraform State em S3!

E se o hacker comprometer um usuário com acesso a buckets S3?

Acessando arquivos de Terraform State

Um arquivo Terraform State é um JSON escrito em texto claro, sem qualquer proteção aos valores salvos.

Podemos até escrever o código Terraform da seguinte maneira:

$ cat variables.tf
variable "senha_root" {
  type = string
  description = "Senha de root mais importante que temos"
  sensitive = true
  nullable = false
}

Note o atributo sensitive!

Podemos também garantir que o parâmetro só é conhecido em tempo de execução de código por meio de passagem de parâmetro do usuário:

# Um formulário permitiu preencher a variável SENHA antes da execução:
$ terraform apply -var "senha_root=$SENHA" -auto-approve

Só que, na prática, o atributo sensitive apenas garante que o atributo não será exibido na saída da execução do comando ou em mensagens de log, como descrito aqui:

Terraform will then redact these values in the output of Terraform commands or log messages.

No mesmo link acima, um alerta importante em outra seção:

When you run Terraform commands with a local state file, Terraform stores the state as plain text, including variable values, even if you have flagged them as sensitive. Terraform needs to store these values in your state so that it can tell if you have changed them since the last time you applied your configuration.

Traduzindo: o Terraform salva o State File em texto claro!

E mais abaixo:

Marking variables as sensitive is not sufficient to secure them.

Como eles mesmos descrevem:

You must also keep them secure while passing them into Terraform configuration...

...como fizemos com o formulário, mas...

...and protect them in your state file.

Claro que você pode usar as versões pagas para resolver seu problema:

HCP Terraform and Terraform Enterprise manage and share sensitive values, and encrypt all variable values before storing them.

Caso contrário, você está sem sorte, como na sequência de comandos abaixo:

$ aws s3api list-buckets --query 'Buckets[*].Name' --output text
devsres-terraform-state-storage

$ aws s3 ls --recursive s3://devsres-terraform-state-storage/
2024-07-01 20:30:15       3987 terraform/state/senha_root

$ aws s3 cp s3://devsres-terraform-state-storage/terraform/state/senha_root /tmp/
download: s3://devsres-terraform-state-storage/terraform/state/senha_root to /tmp/senha_root

# A maioria das pessoas simplesmente usaria um grep mesmo:
$ jq -r '.resources[].instances[].attributes | select(.secret_string != null).secret_string' /tmp/senha_root
z0mgM1nh4p@ssw0rd!

Opentofu terraform state encryption

Só que isso é se estivermos falando do Terraform.

O OpenTofu é um projeto software livre derivado do Terraform após a mudança de licença da Hashicorp para BSL.

Em vez de ser um simples "fork", o OpenTofu trouxe novas funcionalidades que respondem ao anseio de muitas pessoas da comunidade, na prática deixando os códigos agora nem sempre 100% compatíveis!

Por exemplo, é possível criptografar o Terraform State com uma passphrase ou com um serviço de chaves como o KMS sem precisar contar com funcionalidades nativas do S3!

Como fazer isso?

Bem, aí é necessário ler a documentação. Essa funcionalidade está disponível desde a versão 1.7.0 lançada em abril de 2024.

O exemplo abaixo é suficiente para mostrar a criptografia com passphrase:

$ cat terraform.tf
terraform {
  backend "s3" {
    bucket = "devsres-terraform-state-storage"
    key    = "tofu/state/senha_root"
    region = "us-east-1"

    # encrypt    = true
    # kms_key_id = "arn:aws:kms:us-east-1:730335449394:key/9b8acab0-df09-4c2b-81ab-7dd33d2a4ba2"
  }

  encryption {
    key_provider "pbkdf2" "senha_de_state" {
      passphrase = "wow!criptografia!"
    }

    method "aes_gcm" "protege" {
      keys = key_provider.pbkdf2.senha_de_state
    }

    state {
      method = method.aes_gcm.protege
      enforced = true
    }

  }
}

Ao usar o código acima, este é o State File disponível no bucket S3:

$ aws s3 cp s3://devsres-terraform-state-storage/tofu/state/senha_root /tmp/
t download: s3://devsres-terraform-state-storage/tofu/state/senha_root to ../../../../../tmp/senha_root

$ cat /tmp/senha_root
{"serial":1,"lineage":"5d8b4611-05a3-1f8a-404a-11e1b0693e8f","meta":{"key_provider.pbkdf2.senha_de_state":"eyJzYWx0IjoiN3d4VmgxcHF3S01EQ0FzRXpqZ0xnU0w3bkJGbmFSd2pmSGVwWm45VTlkOD0iLCJpdGVyYXRpb25zIjo2MDAwMDAsImhhc2hfZnVuY3Rpb24iOiJzaGE1MTIiLCJrZXlfbGVuZ3RoIjozMn0="},"encrypted_data":"YihB4BhoJnJ/RV0tmk+CzHDrs6YBQOqVPf+JllkbiMQex0U9TglBOb+iLo1OQRIw4EyXCPDgqwdTM7yx+OFp2bCiiP+mQC5dk6pv6SQiRLKc1rvVV3pfrpvnts59s8SYSFZOzOTJfZgOeEaGKueGdgmkbQR2hXE6BRh0o3ohi/Zxw67B5pKtYNdNJFQPgLbBYDhNP/a5pCpsNi2PYw6I4xILbqLKgQPMmspQPS4+zIP2IU71VnW9anirJp5trV9dMb0v2qyzZLY4iitsbgltRYziCJURh/e4vR7P1oTbaI0OZ422r1uJLIWyrKzZH12pqtqjNmT/KXIGXtd76TcqjmMxX+s1jtyvV5F6EnwCU857DfGyBl/0WgREPo7kB9uH6MhwOCkUPTe638awLp+8Ess9cKFzxx/jn8u4GvtkBEJoTUO/0fFVh0fIudtYaRuiNuJ4Hd/rMlgfXc/smo50su23jeHEJfycksWnwjXIreMLzkXevQChZ/ix3RyPxH55dZIivyyBaILIvaP+1dEzzgCNiuD0chtxOTqOEkJnh30exznLRLR/8q3ISmN86co2C1fvs7PwmpTyYlDb33DzwmpYMbdJ79dngM4nc7d2drv6kDxyi2+KYdGKZmO1r56lQgxPewCNQPwzyC7OOp/rNWB4K2s9favdKQ2Fh3m7JtOi9PWzMTvHPZVEylam3RxbpH4IRoDEpGXw9tzRCBFNXbmBwEDTNKYM2yuDMyrqIQj0PuTitsRWtfScPZtZRs7ar0UmeAvG5Pn/H9Z3WEwk/um9Yogob7HAYsMnsBZyRoCrGxg1nJYFt65WPzcxmqbx/tO3mHwOL75RLQ6bicmVLIHbXTI92zc1OZ9uf80QIMVA4Qs3FlKXGW4rOufEFXUd1d31qoM4nZaxPB3kEJmNUiuKIaKbvcHCnbkSKsQP+WfmBYFCbBXSbwf9R5EXdU6kigX3Ixg5pkyXkeZNUXoFA707Xq6QuwWWihuAfbq16zPIpmWzXZPRiGOpAFGV5tJE4/ZXkL0l/cDf7mbkzN7/mK18wFXCWHeBBhi/KDNHpyvrFyO/RM5cLAnYQR0GBZ1FYPmVASYTwoF/m+T/zfZQMLXsinrFhmBaPOuhT5/v3O6X6S0DaMJYoQiupOPXXVwJ2Go/TGWw00AZ8J4I4mn+yz7rAG5VZWiz4H08Z3VuAWO9O5J6EYiMqGsU10DEftNy1juao3UmlnjZx8XkRNmgkDCfNHXx3+eo8mu5vGds9HrvsGYpUVX0rQQtzh5JIcUOQz9Yh/BNsRSxZ+7Y5SY45ifq1rf6kjaA0R8gBEoPvAAOE2QBZaKkq+wrtiJ4TiXJk7fni2nsSv6c29pONaQMq7E9TVdL5LhS8vzl69ticbheAJpoDUOR2R2Bf0FnpFx9d2P1mckCBqhIIuQQqMPjL+0/az4ysAA6k/LF+xfH7WBxl6RfUFHzfXty792z0HkueF62Y+1a9VRJViuaSl5f5QJ90tYnHsM3ooAb6c1m+tTevxE2nyIIvb2bzOyh7tOLVFSgJzzuX/C5VXGQ6KdeRCVQFcGP+XuodZQEhkkpWBxVIHXJfSAEFNQPvKGJJdkadz5zbyw1GJbY6CSwYB/rc5v1H6FDc1YSLNRTk2d6cEI71rtURuuYrO9K/Rq9EowPwdGRO+eom8Wu/QMsyGiab6hiAbek8frq4zAxhcOHjXTbJG0KkvteBKwNJfDeLKQ5A/JyjAIdlAK9zEBtuf+kBWNoQN85izVwftMQghpCVFIlUEqYA0Lbgo0a4bYvcDuCn6lIaekY2o2qoeS+CBKR0vp4DYFxVOBhAET92Sk1fODeZflvGkISJPMyXcKC1j1f50wN/X+cTxkb/+7r/IILbMtcxoD3sFIs29SgacaYizM/VKuAIcj7XMD9z7qTE7LQvbU+UL9C1ZyCms8havyrGkyODDWO8TNDI2bASzLtc08a9c3lAFVafqYn0ioSuP+FKpb5HopNeyEXh1U30sp1gmkPT/KF4VQdNt6joQ1El5SdpZra68IOkLrG92wKiWUPenAND+ubZYh5AX5fIOSUCAFZIzj1akGE9HJ1aA4+pHiIbC51dVvjtOVJnYWSkvOyiQteZs3Hmrr003R7COSVVbJqCYnUfcDr6HnyNT+ucoPMMpx1M1A7A3w4UQcfvxHEqOOITI/o7WMW52ZpMzBjc+o8fwSq2ybFA5SPetXTQnmyqD7B9Cx0/2s7J6neMsDPaM8H1gmHXZQBE4VPPAvoe6CrSy87I4Np3b2XH6+0coHBPChaI6Y0NGj+qqgOtKB/JSDERAU5zUELbhevPpAqOw71Cq/kuGMMC8PBAiO8Nflkkmx8Lv5qIwrAAu7NpFE4zjYAVtZw04SQxFXIxhqnXwqYkQoI/6ABMKKIacctGov1n1vIJYTC84pLHVqEnX+gGbA7JaCpewIdHvgOecgaA7l2/bSKNwck5J+7koD1GxOO9aM2YQvFpYa3VjbVTGSGzAglXaM40r+NVj/qjPbGdB/CoAnSIRfVPnJgoKtQHFC4fltm3IWJ2Xf/kQm3h4b/sks4V8AIwr6IGSE6ZtwsPA4tDDumbta2iGuZrEw9VQDad0kYJkMVZ767Kh4dx1os55jk7lbOvv9j0g7ryFMjmZx1NzfqswFa4e23yvyHpYoKjLxV2pFq2rByZifdPEWGrp37Zt7NgJtHU3wdjQSVuiB5UeX7q/1Kr8PDRWtRNxaZ55KmZhIswqwr7uji+qnsWGxq7hRtpcnPZk4GWN1GenpBHX+T/YTsylXBAOvpHWnj+r3YgcwkhTn4lrPZ3Ta9CXxMZMG2Cj1c3yvqfAHDDQ6uVHKXnai+vWJFUQvyPPsTU5njn3kBcptwnSptNPqzZnrE26qy6E8qK9bS6a1YhYjbw9J6W8ORJacJYfQj5OabGTcaBLC6zzY9GF9LsUy9WoVb8Fph5ydJLXkyARJwSlvWpzKc4psLKhtjcYIzBoEHg9SBTDrk4LKtiRjVaaa5sjjixib1O7fUkZEREG6IzhsJ3AOarRbSb1J1KpF5iC5Pc31yjkkt6yBstBqYLqINRff5nrNzT61i28ZwTZRIQtV9hb4JotJo50JJsHaN7idalZ47teRrIlvXQpOF3dkO1BHRN4rfEUHuIBV9/cdUz9ylqyQtb+qPmK7LD246H9bRZRj8e80DJtfwPBFjCPXYMCHO2a22aGIMjFXTeo1IHIdwvFIeevSHzzyDhfViknaGu6B7fEM5fGKmAbEZ5IpGxGK22UfXQDXHgOns0IDBUovgS5dlN0Ag2/swCS5i4ys/nzi01AJfm1HMfu7nIisBK39FJLDJlDycQjcvdk3tuwYktI+4uybnXl03PaE6re7+FV6FFveXYfpCrrHasAOs/Cj9isgbk+/vSSDVeS5324/DawlV54JCUsUA512ad167gCGZJcFOrxTl9vXke4fw2iHnX00q6sx3drNZ4LJxynSxiI0wF3i7Fm5c9poVQC2Tgko3usNDM8eojjVbi2e7dAPtWRi3rkAxT7Ad/RNY9EGcYg0j5KqOjeWm/leQhsgeqCQ1DVUeRCYb6q1w0Ghahd1ecmvEtm3HgtEOtBD6tPrgD5deUEjrnKLEUPKAiZMg3g5AnMEWEYVBfo/gpc37wp+luMjs3phHe2sx/l1eHOUrOR57jLxqsxOOh5FivBRv/RT2amc5n8PzA6RMLYPweF1kA5005TimawYHEfMf0bWoVe+arCeyk1MCrAKg+WlbzFC4UKH/wCYcD+Cy+kWAdfjuQxhCX3jmkgyTDO0dRzHEqbMv4NJn9zTmC3PqdA6JoXAgRvQhqYdY8x2iQA6SqUBu0K1D4BYPROSoJAp0T0e4zRAKzN2C6CS51DNYEFPS8XsvWemKYdkTKuohBfukUdyq8qz0LosLC1SmkMKxRo3iQGHJcBL+u/n1eUeHQJzwO1S79KibdwXyXOkV+m0/2TEYlzUFF5fy+kUBDPgnUPkiHNb23qTGXnry7vxE0L4Wv3hwwuHu9Au1a7ot3V/1pHcdeHusL+peR9npTVriMsAVzt4tCQDweVTgMwSuXi1J/bNo13hHR9tvw8jpJ7SW5avqTHxJT6g2PaOeztfT6h7CcxOJ1LHFUZKwLq4NNjMxJebdcX0sdYeOdO/ZsHfAN4RJbashe67ulqsoxk/rjRFkp/pbeXoC43TUByKxGcHUNpPs3u6gMH4L2mSsFs4+Euvk0gBhKqiO+CBtSauggZKrXzM9UFJsjtBNL6OSaPip3NVIG2bwUd1bhjLrdicVAGZBnoa6pIIBHndNMQCepZsPpM45OGQFDtpUIDvlrzO2uqlUqS87HYWz5hKfUri9nUwhBRnrkFkjbjchQMGDX9QcWHlfiS4GYT41OZfXWjbtrdOCw0CAvCaMH1906M4dZ3n3KnidtC0E9HU/Gq3hPNZPqN4iE4xuL9zresPyvjxWpdWzYOkmKP5qtqN5qN1xCW3Yv7HVHCblT9NbpIOKP4VbHQ4yXgrx5VQ1lDSueMFA71mvDGT7Dzdx299TH1v54oZmIofXC5suFSG7qNtlN+nbRlp6aGHeljaI6SF4vVjCBrH+H32lglJk2z27eT6jYXpnw3mfRw82czhOgBKOTFMNxFz17ydd3BQ5laBSn/6CNnLdwdhBmD8Agoyw4xDbu4YWmJtAy3OiiRRNF69KGg1+RqfaWaADpH8RLA4Bjlo00GwBUj4jeecFWjrGMbQaYwewUww/IVBt6BJR/qJ5gJpRQKnAe+NVWkrVrZk0PtEyNbMVLmWQrMPrK8nyUiZfrCmMzmpeUrNq5428Niegw+qbNRc35HbLxSOUuuDvkNytrkbuj7EAvwLlzgrAv43Mb5+0p5ywu+0+FrdbRPuivA7DysmFKFWNIF7yyLp8eqmHk0BtCzfMqWOL3ubUfht0T3o5P2eKuikRktslY5Vmwe9X3yUWMOU97UUHrfCFEU4MtNBe1lr2ylLccYE7PaBMwRnHgBum24WKAqlOfFV8FlU5wj2+J+VL1tR2OXdnjD03q9FfAi2MyYzIzY7HWF9ckw9bEb+kqQ1U0zXdtf0JYa0uZCO+ec14zIlvQm8GDspaMpf/y1cHgb4aI5dvD2OYE0CYucxfxVD9/Et68UbrIaXJNrD3LanALTLYKWOEtQOI+Gs1nFGp8SwWArRHJTsJN1LV8TcfdY6aGNBsMx74","encryption_version":"v0"}

O arquivo está criptografado e indisponível para acesso direto.

Ah, e se você tentar usar esse bloco de código com o Terraform, ele trará um erro:

$ terraform init -migrate-state
...

╷
│ Error: Unsupported block type
│
│   on main.tf line 10, in terraform:
│   10:   encryption {
│
│ Blocks of type "encryption" are not expected here.
╵

Extra: Mitigação na AWS com KMS

Uma pessoa mais sagaz poderia argumentar: "ah, é só usar a chave KMS para criptografar também o seu State File"!

$ cat 
terraform {
  backend "s3" {
    bucket = "devsres-terraform-state-storage"
    key    = "terraform/state/senha_root"
    region = "us-east-1"

    encrypt    = true
    kms_key_id = "arn:aws:kms:us-east-1:730335449394:key/9b8acab0-df09-4c2b-81ab-7dd33d2a4ba2"
  }
}

E é verdade, isso mitiga o acesso:

$ aws s3 cp s3://devsres-terraform-state-storage/terraform/state/senha_root /tmp/
download failed: s3://devsres-terraform-state-storage/terraform/state/senha_root to ../../tmp/senha_root An error occurred (AccessDenied) when calling the GetObject operation: User: arn:aws:iam::730335449394:user/hacker is not authorized to perform: kms:Decrypt on resource: arn:aws:kms:us-east-1:730335449394:key/9b8acab0-df09-4c2b-81ab-7dd33d2a4ba2 because no identity-based policy allows the kms:Decrypt action

Mas nem todo backend suporta esta funcionalidade. Salvo engano, não é possível usar com Azure Blobs; outros backends e usuários on-premises também ficam sem opção.

Como a AWS Cloud Control API e o novo Terraform provider impactam sua vida?

Marcelo Andrade — Thu, 06 Jun 2024 03:56:10 +0000

Recentemente, a Hashicorp anunciou que o provider AWS Cloud Control agora é considerável pronto para uso em produção (também conhecido como "Generally Available", ou GA):

A notícia é bem explicativa, mas percebi bastante confusão dentre meus conhecidos a respeito sobre o assunto, então vamos falar sobre! O que é AWS Cloud Control, como funciona, o que faz este novo provider e qual o impacto na sua vida!

Terraform Provider AWS

Se você usa Terraform (ou OpenTofu) e AWS, então provavelmente você usa o Terraform Provider AWS para provisionar sua infraestrutura.

Disponível desde o Terraform 0.1 (2014!), este possivelmente é o provider mais antigo da solução e de longe o mais conhecido e usado.

O que a notícia compartilhada tem a ver com este provider?

Nada!

Este provider usa a mesma API que a AWS SDK e o AWS CLI, por exemplo.

Por falar em AWS CLI...

AWS API e suas inconsistências

Se você já usou a AWS CLI, provavelmente já percebeu algumas "particularidades".

As APIs da AWS foram construídas ao longo de quase 20 anos; serviços de épocas diferentes certamente foram desenvolvidos por equipes diferentes a partir de modelos e ideias diferentes. Além disso, serviços antigos são extendidos possivelmente por outras equipes que implementam recursos do seu jeito.

Combinado ao tamanho e variedade de ofertas, essa característica torna torna a API extremamente inconsistente em seu comportamento. Vamos a um exemplo bem simplório mas que ilustra adequadamente o que queremos dizer.

Para listar as máquinas virtuais de uma determinada região, você executa:

$ aws ec2 describe-instances

Para listar seus bancos gerenciados do serviço RDS:

$ aws rds describe-db-instances

Por outro lado, se você quiser os buckets S3 de uma conta, você usa o seguinte comando:

aws s3 ls

Para listar todas as Kinesis streams:

$ aws kinesis list-streams

O subcomando s3 da AWS CLI é tão esquisito que a AWS optou por implementar uma nova API para trabalhar com s3 e não quebrar a retrocompatibilidade - o subcomando s3api. Este subcomando usa a versão mais "moderna", parecida com o Kinesis, que usa list como verbo em vez de describe:

$ aws s3api list-buckets

Se você achou bobagem essas divergências, saiba que isso tem seu custo, em especial se você vai além das operações triviais. Como essas particularidades não são da linha de comando e sim da API, elas se apresentam também na AWS SDK, e isso pode ser um problema, em especial para quem desenvolve soluções third-party que integram com serviços AWS. Observe o post abaixo:

Então eu não sou o primeiro a apontar que isso incomoda!

AWS Cloud Control

Curiosamente, no mesmo ano da notícia anterior, a AWS anunciou a API Cloud Control, cujo propósito é resolver justamente esse problema de consistência:

A própria AWS admite os problemas:

As applications and infrastructures become increasingly sophisticated and you work across more AWS services, it becomes increasingly difficult to learn and manage distinct APIs. This challenge is exacerbated when you also use third-party services in your infrastructure, since you have to build and maintain custom code to manage both the AWS and third-party services together.

Qual era a ideia então? Oferecer uma "interface padrão" para as operações em todos os serviços da AWS. No caso, implementar as operações de um CRUDL (o mesmo que um CRUD, mas com um List junto!):

CreateResource;
GetResource;
UpdateResource;
DeleteResource;
ListResource.

Como funciona na prática? Vamos criar um bucket S3:

$ aws cloudcontrol create-resource \
      --type-name AWS::S3::Bucket \
      --desired-state '{
        "BucketName": devsres-cloudcontrol-lab
        }'
{
    "ProgressEvent": {
        "TypeName": "AWS::S3::Bucket",
        "Identifier": "devsres-cloudcontrol-lab",
        "RequestToken": "6b47f322-d9af-4d08-8faa-6d530f33bcff",
        "Operation": "CREATE",
        "OperationStatus": "IN_PROGRESS",
        "EventTime": "2024-06-05T22:16:06.220000-03:00"
    }
}

Criando uma stream Kinesis:

$ aws cloudcontrol create-resource \
    --type-name AWS::Kinesis::Stream \
    --desired-state '{
      "Name": "ResourceExample",
      "RetentionPeriodHours":168, 
      "ShardCount\":3
      }'

Quer criar um CloudWatch LogGroup?

$ aws cloudcontrol create-resource \
 --type-name AWS::Logs::LogGroup   \
 --desired-state '{
   "LogGroupName": "DevSREsCloudControlLG",
   "RetentionInDays":30
   }'
{
    "ProgressEvent": {
        "TypeName": "AWS::Logs::LogGroup",
        "Identifier": "DevSREsCloudControlLG",
        "RequestToken": "7fe86619-dda1-4698-beb0-7bcf29c22868",
        "Operation": "CREATE",
        "OperationStatus": "IN_PROGRESS",
        "EventTime": "2024-06-04T00:56:17.364000-03:00"
    }
}

Para listar os buckets existentes:

$ aws cloudcontrol list-resources --type-name AWS::S3::Bucket
{
    "ResourceDescriptions": [
        {
            "Identifier": "devsres-cloudcontrol-lab",
            "Properties": "{\"BucketName\":\"devsres-cloudcontrol-lab\"}"
        },
        {
            "Identifier": "outro-bucket-criado-de-outro-jeito",
            "Properties": "{\"BucketName\":\"outro-bucket-criado-de-outro-jeito\"}"
        },
        {
            "Identifier": "terceiro-bucket-criado-de-outro-jeito",
            "Properties": "{\"BucketName\":\"terceiro-bucket-criado-de-outro-jeito\"}"
        }
    ],
    "TypeName": "AWS::S3::Bucket"
}

Quer listar os CloudWatch LogGroups?

$ aws cloudcontrol list-resources --type-name AWS::Logs::LogGroup
{
    "ResourceDescriptions": [
        {
            "Identifier": "DevSREsCloudControlLG",
            "Properties": "{\"RetentionInDays\":30,\"LogGroupClass\":\"STANDARD\",\"LogGroupName\":\"DevSREsCloudControlLG\",\"Arn\":\"arn:aws:logs:us-west-2:211125357951:log-group:DevSREsCloudControlLG:*\"}"
        },
        {
            "Identifier": "OutroLogGroup",
            "Properties": "{\"RetentionInDays\":30,\"LogGroupClass\":\"STANDARD\",\"LogGroupName\":\"OutroLogGroup\",\"Arn\":\"arn:aws:logs:us-west-2:211125357951:log-group:OutroLogGroup:*\"}"
        },
        {
            "Identifier": "TerceiroLogGroup",
            "Properties": "{\"RetentionInDays\":30,\"LogGroupClass\":\"STANDARD\",\"LogGroupName\":\"TerceiroLogGroup\",\"Arn\":\"arn:aws:logs:us-west-2:211125357951:log-group:TerceiroLogGroup:*\"}"
        }
    ],
    "TypeName": "AWS::Logs::LogGroup"
}

Não sei se você prestou atenção, mas a solicitação de criação não é concluída de maneira síncrona:

$ aws cloudcontrol create-resource \
      --type-name AWS::S3::Bucket       \
      --desired-state '{
        "BucketName": "ele-nao-espera-concluir"
      }'
{
    "ProgressEvent": {
        "TypeName": "AWS::S3::Bucket",
        "Identifier": "ele-nao-espera-concluir",
        "RequestToken": "e871792e-1467-45cb-bd0d-9ac8041825e2",
        "Operation": "CREATE",
        "OperationStatus": "IN_PROGRESS",
        "EventTime": "2024-06-05T23:52:02.801000-03:00"
    }
}

O OperationStatus IN_PROGRESS indica que a solicitação está sendo processada. Para acompanhar o status, usa-se outro comando passando o RequestToken:

$ aws cloudcontrol get-resource-request-status \
      --request-token e871792e-1467-45cb-bd0d-9ac8041825e2
{
    "ProgressEvent": {
        "TypeName": "AWS::S3::Bucket",
        "Identifier": "ele-nao-espera-concluir",
        "RequestToken": "e871792e-1467-45cb-bd0d-9ac8041825e2",
        "Operation": "CREATE",
        "OperationStatus": "SUCCESS",
        "EventTime": "2024-06-05T23:52:25.022000-03:00"
    }
}

A solicitação foi atendida com sucesso.

E se tentarmos criar o mesmo bucket novamente?

$ aws cloudcontrol create-resource \
      --type-name AWS::S3::Bucket       \
      --desired-state '{
        "BucketName": "ele-nao-espera-concluir"
      }'
{
    "ProgressEvent": {
        "TypeName": "AWS::S3::Bucket",
        "Identifier": "ele-nao-espera-concluir",
        "RequestToken": "c965b56a-7a25-4b70-b084-6e733db0c6c3",
        "Operation": "CREATE",
        "OperationStatus": "IN_PROGRESS",
        "EventTime": "2024-06-05T23:57:55.038000-03:00"
    }
}

$ aws cloudcontrol get-resource-request-status \
      --request-token c965b56a-7a25-4b70-b084-6e733db0c6c3
{
    "ProgressEvent": {
        "TypeName": "AWS::S3::Bucket",
        "Identifier": "ele-nao-espera-concluir",
        "RequestToken": "c965b56a-7a25-4b70-b084-6e733db0c6c3",
        "Operation": "CREATE",
        "OperationStatus": "FAILED",
        "EventTime": "2024-06-05T23:57:55.311000-03:00",
        "StatusMessage": "ele-nao-espera-concluir already exists (Service: S3, Status Code: 0, Request ID: null)",
        "ErrorCode": "AlreadyExists"
    }
}

Como era esperado, o retorno da requisição é uma falha, e StatusMEssage te explica o porquê.

Genial! Quando migramos?

Parece legal, certo? E realmente é.

Mas você precisa se perguntar da relevância dessa mudança na sua vida e no seu código.

Faz sentido você migrar todas as suas stacks de código Terraform para usar o novo provider?

A resposta, provavelmente, é não - o ganho é mínimo para a infraestrutura pré-existente, em especial se levado em consideração a massiva quantidade de trabalho que essa migração demandaria.

Faz sentido você passar a escrever todos os códigos Terraform daqui pra frente usando única e exclusivamente a API Cloud Control com seu novo provider?

Aqui temos algo passível de discussão. Mas, na minha opinião, não vejo como imperativa a troca. O provider acabou de ser lançado como GA; a maturidade do software e a base de usuários que o adotou nem se comparam com o provider original.

A própria API Cloud Control não tem tanta popularidade assim - em uma rápida pesquisa que fiz no meu perfil, quase ninguém havia sequer ouvido falar a respeito. Uma base menor de usuários no mínimo aumenta a possibilidade de incorrer em maior quantidades de bugs e comportamentos inesperados - tanto do provider quanto da própria API Cloud Control.

Esse fato, por si só, não deveria desencorajar a adoção de um software, mas sabemos que nem todos estão prontos para se tornarem Early Adopters.

Para quem é o Cloud Control então?

A AWS responde sua pergunta no seu anúncio de 2021: pessoas que construam soluções que operam usando serviços da AWS (especialmente se usarem muitos serviços!). Trouxe o excerto em inglês original para cá:

Builders - The first community is builders using AWS Services APIs to manage their infrastructure or their customer’s infrastructure. The ones requiring usage of low-level AWS Services APIs rather than higher level tools. For example, I know companies that manages AWS infrastructures on behalf of their clients. Many developed solutions to list and describe all resources deployed in their client’s AWS Accounts, for management and billing purposes. Often, they built specific tools to address their requirements, but find it hard to keep up with new AWS Services and features. Cloud Control API simplifies this type of tools by oﬀering a consistent, resource-centric approach. It makes easier to keep up with new AWS Services and features.

APN Partners - The second community that benefits from Cloud Control API is APN Partners, such as HashiCorp (maker of Terraform) and Pulumi, and other APN Partners offering solutions that relies on AWS Services APIs. When AWS releases a new service or feature, our partner’s engineering teams need to learn, integrate, and test a new set of AWS Service APIs to expose it in their offerings. This is a time consuming process and often leads to a lag between the AWS release and the availability of the service or feature in their solution. With the new Cloud Control API, partners are now able to build a unique REST API code base, using unified API verbs, common input parameters, and common error types. They just have to merge the standardized pre-defined uniform resource model to interact with new AWS Services exposed as REST resources.

Se você não lê em inglês (melhore isso já!), vamos usar um exemplo.

A AWS anunciou, no fim de abril, um novo serviço (nº 356?) de "render farms" gerenciado com o pouco sugestivo¹ nome Deadline Cloud. Suponha que você trabalhe em uma empresa que faz trailers de filmes e tem interesse em usar este serviço; você não pode usar o terraform provider aws simplesmente porque ele ainda não é suportado:

Isso quer dizer que você não pode usar sua infra-estrutura de IaC com Terraform para usar este serviço, certo?

Ou pode?

Como a própria Hashicorp conta em seu comunicado do post original:

Initially launched in 2021 as a tech preview, the Terraform AWS Cloud Control provider is automatically generated based on the Cloud Control API published by AWS, which means the latest features and services on AWS can be supported right away. The AWSCC provider gives developers access with several new AWS services such as: AWS Billing Conductor, AWS Chatbot, Amazon Personalize, Amazon Q Business, and more.

Em uma tradução livre, o provider Cloud Control para Terraform é gerado automaticamente usando como base a API disponibilizada pela AWS. Teoricamente isso quer dizer que qualquer funcionalidade disponibilizada pela AWS estará disponível quase que imediatamente.

Mas há detalhes adicionais! A lista de serviços acima do excerto em inglês lista os serviços Amazon Q Business (lançado em maio de 2024), AWS Billing Conductor (lançado em 2022), AWS Chatbot (lançado em 2020!) e Amazon Personalize, que foi lançado há quase 5 anos atrás!

Isso dá uma ideia que não é só uma questão de "usar os serviços lançados ontem", mas também usar serviços mais obscuros e menos usados, cuja baixa popularidade faz com que a implementação no provider principal não atinja massa crítica o suficiente para se justificar o tempo gasto (como o Amazon Personalize), oferecendo uma alternativa às pessoas que não conseguiam usar o mesmo padrão e convenções de IaC para 100% de sua infraestrutura na AWS.

Conclusão

Para a Hashicorp e Pulumi, naturalmente seria muito melhor se todos abandonassem seus providers oiginais e migrassem para os novos baseados em Cloud Control.

Mas esse desejo provavelmente não significa que irão descontinuar os providers originais e só oferecer manutenção nos novos - eles certamente não são loucos o suficiente para fazê-lo (ou são?).

Se sua empresa está interessada em usar os serviços mais novos (em especial o festival de ofertas sobre generative AI), serviços mais obscuros (como o Amazon Personalize) ou simplesmente tem o perfil "early adopter", em que os funcionários contam com espaço para depurar e contribuir com projetos, lembre-se: a API Cloud Control existe, e agora temos inclusive um Terraform Provider considerado pronto para uso em produção.

Aproveitem!

¹ O nome do serviço não é tão pouco sugestivo assim; na verdade não é sugestivo para você! Em 2017, a AWS comprou uma empresa chamada Thinkbox Software, que construía, entre outras coisas, soluções para gerenciamento e pós processamento de renderizações. A mais popular das ferramentas se chama Deadline; logo, AWS Deadline Cloud é o deploy automatizado deste software na nuvem.

EBS, seus snapshots e quanto ocupam de espaço

Marcelo Andrade — Fri, 16 Feb 2024 01:22:50 +0000

Se você for chato como eu, provavelmente não fica nada satisfeito com a seguinte informação fornecida pelos Snapshots dos seus discos EBS:

$ aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[0]' | jq '{ "Id" :.SnapshotId, "Tamanho": .VolumeSize } '
{
  "Id": "snap-0ad47bdaaf65a4a33",
  "Tamanho": 300
}

Por que eu digo isso? Se você pegar uma lista com os snapshots diários realizados de um disco, todos eles vão ter esse tamanho "300", que é na verdade o tamanho do disco do qual foi tirado o snapshot:

jq -r  '.Snapshots[] | "\(.StartTime | sub("\\.[:+0-9]*"; "") | strptime("%Y-%m-%dT%H:%M:%S") | strftime("%Y-%m-%d %H:%M:%S") );\(.VolumeId);\(.SnapshotId);\(.VolumeSize)"'  /tmp/snapshots  | sort | fgrep 2024-01 | fgrep volumeAlvo | cut -f1,3,4 -d';'
2024-01-12 06:52:14;snap-1e61c51bff6bccb1c;300
2024-01-13 06:50:26;snap-156ff8793f546c40c;300
2024-01-14 06:50:35;snap-1540ae07ff3f2fafc;300
2024-01-15 06:55:12;snap-1deffec06fff3a76c;300
2024-01-16 06:50:55;snap-1936dd665a700507c;300
2024-01-17 06:48:18;snap-188a940760ef0c94c;300
2024-01-18 06:49:03;snap-1945f27eae3a35e7c;300
2024-01-19 06:51:01;snap-176d9fee762cfb56c;300
2024-01-20 06:50:14;snap-115fe1148762c5f3c;300
2024-01-21 06:51:17;snap-10d4a9af2fb8939fc;300
2024-01-22 06:50:02;snap-1e37bafc822cc7b4c;300
2024-01-23 06:50:51;snap-11ee2feb0c80bf6cc;300
2024-01-24 06:52:55;snap-15c1f5bfd8c973b1c;300
2024-01-25 06:50:05;snap-1236f4771ac4ff4fc;300
2024-01-26 06:52:34;snap-135de7fda2ca0039c;300
2024-01-27 06:54:12;snap-1a2b6f44c3b250fac;300
2024-01-28 06:49:42;snap-15afe58c720ea661c;300
2024-01-29 06:50:24;snap-1c2cb9f83d180b5dc;300
2024-01-30 06:51:31;snap-19292f66969ae91cc;300
2024-01-31 06:49:24;snap-183c70ef3ce184b1c;300

E isso não faz sentido, porque vamos relembrar a definição de snapshot para a AWS:

You can back up the data on your Amazon EBS volumes by making point-in-time copies, known as Amazon EBS snapshots. A snapshot is an incremental backup, which means that we save only the blocks on the device that have changed since your most recent snapshot.

Ou seja, o primeiro snapshot pode até ter próximo de 300 GiB; o segundo, entretanto, a menos que você reescreva o disco inteiro todos os dias, deverá ter bem menos blocos!

E como fazer para saber o tamanho real de um snapshot? A resposta é que não há uma maneira conveniente.

Então vamos de maneira inconveniente mesmo!

A partir da saída acima, podemos gerar um arquivo:

$  jq -r  '.Snapshots[] | "\(.StartTime | sub("\\.[:+0-9]*"; "") | strptime("%Y-%m-%dT%H:%M:%S") | strftime("%Y-%m-%d %H:%M:%S") );\(.VolumeId);\(.SnapshotId);\(.VolumeSize)"'  /tmp/snapshots  | sort | fgrep 2024-01 | fgrep <volume> | cut -f1,3,4 -d';' > /tmp/snaps

Vamos comparar a diferença dos blocos do primeiro snapshot para o último:

$ aws ebs list-changed-blocks  --first-snapshot-id snap-1e61c51bff6bccb1c --second-snapshot-id snap-183c70ef3ce184b1c  --max-results 100
{
    "ChangedBlocks": [
        {
            "BlockIndex": 2,
            "FirstBlockToken": "ADEBAWTl1T2vIApHeiKgKcuwBAiqZ3klr66mE47BZomkZvBk1xa7l6Se3EVy",
            "SecondBlockToken": "ADEBAZC7wx3B//8SZ8AO8Ik4nO3drO69ZHydPGfiFdQPf7+z0/yeTvhtpdPk"
        },
        {
            "BlockIndex": 3,
            "FirstBlockToken": "ADEBAUFwRyPWnxXmE9tuUiGA0/IZNMT6QeArgY6LEUPzqfc1kla8X1RE682F",
            "SecondBlockToken": "ADEBAXZa8N6xIhaeQmNpB4Ryg0c71c3hfJggUam5aRWzXtsOMIM+o7B8gTMz"
        },
        {
            "BlockIndex": 9,
            "FirstBlockToken": "ADEBAY/0eak3ujr8ZeaKojwpqpDdDgkEEoJbwm1qQq3ZD8OGgZJWWawJ3gAP",
            "SecondBlockToken": "ADEBAZMWcWKeWoOVSmSoddWfqIpt4MJb7jC8pczPc2Zb5bzDhaXdOcy5igEx"
        },
        {
            "BlockIndex": 54,
            "FirstBlockToken": "ADEBAWVhyEKJPSo3dngCxFvu+thS+Wxb6bIsya3oW/7BhdXgKwXAEd1pf8le",
            "SecondBlockToken": "ADEBAZ/wRcFMm0dps8ORFkiSutXRI+UBS+Zx5sQ0nUonUTwBP6oQg0XcsTTI"
        },
        {
            "BlockIndex": 63,
            "FirstBlockToken": "ADEBAbG6AUCqy8i8iTha8TsuS/KJjkR6m2orwTiWu6x1TRnhF9nZQeNryPNG",
            "SecondBlockToken": "ADEBAa1CD96xB6tGbtqNlh2L0oRVcsQTWB5Zt2oFaYnF9r3Nl0BkdTXoMrgU"
        }
    ],
    "ExpiryTime": "2024-02-22T23:27:36.911000-03:00",
    "VolumeSize": 300,
    "BlockSize": 524288,
    "NextToken": "ADEDAfg20tH5S6MgIQvwejESz9oJt6wTkV9E7uLE/AWOE3YldGqcD87vayC4iR409U/UlvchfJ31"
}

"Temos 800 TiB de snapshots!"

Em um outro caso, alguém ficou horrorizado porque tínhamos quase 800TiB de snapshots de um backup de um disco que não estava sendo usado!

Mas... Se o disco não está sendo usado, os snapshots subsequentes possivelmente estão vazios, pois não há diferença entre os blocos!

Vamos olhar?

$ jq -r  '.Snapshots[] | "\(.StartTime | sub("\\.[:+0-9]*"; "") | strptime("%Y-%m-%dT%H:%M:%S") | strftime("%Y-%m-%d %H:%M:%S") );\(.VolumeId);\(.SnapshotId);\(.VolumeSize)"'  /tmp/snapshots  | sort | fgrep 2024-01 | fgrep <outro volume> | cut -f1,3,4 -d';' > /tmp/snaps

$ head /tmp/snaps
2024-01-12 05:08:57;snap-021dd9ce209e29e04;8000
2024-01-13 05:04:54;snap-0bb0b0a4ba1aa52a4;8000
2024-01-14 05:05:34;snap-0235d8d888956aabc;8000
2024-01-15 05:05:45;snap-0b438036484680c4d;8000
2024-01-16 05:02:47;snap-0224676f259ea425c;8000

Vamos separar o primeiro snapshot (que tem o disco inteiro) e comparar com todos os demais:

FIRST=$( head -n1 /tmp/snaps | cut -f2 -d';' ) ; for i in $( tail -n+2 /tmp/snaps | cut -f2 -d';' ) ; do  echo -n $i: ; aws ebs list-changed-blocks --first-snapshot-id $FIRST --second-snapshot-id $i | jq '.ChangedBlocks | length' ; done
snap-02b0b0a4ba1aa52a4:0
snap-0b35d8d888956aabc:0
snap-02438036484680c4d:0
snap-0b24676f259ea425c:0
snap-02356588643dade8c:0
snap-05391e8ce8e97ac09:0
snap-022654ea634922940:0
snap-0c559252bb1323192:0
snap-0197cfa3b57dd112a:0
snap-0baf04b1bc66d9fbe:0
snap-0c8139bca34c3fa2b:0
snap-01a13015e939ec730:0
snap-03c616d28c4c2f8e2:0
snap-00d3d9a860deebf38:0
snap-0e98d71bec134ca26:0
snap-0374d3f4ce87bad9e:0
snap-0f797d4836e05681d:0
snap-0b305c3b79e375f36:0
snap-06338105ef6571bee:0

Mostrando sem o jq:

...
# Saída sem o jq:
snap-02b0b0a4ba1aa52a4:{
    "ChangedBlocks": [],
    "ExpiryTime": "2024-02-15T22:16:59.026000-03:00",
    "VolumeSize": 8000,
    "BlockSize": 524288,
    "NextToken": "ADEDAao20vaMS6MgIahZ7GoSz9o7FPruoV9E7tDE4qoDE3YldGqcD84P8/h4vpdT5TY/6I/kb8Ud"
}

Ou seja, esses snapshots definitivamente não estão ocupando 800TiB, ou o custo seria na casa de 55 mil dólares!

EBS Direct API

Este recurso não tão conhecido é a API pela qual podemos disparar a criação de snapshots.

Só que vai muito além! Com ela, é possível ler e escrever dados em snapshots, além de analisar as diferenças entre snapshots da mesma origem!

Nota de rodapé pensando em segurança

Eu naturalmente estava interessado apenas na funcionlaidade de listar as diferenças entre snapshots. Mas vai aqui algumas informações importantes sobre este serviço sob a ótica da segurança.

Na documentação é possível consultar os comandos da EBS Direct API:

start-snapshot
complete-snapshot
get-snapshot-block
list-changed-blocks
list-snapshot-blocks
put-snapshot-block

Se você olhar o site, eu mudei a ordem propositalmente.

Os dois primeiros são considerados Management Events pela API da AWS, e portanto são logados por padrão pelo CloudTrail.

Os outros quatro, entretanto, são considerados Data Events. E como você bem sabe (provavelmente porque já precisou ir atrás de quem deletou algo de um bucket S3), este tipo de evento não é logado por padrão no CloudTrail!

Ou seja, alguém pode usar get-snapshot-block para baixar pedaços dos seus discos e você nunca vai saber a menos que tenha data events ativado em uma Trail! Maneira extremamente maliciosa de surrupiar dados dos outros.

Usando cURL para diagnóstico de problemas

Marcelo Andrade — Wed, 20 Dec 2023 01:53:32 +0000

"O sistema está lento".

Que sysadmin/devops/SRE (ou seja lá qual o branding moderno para o responsável pela infra) não odeia essa declaração, porque ela não te diz absolutamente nada.

A aplicação está lenta? Ou é o servidor de aplicação? Ou o balanceador? Ou o storage?

E se a aplicação for distribuída, o problema fica 100 vezes maior.

A maneira moderna de fazer diagnóstico deste tipo de problema é usar Application Performance Monitoring, ou monitoramento de performance de aplicações, geralmente caríssimas, para entregar a resposta que você quer.

Mas o assunto não é este hoje; a ideia é tentar usar o cURL para identificar certos problemas de maneira mais ágil.

curl custom output

Você certamente está acostumado a usar cURL para testar conectividade com um site:

# Qual a versão do kubectl mais nova?
$ curl -L -s https://dl.k8s.io/release/stable.txt
v1.29.0

Ou ainda baixar um programa:

# Vamos baixar o kubectl!
$ 
$ curl -LO "https://dl.k8s.io/release/$LATEST/bin/linux/amd64/kubectl"
...

$ ls -l kubectl
-rw-r--r-- 1 marcelo marcelo 49704960 Dec 19 20:30 kubectl

Mas é possível customizar a saída com diversas coisas. A que mais uso é, de longe, a resposta HTTP:

$ curl www.google.com -so /dev/null -w '%{http_code}\n'
200

Uma maneira extremamente ineficiente de testar se uma aplicação está com problemas é disparar uma rajada de curl sobre ela e analisar a saída:

$ for i in {1..100} ; do 
  curl -so /dev/null 127.0.0.1 -w '%{http_code}\n' ;
done | sort | uniq -c
     83 200
      3 500
      5 503
      9 504

Como eu falei, é uma maneira extremamente ineficiente - você se daria melhor executando testes com uma ferramenta de verdade. Mas quando você está on-call com notebook e te acionam...

Este link tem as variáveis que podem ser usadas juntamente com o programa --write-out.

Variáveis de writeout para exibir tempos

Suponha que você queira saber quanto tempo um download demora, muita gente gosta de usar o comando time:

$ LATEST="$( curl -L -s https://dl.k8s.io/release/stable.txt )"
$ time curl -sLO "https://dl.k8s.io/release/$LATEST/bin/linux/amd64/kubectl"

real    0m0.523s
user    0m0.132s
sys     0m0.141s

Mas a melhor maneira é pedir para o próprio cURL trazer esta métrica!

$ LATEST="$( curl -L -s https://dl.k8s.io/release/stable.txt )"
$ curl -sLO  -w '%{time_total}\n' \
"https://dl.k8s.io/release/$LATEST/bin/linux/amd64/kubectl"
0.441882

A parte interessante é que existem muitas variáveis diferentes de tempo para usar, o que pode ser um excelente recurso na depuração de certos problemas!

Este blog teve a ideia legal de criar um arquivo com o seguinte formato:

$ cat > curl-format.txt << EOF
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
———\n
time_total: %{time_total}\n
EOF

E agora podemos passar este arquivo para o cURL:

$ curl -w "@curl-format.txt" -o /dev/null -s http://devsres.com

time_namelookup: 0.000964
time_connect: 0.002114
time_appconnect: 0.000000
time_pretransfer: 0.002148
time_redirect: 0.000000
time_starttransfer: 0.010617
———
time_total: 0.010684

Genial, não é?

Bem, para achar genial, você precisa saber para que serve cada etapa e como usá-las em diagnóstico.

Vou usar o primeiro, time_namelookup apenas como exemplo!

time_namelookup

O poder de diagnóstico desta diretiva não pode ser mensurado!

Problemas de DNS tendem a ser de difícil diagnóstico para pessoas sem background de redes. Mas observe o seguinte teste em uma máquina que está "consistentemente lenta":

$ curl -w "@curl-format.txt" -o /dev/null -s http://devsres.com
time_namelookup: 5.139453
time_connect: 5.156280
time_appconnect: 0.000000
time_pretransfer: 5.156360
time_redirect: 0.000000
time_starttransfer: 5.172965
———
time_total: 5.173074

Apenas para referência, estes são os tempos esperados em um dia normal:

$ curl -w "@curl-format.txt" -o /dev/null -s http://devsres.com
time_namelookup: 0.046703
time_connect: 0.047609
time_appconnect: 0.000000
time_pretransfer: 0.047647
time_redirect: 0.000000
time_starttransfer: 0.050434
———
time_total: 0.050491

Sabe porque o primeiro teste levou mais de 5 segundos? Porque esse é o tempo padrão que o linux resolver espera para testar a resolução usando o seu servidor secundário!

(man resolv.conf)
timeout:n

Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server. This may not be the total time taken by any resolver API call and there is no guarantee that a single resolver API call maps to a single timeout. Measured in seconds, the default is RES_TIMEOUT (currently 5, see ). The value for this option is silently capped to 30.

Configurar múltiplos servidores DNS no seu /etc/resolv.conf é útil para garantir resiliência, mas o ambiente ficará severamente degradado caso o primeiro servidor falhe se precisar resolver nomes para seu funcionamento!

É possível reduzir esse tempo de timeout com a seguinte diretiva em seu resolv.conf:

$ cat /etc/resolv.conf
options timeout:1
nameserver 192.168.0.53
nameserver 1.1.1.1
nameserver 8.8.8.8

A configuração entra em vigor imediatamente:

$ curl -w "@curl-format.txt" -o /dev/null -s http://devsres.com
time_namelookup: 1.115452
time_connect: 1.135235
time_appconnect: 0.000000
time_pretransfer: 1.135265
time_redirect: 0.000000
time_starttransfer: 1.151118
———
time_total: 1.151194

Se não funcionar, talvez seja necessário ajudar esse parâmetro usando network manager.

Neste caso, usamos este parâmetro para permitir identificar que a causa do problema é o não funcionamento do servidor DNS do cliente, e não a aplicação! É um excelente primeiro teste a fazer para identificar se realmente há um problema no seu ambiente, antes de fazer dezenas de verificações e constatar que está tudo ok!

Como o RSYNC funciona?

Marcelo Andrade — Sun, 17 Dec 2023 19:01:25 +0000

Em um determinado projeto esta semana, comentei que o clássico programa rsync, na verdade, não faz análise de checksum por padrão na hora de identificar que arquivos transferir. Isso surpreendeu algumas pessoas!

Então acredito que compartilhar este "mini-lab" com explicações ajude você a entender o básico do funcionamento do rsync!

RSYNC é assunto para PHD!

O Tridgell , um dos criadores do rsync, descreveu o funcionamento do programa em sua tese de Ph.D. em 1999, e você pode lê-la aqui.

Como nós não somos acadêmicos aqui e queremos apenas usar a ferramenta, vamos decompor duas partes importantes do funcionando do rsync:

Como ele determina que arquivos precisam ser enviados para o destino;
Quais as partes do arquivo foram alteradas e precisam ser enviadas para o destino

São duas coisas totalmente diferentes, mas que geram a confusão que eu entendo que muitas pessoas fazem.

Analisando apenas a parte 2., o rsync é capaz de, a partir de um arquivo com determinado tamanho, dividí-lo em pedaços, calcular um hash para cada pedaço, e identificar qual pedaço precisa ser enviado. Isso é excepcionalmente útil na hora de transferir um arquivo muito grande mas que é 99,9% igual na origem ou no destino. Um exemplo seriam arquivos de logs gerados de maneira progressiva ou massas de dados incompletas que foram transferidas parcialmente por interrupção do serviço. Nessas horas, você pode contar com o rsync para transferir apenas o incremento de 1 ou 2 GiB, e não os 10TiB exatamente iguais do arquivo.

Mas essa operação de checksum é processada após o rsync entender que o arquivo precisa ser enviado. Isso não quer dizer que o rsync executa um checksum em cada arquivo para saber que ele precisa ser alterado.

É extremamente importante não confundir as duas coisas, são etapas diferentes!

Que arquivos precisam ser enviados para o destino?

A resposta está no man rsync

Rsync finds files that need to be transferred using a "quick check" algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file's data does not need to be updated.

Então, o "algoritmo" padrão de detecção nem merece um nome bonito, chamado de quick check. Ele observa mudanças no tamanho do arquivo ou na data e hora da última modificação (ou mtime).

Algumas pessoas chamam esse algoritmo de checkrq ou lquick ou ainda pior lquickcheckrq por causa desta página:

Isso inclusive uma grande piada interna de alguns usuários mais atentos:

O lq do 'lqquick' e o rq do 'checkrq' são, na verdade, o "left quote" e "right quote" da manpage mal transpostos do formato man para html! Logo, por favor, não chame o algoritmo de "checkrq" ou você corre o risco de alguém gargalhar na sua frente!

Mas a parte importante é essa: rsync, por padrão, não executa checksum nos arquivos para decidir se ele precisa transferí-lo (inteiro ou seus pedaços) ou não. Ele executa uma simples análise de timestamp e tamanho.

Por quê? Porque é muito mais rápido e extremamente efetivo! Qual a chance de um arquivo com mesmo tamanho e mesmo mtime ser diferente em duas origens que comumente se sincronizam?

Enganando o rsync:

Vamos fazer um lab.

mkdir -p /tmp/testersync/{origem,destino}

echo "O rsync nao faz checksum por padrao" > /tmp/testersync/origem/arquivo

Se, um tempo depois, você criar um arquivo igual no destino:

echo "O rsync nao faz checksum por padrao" > /tmp/testersync/destino/arquivo

E usar o rsync:

rsync -avi /tmp/testersync/origem/ /tmp/testersync/destino
sending incremental file list
>f..t...... arquivo

Esse t na saída do log mostra que ele notou que o timestamp está diferente.

Se você mudar o tamanho da frase:

echo "Claro que o rsync faz checksum por padrao, oras" > /tmp/testersync/destino/arquivo

Agora o rsync vai falar que ele mudou não só o timestamp mas o tamanho:

rsync -avi  /tmp/testersync/origem/ /tmp/testersync/destino
sending incremental file list
>f.st...... arquivo

Agora vamos tentar enganar o rsync. Vou criar o arquivo com a mesma frase, mas toda em maiúscula:

cat /tmp/testersync/origem/arquivo | tr '[a-z]' '[A-Z]' > /tmp/testersync/destino/arquivo

Do ponto de vista computacional, claramente eles são diferentes:

find /tmp/testersync -type f -exec sha256sum '{}' \+
f27d88d52759a4b07c077f34c230c47b94ea88b6640fc47b44d562243966eb7e  /tmp/testersync/destino/arquivo
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/origem/arquivo

O tamanho é o mesmo:

find /tmp/testersync -type f -printf '%P: %s\n'
destino/arquivo: 36
origem/arquivo: 36

Mas se você usar o rsync, ele vai retransferir o arquivo porque o mtime é diferente, e isso é um grande indicador que algo mudou no arquivo:

find /tmp/testersync -type f -printf '%P: %t\n'
destino/arquivo: Sun Dec 17 14:45:20.4011998470 2023
origem/arquivo: Sun Dec 17 14:43:11.4812008470 2023

Então, se você executar o rsync, ele vai substituir o arquivo:

rsync -avi /tmp/testersync/origem/ /tmp/testersync/destino
sending incremental file list
>f..t...... arquivo

find /tmp/testersync -type f -exec sha256sum '{}' \+
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/destino/arquivo
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/origem/arquivo

Só que isso é bem diferente de executar análise de checksum, que em larga escala, pode ser muito ineficiente.

Vamos enganar o rsync. Primeiro recrio o arquivo diferente:

cat /tmp/testersync/origem/arquivo | tr '[a-z]' '[A-Z]' > /tmp/testersync/destino/arquivo

Depois eu altero os horários dele para ficarem iguais ao da origem (conhece essa função do comando touch?):

touch /tmp/testersync/destino/arquivo -r /tmp/testersync/origem/arquivo

Como o rsync enxerga o arquivo agora?

find /tmp/testersync -type f -printf '%P:Tamanho %s, Mtime %t\n'
destino/arquivo:Tamanho 36, Mtime Sun Dec 17 14:43:11.4812008470 2023
origem/arquivo:Tamanho 36, Mtime Sun Dec 17 14:43:11.4812008470 2023

Do ponto de vista do rsync, eles agora são iguais. Duvida? Vamos executá-lo:

rsync -avi /tmp/testersync/origem/ /tmp/testersync/destino
sending incremental file list

sent 85 bytes  received 12 bytes  194.00 bytes/sec
total size is 36  speedup is 0.37

Pelo log, você pode ver que ele não transferiu nada, e o checksum segue diferente:

find /tmp/testersync -type f -exec sha256sum '{}' \+
f27d88d52759a4b07c077f34c230c47b94ea88b6640fc47b44d562243966eb7e  /tmp/testersync/destino/arquivo
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/origem/arquivo

Usando checksum para identificar arquivos diferentes

Neste tipo de situação - que geralmente é improvável de acontecer, mas não necessariamente impossível, você precisa da flag -c:

rsync -avic /tmp/testersync/origem/ /tmp/testersync/destino
sending incremental file list
>fc........ arquivo


find /tmp/testersync -type f -exec sha256sum '{}' \+
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/destino/arquivo
47c6ec4243572212a13d657637a62975a1007cf5881668cf7d02d370956dc3b3  /tmp/testersync/origem/arquivo

Agora sim, eu garanto que origem e destino são exatamente iguais.

Conclusão

Se você quiser garantir que a origem e o destino são iguais, você precisa modificar o comportamento padrão do rsync usando a flag -c ou --checksum.

Se você está trabalhando com arquivos que usam algum tipo de empacotamento binário de data (basicamente qualquer coisa), a chance desse tipo de situação passar batido é extremamente baixa.

Mas quando você trabalha com muitos arquivos textos com formatos e layouts parecidos e com filesystems extravagantes que podem não expor o mtime adequadamente, você pode cair nessa armadilha.

Em uma era em que a leitura dinâmica e o aprendizado resumido estilo TL;DR segue em voga, muitas vezes vale a pena você parar para entender com calma as ferramentas que você usa para evitar cair em armadilhas no futuro!

GCP OSLogin: entendendo como funciona!

Marcelo Andrade — Thu, 14 Dec 2023 05:29:04 +0000

Você usa / trabalha com Linux há anos diariamente, e usa SSH para tudo. Provavelmente vai ser difícil apresentar algo que você não conheça, certo?

Então vamos tirar isso à prova fazendo um estudo de caso do recurso OSLogin do Google Cloud. No final, me conte se aprendeu algo diferente ou não!

OS Login

De acordo com a documentação, OS Login é um recurso para melhor gerir o acesso via SSH às suas máquinas virtuais Linux no GCP. Ele faz mais que gerenciar chaves:

é um mecanismo completamente integrado ao GCP IAM, o que garante controle de acesso e permissões granulares usando políticas globais da conta e não do Linux;
implementa componentes que permitem ao Linux reconhecer identidades externas, que podem estar em um servidor LDAP ou no seu Active Directory.

Eu vejo muitas comparações com o AWS Systems Manager - Session Manager, mas é um recurso muito mais parecido com outro recurso da AWS chamado Instance Connect.

Como acessar VMs

Em uma instância com este recurso ativado (é possível ativá-lo na maioria das instâncias Linux no processo de criação), basta executar um único comando que você consegue o acesso:

$ gcloud compute ssh instancia-publica
...
Last login: Thu Dec 14 02:20:56 2023 from 35.235.244.32
cloud_user_p_0fffe37e_linuxacade@instancia-publica:~$

Se sua máquina não tiver um endereço IP público para acesso direto, o Gcloud é esperto o suficiente para saber que precisa de um passo a mais para viabilizar:

$ gcloud compute ssh instance-2
External IP address was not found; defaulting to using IAP tunneling.
...

Usuários com a role compute.osLogin ou compute.osAdminLogin naquela ainstância poderão acessar a máquina. Pode ser necessário mais permissões caso a máquina use uma ServiceAccount.

Como funciona o OS Login - cliente SSH

Ao tentar usar OS Login a primeira vez, você deverá receber a seguinte mensagem:

$ gcloud compute ssh instance-1
WARNING: The private SSH key file for gcloud does not exist.
WARNING: The public SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/marcelo/.ssh/google_compute_engine
Your public key has been saved in /home/marcelo/.ssh/google_compute_engine.pub
The key fingerprint is:
SHA256:W0xABfw0HgNyBgsPX6av+co9ZM/JWaa893fcIhM3zL8 marcelo@devsres.com
The key's randomart image is:
+---[RSA 3072]----+
|    o o+X+.      |
|     = O..=      |
|      =  +.+     |
|       . oo      |
|        S o  o   |
|       ooo  + =  |
|      oo.= * o +.|
|     . o. O + . *|
|      o.o..o +.Eo|
+----[SHA256]-----+
...

Ainda que você tenha chaves - mesmo com os nomes padrão id_rsa, id_ecdsa, id_ed25519 -, ele irá gerar uma nova para você:

$ ls -la ~/.ssh/google*
-rw------- 1 marcelo marcelo 2602 Dec 13 23:38 /home/marcelo/.ssh/google_compute_engine
-rw-r--r-- 1 marcelo marcelo  571 Dec 13 23:38 /home/marcelo/.ssh/google_compute_engine.pub
-rw-r--r-- 1 marcelo marcelo  218 Dec 13 23:44 /home/marcelo/.ssh/google_compute_known_hosts

(Observe que eles optam por não poluir o seu arquivo known_hosts com as máquinas do GCP, o comando gcloud adiciona os hosts conhecidos em um arquivo próprio, o .ssh/google_compute_known_hosts)

A chave gerada é uma RSA de 3072 bits:

# O comando executado deve ter sido:
# ssh-keygen -t rsa -b 3072 ~/.ssh/google_compute_engineq
$ ssh-keygen -l -f ~/.ssh/google_compute_engine.pub
3072 SHA256:W0xABfw0HgNyBgsPX6av+co9ZM/JWaa893fcIhM3zL8 marcelo@dominator (RSA)

Após gerar a chave, o gcloud "sobe" a chave pública para o GCP sem você ver:

$ gcloud compute os-login ssh-keys list
FINGERPRINT                                                       EXPIRY
eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138

É possível ver informações sobre a chave executando o comando:

$ gcloud compute os-login ssh-keys describe --key eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138
fingerprint: eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138
key: ssh-rsa ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCsPAqzEGyyz5ltlhJd1wxSyde2WOkDz4baJkDyB90dXstaVLkrw64LfYTIu0W2gpJOLkzOsUNjhTJl/3Feda+GvTIpNpom7EboCYbNd9ExTWnw2W1d6Y/Inn1vydOHoi1qt7X97QOfg7avDkYHoXhHMxumRetUWxte1FBKZ8se3KAPUH/GCBEB28EO6OOqs89c9MmjxWq9d1l0iMioGzGRkM2DvowhmVe5NwrYZMeSXBd7x0bGkDTpdaT5RFJf1nvBy8a68SQbTGO6d9KsqsGmTyUrUPhylkG+yzG+DW4p+KRsC8M6bXX0J3DCiHA9evLT6MyuTpOJDpxJAb+UAdXNwNn6T154HJZ1s1w4u5ruenAepaXBqI8EzGKBy0VUBObupQZuEMNj7XkKTlF3hgjwDvnMQr0AbDsz7da/uMhcVjoUCGZPRmeYRtCpUaEG453W9ZgNlQYALy18D4NEaJ85XiQQUQWDbBoEUcdl6R0JCIJK6pe4HxTyJT05I/QYNus=
  marcelo@devsres.com
name: users/cloud_user_p_0fffe37e@linuxacademygclabs.com/sshPublicKeys/eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138

É possível reusar suas chaves sem dificuldade:

$ gcloud compute os-login ssh-keys add --key-file ~/.ssh/id_rsa.pub --ttl 30
...
$ gcloud compute os-login ssh-keys list
FINGERPRINT                                                       EXPIRY
ca30c038ede7cc7ed7bee957d7778988b540f8204beabe2cdccf00ae78031a30  2023-12-14T03:19:19Z
eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138
...

Executar o "gcloud compute ssh" especificando uma chave privada sem subir a chave pública faz o auto upload da chave com TTL 0 (ou seja, não expira).

Como funciona o OS Login no servidor

No Linux: NSS

Agora sim, a parte interessante!

Primeiramente, vamos observar com que usuário você autentica no servidor remoto:

$ gcloud compute ssh instancia-publica --project=playground-s-11-b0bd65c9 --zone=us-central1-a
...
cloud_user_p_0fffe37e_linuxacade@instance-1:~$ whoami
cloud_user_p_0fffe37e_linuxacade

O usuário está associado ao meu usuário do Google Cloud - que é meio grande e não coube: cloud_user_p_0fffe37e@linuxacademygclabs.com.

Aqui a primeira diferença deste recurso para o SSM Session Manager e o Instance Connect: esse usuário não foi criado localmente na máquina:

[instancia-publica] $ grep cloud_user /etc/passwd | echo nao achei nada
nao achei nada

Isso acontece porque o OS Login integra com uma velha conhecida no mundo Linux, a libnss, por meio de um módulo específico (na verdade, dois):

[instancia-publica] $ head -n 13 /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files cache_oslogin oslogin
group:          files cache_oslogin oslogin
shadow:         files
gshadow:        files

hosts:          files dns
networks:       files

O arquivo nsswitch.conf é onde, tradicionalmente, mapeamos essa integração. A resolução de nomes, por exemplo, ocorre na ordem files -> dns (ou seja, /etc/host, depois linux client resolver). Para entradas no /etc/passwd ou /etc/group, a libnss orienta buscar, após destes arquivos, primeiramente no provider cache_oslogin, e posteriormente no próprio oslogin.

Essas libs são instaladas pelo pacote:

[instancia-publica] $ dpkg -L google-compute-engine-oslogin | fgrep libnss
/lib/x86_64-linux-gnu/libnss_cache_oslogin-20231004.00.so
/lib/x86_64-linux-gnu/libnss_oslogin-20231004.00.so
/lib/x86_64-linux-gnu/libnss_cache_oslogin.so.2
/lib/x86_64-linux-gnu/libnss_oslogin.so.2

Também há units do systemd ativas com estes programas:

[instancia-publica] $ systemctl list-units 'google*'
  UNIT                            LOAD   ACTIVE SUB     DESCRIPTION
  google-guest-agent.service      loaded active running Google Compute Engine Guest Agent
  google-osconfig-agent.service   loaded active running Google OSConfig Agent
  google-shutdown-scripts.service loaded active exited  Google Compute Engine Shutdown Scripts
  google-oslogin-cache.timer      loaded active waiting NSS cache refresh timer

Dependendo do provider, é possível ver as entradas usando o comando abaixo:

[instancia-publica] $ getent passwd | tail -n5
systemd-timesync:x:999:999:systemd Time Synchronization:/:/usr/sbin/nologin
systemd-coredump:x:998:998:systemd Core Dumper:/:/usr/sbin/nologin
cloud_user_p_0fffe37e_linuxacade:*:1862762045:1862762045::/home/cloud_user_p_0fffe37e_linuxacade:/bin/bash
sa_112203697991872690750:*:3661484281:3661484281::/home/sa_112203697991872690750:/bin/bash
sa_109344113766727672345:*:3686152525:3686152525::/home/sa_109344113766727672345:/bin/bash

Nem sempre o comando getent traz todas as entradas. Isso não quer dizer que o sistema operacional não seja capaz de enxergá-lo, apenas indica que a biblioteca usada não necessariamente suporta enumeração.

Se seu usuário não fosse visível para o SO, você não conseguiria nem logar!

Se ele não surgir na saída do comando acima, é possível fazer uma query direta sobre ele especificando o nome:

[instancia-publica] $ id
uid=1862762045(cloud_user_p_0fffe37e_linuxacade) gid=1862762045(cloud_user_p_0fffe37e_linuxacade) groups=1862762045(cloud_user_p_0fffe37e_linuxacade),44(video)

[instancia-publica] $ getent passwd cloud_user_p_0fffe37e_linuxacade
cloud_user_p_0fffe37e_linuxacade:*:1862762045:1862762045::/home/cloud_user_p_0fffe37e_linuxacade:/bin/bash

Nem todo mundo conhece estas funcionalidades do mundo Linux! Elas vêm desde lá atrás com o NIS/Yellow Pages, e geralmente só quem administra servidores integrados com LDAP ou Active Directory conhece esses recursos!

Agora, uma outra consideração: as conexões realmente ocorrem via ssh a partir do endereço da sua máquina!

[instancia-publica] $ ss -nt '( sport = :22 )'
State              Recv-Q              Send-Q                           Local Address:Port                            Peer Address:Port              Process
ESTAB              0                   140                                 10.128.0.2:22                             XXX.42.69.YYY:59660

No caso, o IP XXX.42.69.YYY representa o meu endereço IP.

Se você executar o comando a partir de um tunel IAP, o endereço vai ser outro:

[instancia-publica] $ ss -nt '( sport = :22 )'
State              Recv-Q              Send-Q                           Local Address:Port                           Peer Address:Port               Process
ESTAB              0                   0                                   10.128.0.2:22                             35.235.240.4:46519

Ou seja, é necessário garantir que haja conectividade a partir dos recursos de Identity Aware Proxy (IAP) do Google Cloud para que isso funcione (i.e., abrir regras para o range 35.235.240.0/20, como descrito na documentação).

Como os acessos ocorrem realmente via SSH (diferentemente do AWS SSM Session Manager), é necessário configurar um outro componente para viabilizar o login no Linux: o PAM!

No Linux: PAM

O diretório /etc/pam.d conta com a configuração de como vários programas do Linux realizam seu processo de autenticação e estabelecimento de sessões!

[instancia-publica] $ ls /etc/pam.d
chfn      chsh            common-auth      common-session                 cron   newusers  passwd   runuser-l  su    sudo
chpasswd  common-account  common-password  common-session-noninteractive  login  other     runuser  sshd       su-l

O PAM oculta diversas camadas de complexidade por trás de sua aparente simplicidade, e é imprescindível que um administrador Linux entenda do que se trata e saiba ler o que dizem as configurações.

Esta é a configuração PAM do comando sudo:

[instancia-publica] $ egrep -v '^$|^#'  /etc/pam.d/sudo
@include common-auth
@include common-account
@include common-session-noninteractive

Esta, a do su:

[instancia-publica] $ egrep -v '^$|^#'  /etc/pam.d/su
auth          sufficient pam_rootok.so
session       required   pam_env.so readenv=1
session       required   pam_env.so readenv=1 envfile=/etc/default/locale
session       optional   pam_mail.so nopen
session       required   pam_limits.so
@include common-auth
@include common-account
@include common-session

E esta a do ssh (se a diretiva UsePAM estiver configurada!):

[instancia-publica] $ sudo fgrep -i 'UsePAM'  /etc/ssh/sshd_config
UsePAM yes

[instancia-publica] $ egrep -v '^$|^#'  /etc/pam.d/sshd
auth       [default=ignore] pam_group.so
@include common-auth
account    required     pam_nologin.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_keyinit.so force revoke
@include common-session
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate
session    optional     pam_mail.so standard noenv # [1]
session    required     pam_limits.so
session    required     pam_env.so # [1]
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open
@include common-password
session    [success=ok default=ignore] pam_mkhomedir.so

Achou complicado? Note que em todos há includes de outros arquivos, o que 'empilha' as diretivas com as descritas nesses arquivos! Isso existe para evitar que você precise reconfigurar cada programa separadamente com as mesmas diretivas!

O Google OS Login pode modificar o PAM e usar dois módulos, o pam_oslogin_login.so para determinar se o usuário pode autenticar, e o pam_oslogin_admin.so que determina se o usuário vai poder usar o comando sudo.

Em vez de criar as entradas em /etc/sudoers.d, o OS Login deixa um arquivo com um include para outro diretório:

[instancia-publica] $ cat /etc/sudoers.d/google-oslogin
#includedir /var/google-sudoers.d

[instancia-publica] $ cat /var/google-sudoers.d/*
cloud_user_p_0fffe37e_linuxacade ALL=(ALL) NOPASSWD: ALL

No SSH

A parte mais interessante, entretanto, vem nas modificações do SSH. O programa faz as seguintes modificações no arquivo /etc/sshd:

[instancia-publica] $ head -n7 /etc/ssh/sshd_config
#### Google OS Login control. Do not edit this section. ####
TrustedUserCAKeys /etc/ssh/oslogin_trustedca.pub
AuthorizedPrincipalsCommand /usr/bin/google_authorized_principals %u %k
AuthorizedPrincipalsCommandUser root
AuthorizedKeysCommand /usr/bin/google_authorized_keys
AuthorizedKeysCommandUser root
#### End Google OS Login control section. ####

As três primeiras diretivas estão relacionadas ao uso de certificados SSH, o que, a princípio, não é a funcionalidade usada para as conexões do usuário - mas que vale a leitura a respeito se você nunca ouviu falar!

A diretiva mais importante para o uso desta funcionalidade é AuthorizedKeysCommand: ela permite que o SSH invoque um comando adicional para recuperar quais chaves estão associadas ao usuário tentando logar.

As chaves estão salvas no GCP (como mostramos na sessão do cliente!); logo, basta que a instância seja capaz de acessar a API do GCP e listar as chaves públicas cadastradas para o usuário!

[instancia-publica] $ /usr/bin/google_authorized_keys cloud_user_p_0fffe37e_linuxacade
ssh-rsa ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCsPAqzEGyyz5ltlhJd1wxSyde2WOkDz4baJkDyB90dXstaVLkrw64LfYTIu0W2gpJOLkzOsUNjhTJl/3Feda+GvTIpNpom7EboCYbNd9ExTWnw2W1d6Y/Inn1vydOHoi1qt7X97QOfg7avDkYHoXhHMxumRetUWxte1FBKZ8se3KAPUH/GCBEB28EO6OOqs89c9MmjxWq9d1l0iMioGzGRkM2DvowhmVe5NwrYZMeSXBd7x0bGkDTpdaT5RFJf1nvBy8a68SQbTGO6d9KsqsGmTyUrUPhylkG+yzG+DW4p+KRsC8M6bXX0J3DCiHA9evLT6MyuTpOJDpxJAb+UAdXNwNn6T154HJZ1s1w4u5ruenAepaXBqI8EzGKBy0VUBObupQZuEMNj7XkKTlF3hgjwDvnMQr0AbDsz7da/uMhcVjoUCGZPRmeYRtCpUaEG453W9ZgNlQYALy18D4NEaJ85XiQQUQWDbBoEUcdl6R0JCIJK6pe4HxTyJT05I/QYNus= marcelo@devsres.com

Caso mais uma chave seja adicionada do lado do cliente:

$ gcloud compute os-login ssh-keys add --key-file ~/.ssh/id_ecdsa.pub --ttl 30
...

$ gcloud compute os-login ssh-keys list
FINGERPRINT                                                       EXPIRY
68dc496cf5293b7fa094a05b0f0acc92d2382e7bb983a70bacae1ea06cbfaeed  2023-12-14T05:27:22Z
eee442d8830969ce8109c1c62a8d1aed1c188c11e87c7beebdb8610269724138

A saída do outro comando irá mostrar todas as chaves disponíveis!

[instancia-publica] $ /usr/bin/google_authorized_keys cloud_user_p_0fffe37e_linuxacade
fiXhlbf7uTxcmcYKSrFRakfPRyVtpUVaBLoTJHh70OvITNBXyCiUxwBGM6kKwqSWGX6uD3Bk8nal6cG4eZFHGFy8mfCK3Cx7wNShvXfXEVOqALXJI5W8NPl3eIOMQhx+S1mrK+45K4qTqfaUuq9W8MdrzUEfB4y/DbsgcY4p6GAqTBURuMU0Ym3d+H7DAo4rJCTpy1d/qTvCTkN14Y3slIshmzORmuo2caPpPMsX7iJtpLZkmMJ872gTKU3P5sx7efEv1D89i1WMHFpWAqhIRsKNsJCB53r0Dtt6dK2iKeonWgZYMYfKd+3Px8eDgYyOetNVFhaGXv9w/bDDj60pchENCEDTB59CdAU71tiI/U7738DITq1ZZVzCSWpu0= cloud_user_p_0fffe37e@cs-380498931324-default
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCsPAqzEGyyz5ltlhJd1wxSyde2WOkDz4baJkDyB90dXstaVLkrw64LfYTIu0W2gpJOLkzOsUNjhTJl/3Feda+GvTIpNpom7EboCYbNd9ExTWnw2W1d6Y/Inn1vydOHoi1qt7X97QOfg7avDkYHoXhHMxumRetUWxte1FBKZ8se3KAPUH/GCBEB28EO6OOqs89c9MmjxWq9d1l0iMioGzGRkM2DvowhmVe5NwrYZMeSXBd7x0bGkDTpdaT5RFJf1nvBy8a68SQbTGO6d9KsqsGmTyUrUPhylkG+yzG+DW4p+KRsC8M6bXX0J3DCiHA9evLT6MyuTpOJDpxJAb+UAdXNwNn6T154HJZ1s1w4u5ruenAepaXBqI8EzGKBy0VUBObupQZuEMNj7XkKTlF3hgjwDvnMQr0AbDsz7da/uMhcVjoUCGZPRmeYRtCpUaEG453W9ZgNlQYALy18D4NEaJ85XiQQUQWDbBoEUcdl6R0JCIJK6pe4HxTyJT05I/QYNus= marcelo@devsres.com

É ou não é um recurso interessante?

Isso porque eu ainda não mostrei a funcionalidade de usar SSH com MFA também disponível!

EKS and NetworkPolicies: the story so far

Marcelo Andrade — Tue, 12 Sep 2023 00:08:43 +0000

On my monthly "let´s keep up with AWS news" live stream, one of the news caught my eye as game changer, and it was this one:

Amazon VPC CNI now supports Kubernetes NetworkPolicy enforcement~

Let's have a peek on what this is about and why it is a game changer.

Kubernetes NetworkPolicies

NetworkPolicies are often overlooked, but it is basically the major security feature of Kubernetes that grants you the hability to control the conectivity between your applications (and also the rest of the world!).

Many people get the feeling that the concept of namespaces provides isolation for applications running under, but it does not provide network isolation by default.

You can create a namespace app1 and grant access for your Team A to deploy their applications. But if you allow Team B to run jobs on a namespace app2, even if they will not be able to modify app1 deployments, their jobs will be able to connect to the app1 deployments:

# Checking IPs for the applications:
$ kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.status.podIP}{"\n"}{end}' |
fgrep app
app1/backend-84bf889f7f-nrxbr: 192.168.130.72
app1/frontend-54d8796d8c-2fzsk: 192.168.140.197
app2/job-f8dd4484b-kmxkm: 192.168.138.201

$ for i in 192.168.130.72 192.168.140.197; do \
    kubectl -n app2 exec job-f8dd4484b-kmxkm -- curl $i -so /dev/null -w '%{HTTP_CODE}' \
  done
200
200

This may not sound like a problem to you, but it is certainly not the most desirable situation, specially if most of your security is invested into the LoadBalancers/Web Application Firewalls that are outside the security perimeter of your cluster - it turns your cluster into a lateral movement extravaganza if someone not intended manages to get access to it.

Securing the application

In order to block traffic from other namespaces to your application, you have to apply a NetworkPolicy that denies all incoming traffic:

$ echo '---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: app1
spec:
  podSelector: {}
  policyTypes:
  - Ingress
' | kubectl apply -f -

Syntax might look weird at a glance, but it applies to all pods (podSelector: {}) allowing nothing because there is no ingress block defined at the top level of spec.

After these rules get applied, no one will be able to access pods on namespace app1:

$ for i in 192.168.130.72 192.168.140.197; do
    kubectl -n app2 exec job-f8dd4484b-kmxkm -- curl --connect-timeout 2 $i -so /dev/null -w '%{HTTP_CODE}\n'
  done
000
command terminated with exit code 28
000
command terminated with exit code 28

Problem is not even applications on app1 will be able to access each other. Once you apply any networkpolicy of a type (ingress or egress), all traffic that is not specificly allowed will be denied.

So if you have a frontend/backend combo like below:

$ kubectl -n app1 get pods -o name
pod/backend-84bf889f7f-nrxbr
pod/frontend-54d8796d8c-2fzsk

You should allow incoming conections to backend only from the frontend deployment, and frontend might get its connections from a Load Balancer outside the cluster.

To allow frontend to access backend, one would leverage the kubernetes labels to make the rule dynamic:

$ kubectl -n app1 get pods --show-labels | tr -s ' ' | cut -f1,6 -d' '
NAME LABELS
backend-84bf889f7f-nrxbr app=backend,pod-template-hash=84bf889f7f
frontend-54d8796d8c-2fzsk app=frontend,pod-template-hash=54d8796d8c

Backend pods will always have the label app=backend, and Frontend pods will have the label app=frontend; this will tell the NetworkPolicy Controller to update the rules every time a new pod is created (or destroyed).

# Conecting to the **service** backend from the pod frontend
$ kubectl -n app1 exec deploy/frontend -- curl --connect-timeout 2 -so /dev/null http://backend  -w '%{http_code}'
000
command terminated with exit code 28

$ echo '---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: app1 
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 80
' | kubectl apply -f -

# Retesting:
$  kubectl -n app1 exec deploy/frontend -- curl --connect-timeout 2 -so /dev/null http://backend  -w '%{http_code}'
200

Unfortunately, there is no easy way to restrict access to the frontend pods from the load balancers, because they're not hosted inside the cluster.

(You can use Security Groups for Pods for that!)

The best you can do is to limit connections from the subnets where the load balancers will create their ENIs (or use their ips, if you feel bold!):

$ echo '---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: lb-to-frontend
  namespace: app1
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 192.168.0.0/19
        - ipBlock:
            cidr: 192.168.32.0/19
        - ipBlock:
            cidr: 192.168.64.0/19
      ports:
        - protocol: TCP
          port: 80
' | kubectl apply -f -

Of course, anything else that is created on those subnets will be able to access the frontend pods on namespace app1.

The backend pod, otherwise, won't be able to start any connection to the frontend:

$ k -n app1 exec -it deploy/backend -- curl frontend:80 -so /dev/null -w '%{http_code}' --connect-timeout 2
000

Kubernetes NetworkPolicies allow an incredible degree of microsegmentation with little to no effort, even allowing for the devs themselves to be responsible to translate their integrations in a declarative way.

But of course, there is always a catch.

NetworkPolicy Controller

Unfortunately, Netpols are one of the few native Kubernetes Resources that do not have a default controller assigned to it - the other major one would be Ingresses.

Even though it's clearly stated in the docs, as quoted bellow:

Network policies are implemented by the network plugin. To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect.
source

It's still easy for people to miss it, specially if they are less kubernetes-savy than they should be when using this type of technology.

And yes, I've been asked "why my netpols are not working" before. People just assume that it should work.

So, if you install an EKS cluster right now and reproduce the same configurations I have listed here, nothing will work.

At least for a while, because things changed!

EKS and NetworkPolicies

Until August 2023, the only way use NetworkPolicies was to deploy a third party software called Project Calico. It's a full fledged CNI, but one would enable only the Policy part as described in the official EKS docs.

But now, things changed! If you install a new EKS Cluster with the CNI version 1.14.0 or above, it now supports NetworkPolicies natively!!

All you have to do is to create your EKS Cluster with the following on your eksctl yaml:

...
addons:
- name: vpc-cni 
  version: 1.14.0
  configurationValues: |-
    enableNetworkPolicy: "true"    
  attachPolicyARNs:
  - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
...

And that's it! Awesome news for EKS users!

Final notes

I believe it's worth noting that AWS CNI native NetworkPolicies make use of eBPF and not iptables as many of the other solutions available.

It does not support port translation from Services:

For any of your Kubernetes services, the service port must be the same as the container port. If you're using named ports, use the same name in the service spec too.

For a brief period during creation, the pod will not have any restrictions applied to it:

The Amazon VPC CNI plugin for Kubernetes configures network policies for pods in parallel with the pod provisioning. Until all of the policies are configured for the new pod, containers in the new pod will start with a default allow policy. All ingress and egress traffic is allowed to and from the new pods unless they are resolved against the existing policies.

It's also not supported on Fargate or Windows nodes.

Terraform refactoring

Marcelo Andrade — Sat, 08 Oct 2022 03:55:51 +0000

Estava trabalhando com Terraform gerando dados para testes da nova versão do Netbox.

Em vez de destruir todos os dados para reexecutar o código Terraform final , aproveitei para fazer uma demonstração de Terraform Refactoring com as diretivas moved.

Contexto

Originalmente, dois recursos netbox_region eram criados:

# Região de São Paulo
resource "netbox_region" "sp" {
  name = "São Paulo"
  description = "Estado de São Paulo"
  slug = "sp"
}

# Região de Brasília
resource "netbox_region" "df" {
  name = "Distrito Federal"
  description = "Distrito Federal"
  slug = "df"
}

O resultado da aplicação do código acima pode ser inspecionado no arquivo de estados do Terraform:

$ terraform state list | fgrep netbox_region
netbox_region.df
netbox_region.sp

Refactor para variáveis e objetos

Não é algo que agrada a todo mundo, mas você pode parametrizar as configurações usando objetos complexos.

Regra geral, eu não recomendo complexidade excessiva na definição de variáveis porque deixa tudo confuso e difícil para ler ou adaptar posteriormente. Mas vamos lá:

Podemos deixar o arquivo variables.tf:

variable "regions" {
    type = map(
        object({
            name = string
            description = string
            slug = string
    }))
    description = "Estados do Brasil"

    default = {
        sp = {
          name = "São Paulo"
          description = "Estado de São Paulo"
          slug = "sp"
        },
        df = {
            name = "Distrito Federal"
            description = "Distrito Federal"
            slug = "df"
        }    
    }
}

Tudo isso me permite substituir os dois recursos netbox_region por um único bloco usando for_each.

(Vou ser honesto, não me parece uma troca muito inteligente!)

resource "netbox_region" "estado" {
  for_each = var.regions
  name = each.value.name
  description = each.value.description
  slug = each.value.slug
}

Obviamente, se você fizer apenas isso, vai literalmente destruir ambos os recursos originais para criar dois novos. Dependendo do tipo de API com que o Terraform irá lidar, pode ser que nem seja possível fazer as alterações.

Neste código, o que acontece é isso aqui:

$ terraform plan | egrep 'Plan|# netbox'
  # netbox_region.df will be destroyed
  # netbox_region.estado["df"] will be created
  # netbox_region.estado["sp"] will be created
  # netbox_region.sp will be destroyed
  # netbox_site.df will be updated in-place
  # netbox_site.df_spc_1 will be updated in-place
  # netbox_site.sp will be updated in-place
  # netbox_site.sp_spc_1 will be updated in-place
Plan: 2 to add, 4 to change, 2 to destroy.

Mas eu não estou modificando nada, não estou recriando nada, eu quero apenas substituir uma maneira de criar os recursos por outra.

Tradicionalmente, seria necessário fazer mudanças com o comando terraform state mv

$ terraform state mv netbox_region.sp 'netbox_region.estado["sp"]'
Move "netbox_region.sp" to "netbox_region.estado[\"sp\"]" 
Successfully moved 1 object(s).
$ terraform state mv netbox_region.df 'netbox_region.estado["df"]'
Move "netbox_region.df" to "netbox_region.estado[\"df\"]" 
Successfully moved 1 object(s).

$ terraform plan 
...
No changes. Your infrastructure matches the configuration.

Desde a versão 1.1, entretanto, temos uma outra maneira mais legal que executar dezenas de comandos: os blocos moved.

Os blocos abaixo substituem os comandos terraform state mv:

moved {
  from = netbox_region.df
  to = netbox_region.estado["df"]
}

moved {
  from = netbox_region.sp
  to = netbox_region.estado["sp"]
}

Com este bloco, o Terraform modifica o state e não faz operações na API remota:

$ terraform plan -out plan
...
Terraform will perform the following actions:

  # netbox_region.df has moved to netbox_region.estado["df"]
    resource "netbox_region" "estado" {
        id               = "1"
        name             = "Distrito Federal"
        # (3 unchanged attributes hidden)
    }

  # netbox_region.sp has moved to netbox_region.estado["sp"]
    resource "netbox_region" "estado" {
        id               = "2"
        name             = "Estao de São Paulo"
        # (3 unchanged attributes hidden)
    }

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

$ terraform apply plan

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

$ terraform state list | fgrep netbox_region
netbox_region.estado["df"]
netbox_region.estado["sp"]

Você pode se perguntar: mas para que eu substituiria dois comandos simples por um monte de blocos poluindo meu código Terraform?

Bem, primeiramente, trabalhar com blocos de configurações declarativas não é apenas temático, mas certamente uma alternativa muito melhor que um conjunto isolados de comandos imperativos.

Vários comandos imperativos quebram a "atomicidade" das operações, além de ser bem incômodo para execução de rollbacks.

(Nem sempre será possível contemplar 100% dos casos com blocos move, mas é sempre melhor ter uma alternativa declarativa a não ter nenhuma!)

Além disso, se você codifica um módulo que é usado por dezenas de instâncias de códigos diferentes, você precisa executar os comandos de terraform state mv em cada uma das instâncias.

Na maioria dos ambientes, além deste tipo de prática não ser bem vista, normalmente é particularmente difícil de conseguir os acessos a todos os arquivos.

Ao operar "dentro" de um módulo, agora você consegue abstrair boa parte das dores de cabeça que os usuários dos seus módulos podem ter.

Se você usa Terraform e pretende continuar usando no futuro, é bem provável que precise destes recursos nos seus códigos!

A página que fez o anúncio dos blocos moved é esta aqui e conta com vários outros exemplos em que as técnicas podem ajudar.

Também há um tutorial que pode ser seguido aqui para ajudar a praticar esta técnica.

Observabilidade com Prometheus

Marcelo Andrade — Sat, 01 Oct 2022 06:53:24 +0000

Documentando minha apresentação criada originalmente para o DevOps Experience conduzido pelo DevOps Heroes, aqui vai um resumo sobre métricas no Prometheus!

Prometheus

Prometheus como solução de monitoramento é uma "cria" interessante: ele não se limita a um conjunto de ferramentas "server-side" - aliás, o principal foco é justamente a existência de diversas bibliotecas disponíveis.

Inclusive ele mesmo "se vende" como solução para implementar whitebox monitoring:

Tipos de métricas

Como descrito neste post, Prometheus disponibiliza quatro tipos de métricas para uso na instrumentação da sua aplicação:

Gauges
Counters
Histograms
Summaries

Vamos entender como cada uma funciona do ponto de vista de objetivos de monitoração.

Gauges

Métricas do tipo Gauge é um número que representa um "snapshot" do que está sendo observado. Memória livre, espaço em disco consumido, uso de CPU, temperatura do datacenter, algo que pode aumentar ou diminuir.

A maior parte da monitoração tradicional se encaixa com este tipo de métrica. Elas nos permitem formar simpáticos dashboards para acompanhar ao longo do tempo e gerar alertas caso determinada situação persista por muito tempo:

# Consumo de memória (em %)
node_memory_MemAvailable_bytes / 
node_memory_MemTotal_bytes

# Espaço em disco ocupado (em %^)
(1 - node_filesystem_avail_bytes{mountpoint="/mnt/c"}) / 
     node_filesystem_size_bytes{mountpoint="/mnt/c"}

Ambas as métricas acima foram extraídas usando o Prometheus Node Exporter.

Há uma pequena diferença entre as métricas acima.

Como há apenas uma única máquina sendo monitorada, não precisei especificar nenhum filtro de labels na consulta.

Já no espaço em disco, as métricas são exibidas para cada sistema de arquivos:

No caso, no Dashboard, optei por limitar a métrica ao sistema de arquivos "/mnt/c":

1 - node_filesystem_avail_bytes{mountpoint="/mnt/c"} /
    node_filesystem_size_bytes{mountpoint="/mnt/c"}

A terceira métrica é mais interessante: CPU. Ampliando o gráfico:

A máquina conta com 8 CPUs - ou o mais provável, 8 cores.

A métrica para recuperar essa informação é muito mais complexa que as anteriores, e você vai perceber que eu menti ao colocá-la ao lado das duas outras - porque esta não é um Gauge - e o próprio Grafana me dedura:

Entretanto, ninguém percebeu na apresentação!

Usei de conhecimento arcano em Prometheus para exibir valores que "sobem" e "descem". Aqui estão os recursos necessários para viabilizar o Dashboard como ele apareceu na imagem anterior:

# Consumo por CPU
1 - (avg by (cpu) (rate(node_cpu_seconds_total{mode="idle"}[1m])))

# Consumo de CPU agregado 
1 - (avg (rate(node_cpu_seconds_total{mode="idle"}[1m])))

Você pode me perguntar: mas por que tão complicado? Não seria bem mais simples coletar um "snapshot" do consumo de cada core em um dado momento e expor esse valor? Por exemplo, no instante da coleta, 4 CPUs estão a 100%, e 4 em 15%.

Mas pense um pouco. Se você acompanha o consumo de um host por uma amostragem em um dado em um dado momento, quão confiável é aquele valor? Especialmente se o intervalo da amostragem for em períodos longos, como 5 minutos?

Existe uma razão para o Prometheus fazer uma tarefa aparentemente simples ("eu só quero uma amostra do consumo de CPU") de maneira tão surrealmente complicada.

A resposta é uma tríplice combinação de busca por capacidade de inferência combinada com a flexibilidade e expressividade matemática e a simplicidade de para implementar contadores simples ao instrumentar aplicações.

Já vimos a flexibilidade matemática no exemplo da consulta em PromQL acima. A próxima imagem mostra como a métrica na verdade foi implementada:

Na verdade, há 8 métricas geradas para cada core, descrevendo (por meio de um número) o "tempo de cpu" gasto em cada um dos 8 estados (idle, iowait, irq, nice, softirq, steal, system e user).

Uma ferramenta poderia optar por fazer uma extração de um momento em particular. Ao fazer do "jeito complicado", o Prometheus delega a decisão de como tratar a métrica do lado do servidor, oferecendo flexibilidade para você isolar e analisar os valores como quiser.

Se você não entendeu a consulta acima, não se preocupe, vem mais por aí!

curl, downloads, ouputs e muitos "o"s

Marcelo Andrade — Mon, 22 Aug 2022 15:26:22 +0000

Todo mundo usa curl para baixar arquivos, certo?

Já aconteceu isso aqui com você?

Essa é a primeira diferença imediata entre o curl e o wget, e pode ser irritante se você está muito acostumado com o outro.

Vamos "resolver o problema" progredindo os níveis da demanda.

Nível 0: preguiçoso

A primeira maneira para baixar arquivos é simplesmente não usar curl!

$ wget https://releases.hashicorp.com/terraform/1.2.7/terraform_1.2.7_linux_amd64.zip

$ ls
terraform_1.2.7_linux_amd64.zip

Mas aí não aprendemos nada de novo! Próximo!

Nível 1: Júnior

A solução mais comum para este problema é usar -o especificando o nome do arquivo:

$ curl -so terraform.zip \
https://releases.hashicorp.com/terraform/1.2.7/terraform_1.2.7_linux_amd64.zip

Esse parâmetro é útil quando você acessa aquelas URLs todas truncadas que por acaso geram um binário para baixar, como imagem ou arquivo compactado.

Mas no exemplo acima, do Terraform, eu não precisaria especificar o nome, basta "espelhar" o "nome remoto do arquivo":

releases.hashicorp.com/terraform/1.2.7/terraform_1.2.7_linux_amd64.zip

E, claro, existe uma opção mais conveniente para isso.

Nível 2: pleno

A opção -O extrai o "remote file name" da URL (i.e., sem o caminho completo). É exatamente o que procuramos para este caso.

$ TD=https://releases.hashicorp.com/terraform/1.2.7
$ curl -sO $TD/terraform_1.2.7_linux_amd64.zip

Muito bom, mas não precisamos parar por aqui, certo?

Ao fazer download de qualquer coisa - em especial, binários que vamos executar nos nossos preciosos sistemas operacionais -, idealmente deveríamos fazer várias verificações no download para garantir que ele é, de fato, o que queremos.

A recomendação oficial aqui seria:

Baixar o .zip com o Terraform;
Baixar o arquivo de SHA256;
Baixar o arquivo para verificar a assinatura do arquivo de checksum;
Baixar a chave gpg da Hashicorp;

Putz, que trabalheira! Mas ossos do ofício.

O acesso à chave da Hashicorp você pode viabilizar com o próprio GPG:

$ gpg --keyserver keyserver.ubuntu.com --recv-keys 72D7468F
gpg: key 34365D9472D7468F: public key "HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --fingerprint 72D7468F
pub   rsa4096 2021-04-19 [SC] [expires: 2026-04-18]
      C874 011F 0AB4 0511 0D02  1055 3436 5D94 72D7 468F
uid           [ unknown] HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>

Informações batem, aparentemente estamos ok aqui.

Agora é só baixar os demais arquivos:

$ curl -sO   $TD/terraform_1.2.7_linux_amd64.zip \
             $TD/terraform_1.2.7_SHA256SUMS      \
             $TD/terraform_1.2.7_SHA256SUMS.sig

Ué, o que deu errado?

Bem simples... Você não leu a documentação.

If not told otherwise, curl writes the received data to stdout. It can be instructed to instead save that data into a local file, using the --output or --remote-name options. If curl is given multiple URLs to transfer on the command line, it similarly needs multiple options for where to save them.

Múltiplas URLs são histórias diferentes, e você precisa especificar um parâmetro para cada uma delas. No exemplo em questão, precisamos de três -Os!

$ curl -sOOO $TD/terraform_1.2.7_linux_amd64.zip \
             $TD/terraform_1.2.7_SHA256SUMS      \
             $TD/terraform_1.2.7_SHA256SUMS.sig

Meio tosco né. Mas é o jeito e temos que conviver.

Ou não?

Nível 3: Sênior

Se você é daqueles que não se satisfaz com a primeira solução que encontra e não liga de perder algum tempo procurando por algo que talvez não exista, este não é o caso: o curl tem algo para você!

Você pode habilitar o --remote-name-all para resolver este assunto de maneira definitiva:

$ curl -s --remote-name-all            \
   $TD/terraform_1.2.7_linux_amd64.zip \
   $TD/terraform_1.2.7_SHA256SUMS      \
   $TD/terraform_1.2.7_SHA256SUMS.sig

O Daniel Stenberg conta a história desta opção neste blog post bem interessante sobre o histórico de opções de saída do curl. E embora a opção esteja disponível desde 2008, segundo ele mesmo, no post de 2020, ela persiste como uma das opções mais obscuras e menos usadas do curl:

Nível 4: Especialista

Apenas a título de completude, já que estamos falando sobre essas opções, vou deixar uma opção que não se encaixa no exemplo acima por utilidade.

Neste mesmo post, temos um parágrafo:

Esse parâmetro é útil quando você acessa aquelas URLs todas truncadas que por acaso geram um binário para baixar, como imagem ou arquivo compactado.

Normalmente sites que fazem isso usam cabeçalhos especiais para indicar o nome do arquivo.

Se você for na Wikipédia e tentar baixar um artigo, como, por exemplo, a seção sobre Terraforming, você será apresentado a um botão.

Esse botão é a seguinte URL:

https://en.wikipedia.org/api/rest_v1/page/pdf/Terraforming

Se você fizer uma "análise exploratória" na URL, você vai observar alguns cabeçalhos interessantes:

$ curl -sI https://en.wikipedia.org/api/rest_v1/page/pdf/Terraforming | fgrep -i content-disposition
content-disposition: attachment; filename="Terraforming.pdf"; filename*=UTF-8''Terraforming.pdf

O nome do arquivo é indicado pelo cabeçalho de content-disposition.

Se você usar o curl com o parâmetro -J combinado com o -O, você consegue baixá-lo com o "nome certo":

$ curl -sOJ https://en.wikipedia.org/api/rest_v1/page/pdf/Terraforming

Bônus: verificação de download

Neste post, usei o download do Terraform como motivação para avaliar os parâmetros do curl. Falei sobre download seguro e até baixei a chave GPG da Hashicorp, mas não conclui... Vou colocar de bônus aqui no fim!

Baixamos os arquivos:

$ curl -s --remote-name-all \
   $TD/terraform_1.2.7_linux_amd64.zip \
   $TD/terraform_1.2.7_SHA256SUMS      \
   $TD/terraform_1.2.7_SHA256SUMS.sig

Podemos baixar a chave de vários jeitos, e este é um deles:

$ gpg --keyserver keyserver.ubuntu.com --recv-keys 72D7468F
gpg: key 34365D9472D7468F: public key "HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --fingerprint 72D7468F
pub   rsa4096 2021-04-19 [SC] [expires: 2026-04-18]
      C874 011F 0AB4 0511 0D02  1055 3436 5D94 72D7 468F
uid           [ unknown] HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>

Confirmo a identidade com o código do site

$ gpg --lsign-key 'C874 011F 0AB4 0511 0D02  1055 3436 5D94 72D7 468F'

Confirmo as assinaturas do arquivo .sig do Terraform com:

$ gpg --verify terraform_1.2.7_SHA256SUMS.sig
gpg: assuming signed data in 'terraform_1.2.7_SHA256SUMS'
gpg: Signature made Wed 10 Aug 2022 02:51:41 PM -03
gpg:                using RSA key 374EC75B485913604A831CC7C820C6D5CD27AB87
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-04-06
gpg: Good signature from "HashiCorp Security (hashicorp.com/security) <security@hashicorp.com>" [full]

Arquivo de checksums está ok! E agora o download:

$ sha256sum --ignore-missing -c terraform_1.2.7_SHA256SUMS
terraform_1.2.7_linux_amd64.zip: OK

Pronto, pode usar o Terraform em paz!

DEV Community: Marcelo Andrade

Entendendo Kubernetes Ingress Controllers e as vulnerabilidades recentemente anunciadas do Nginx

O que é Ingress?

O que é um Ingress Controller?

O que é o Ingress Nginx Controller?

Ingress NGINX Controller ou NGINX Ingress Controller?

Quais os problemas do Ingress NGINX Controller?

"Validating Webhook Configuration"

Problemas do Webhook

Vulnerabilidade CVE 2025-1974 e demais

Como remediar?

From which Kubernetes pod (and namespace!) is this process that I see on my host?

Terraform, OpenTofu e criptografia de estado

Acessando arquivos de Terraform State

Opentofu terraform state encryption

Extra: Mitigação na AWS com KMS

Como a AWS Cloud Control API e o novo Terraform provider impactam sua vida?

Terraform Provider AWS

AWS API e suas inconsistências

AWS Cloud Control

Genial! Quando migramos?

Para quem é o Cloud Control então?

Conclusão

EBS, seus snapshots e quanto ocupam de espaço

"Temos 800 TiB de snapshots!"

EBS Direct API

Nota de rodapé pensando em segurança

Usando cURL para diagnóstico de problemas

curl custom output

Variáveis de writeout para exibir tempos

time_namelookup

Como o RSYNC funciona?

RSYNC é assunto para PHD!

Que arquivos precisam ser enviados para o destino?

Enganando o rsync:

Usando checksum para identificar arquivos diferentes

Conclusão

GCP OSLogin: entendendo como funciona!

OS Login

Como acessar VMs

Como funciona o OS Login - cliente SSH

Como funciona o OS Login no servidor

No Linux: NSS

No Linux: PAM

No SSH

EKS and NetworkPolicies: the story so far

Kubernetes NetworkPolicies

Securing the application

NetworkPolicy Controller

EKS and NetworkPolicies

Final notes

Links

Terraform refactoring

Contexto

Refactor para variáveis e objetos

Observabilidade com Prometheus

Prometheus

Tipos de métricas

Gauges

curl, downloads, ouputs e muitos "o"s

Nível 0: preguiçoso

Nível 1: Júnior

Nível 2: pleno

Nível 3: Sênior

Nível 4: Especialista

Bônus: verificação de download