Devops on Crimideias do caioau

Slides: Dockerfile: Hardening e boas práticas (Sorocoded 2a edição)

Sat, 16 May 2026 01:00:00 +1100

Atividade realizada dia 16 maio 2026, na segunda edição do sorocoded.

slides (arquivo markdown editável e outros artefatos usados feito com pandoc com beamer (latex), excelente template: alexeygumirov/pandoc-beamer-how-to).

Slides: Dockerfile: Hardening e boas práticas (CoffeOps)

Sat, 18 Apr 2026 01:00:00 +1100

Atividade realizada dia 18 abril 2026, no CoffeeOps Campinas SP no Laboratório Hacker de Campinas – LHC

slides (arquivo markdown editável e outros artefatos usados feito com Marp).

Dockerfile: Hardening e boas práticas

Mon, 16 Feb 2026 10:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 28Jan2026

Dockerfile é tudo igual? Se a imagem está sendo buildada e a aplicação está rodando, posso mandar bala? Vamos ver nesse texto que não. Existem outras considerações a serem feitas, principalmente de segurança. Vamos nos debruçar para encontrar o Dockerfile mínimo contendo apenas o necessário para rodar nosso app em Python.

Foto de S. Laiba Ali, unsplash

Nosso exemplo: API em Python com Flask

Nesse texto vamos explorar bastante esse exemplo, que retorna um “Hello world” simples, e pra fazer uma graça um endpoint que retorna de volta o que foi enviado no caminho da url.

from flask import Flask

app = Flask(__name__)

@app.route("/hello")
def hello_default():
    return hello("")

@app.route("/hello/<string:hellomsg>")
def hello(hellomsg: str) -> str:
    res = "hello world!"
    if len(hellomsg) > 0:
        res = hellomsg
    return res

if __name__ == "__main__":
    app.run(host="0.0.0.0")

app.py

Pra quem quiser brincar com eles, todos os códigos e arquivos utilizados nesse texto estão disponíveis no seguinte repositório gitlab.com/caioau/caioau.gitlab.io

Junto do Dockerfile temos o nosso requirements.txt:

1
2

Flask~=3.1.2
gunicorn~=23.0.0

requirements.txt

Para quem não está familiarizado com a notação ~= estamos usando apontando para versão compatível, como as bibliotecas utilizam versionamento semântico (semver.org) vamos utilizar versões mais novas mas dentro do mesmo menor (minor), mas sem mudanças que quebrem as funcionalidades atuais. A linha Flask~=3.1.2 equivale a Flask>=3.1.2,Flask==3.1.*

Dockerfile v0

Com o código-fonte do nosso app, podemos seguir com o Dockerfile.

A fim de ajudar no debug do app, vamos incluir o vim e curl nas imagens.

FROM debian:bullseye

RUN apt-get update && \
    apt-get install -y \
    python3-pip python3-dev \
    build-essential \
    curl \
    vim

RUN apt-get clean && rm -rf /var/lib/apt/lists/*

WORKDIR /usr/src/app

COPY . /usr/src/app/

RUN pip3 install -r requirements.txt

RUN rm -rf ~/.cache/pip

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v0

O que está acontecendo? Utilizando uma imagem base do Debian, instalamos o Python com outros pacotes que fazem a compilação (build-essential e python3-dev). E daí na próxima instrução deletamos o índice do apt-get.

Mudamos a pasta de trabalho (WORKDIR) e copiamos o código-fonte da aplicação lá, instalamos as dependências da aplicação e similarmente com os índices do apt-get deletamos o cache do pip.

Por fim, configuramos o comando que sobe a aplicação, utilizando o gunicorn como servidor web Python.

Quando colocamos para rodar a imagem, a aplicação funciona \o/

Porém, além de outros problemas de que vamos falar logo, o tamanho da imagem: 570MB, tá bom pra você quase 600 megabytes por um simples hello world?

Fica até o final, porque ~~vai ter bolo~~ vamos reduzir o tamanho dessa imagem para 10x menor.

Observação: Nesse texto, quando estivermos falando do tamanho da imagem, estamos nos referindo ao tamanho sem compressão, ou seja, o valor reportado por docker image ls, ao passo que o tamanho que aparece na página WEB no dockerhub ou outros registries é o tamanho com compressão. Por exemplo, uma imagem de 522 MB sem compressão resulta em 192 MB com compressão.

Dissecando imagens com dive

A nossa primeira dica é usar o dive para “dissecar” a imagem. Uma vez carregada, conseguimos acompanhar como estão os arquivos, então podemos ir “caminhando” a partir da camada inicial até a final como os arquivos foram sendo alterados e dessa forma conseguimos mais facilmente visualizar o que está acontecendo e identificar pontos de melhoria.

Para instalar, basta baixar o binário do github: github.com/wagoodman/dive

Com ele instalado basta executar com o nome da imagem

Bora ver como o dive analisa nossa imagem? Carregando ele podemos o histórico das instruções do nosso Dockerfile, cada instrução gera uma camada e vamos caminhando nesse histórico. Como são muitos arquivos na imagem base, podemos mostrar apenas os arquivos modificados (pressionando Ctrl+U). Vamos retomar esse ponto importante, mas preste atenção na instrução COPY . . quais arquivos são copiados, além do código-fonte.

Com a imagem analisada percebemos dois erros: os índices do apt e o cache do pip não foram limpos, aumentando o tamanho da imagem final desnecessariamente. Isso aconteceu pois a deleção dos arquivos não está na mesma instrução (RUN) do que a criação deles, propagando para a próxima camada.

Repare no canto inferior esquerdo que a ferramenta dá algumas dicas de onde melhorar, para a imagem ficar mais eficiente.

Use dockerignore

O outro erro da nossa v0 foi que alguns arquivos sensíveis vazaram, em particular o arquivo .env com credenciais. Isso aconteceu pois quando copiamos os arquivos em COPY . . todos arquivos no contexto do docker são copiados.

Como resolver? Podemos colocar tudo o que podemos copiar no Docker dentro de uma pasta dedicada, mas teríamos que manter esse controle.

Uma solução mais robusta é utilizar o arquivo .dockerignore (documentação), que funciona de uma forma similar ao .gitignore, limitando a quais arquivos é permitido o acesso no contexto Docker.

# ignora tudo
*

# permite codigos fonte
!/src
!*.py
!requirements.txt
!entrypoint.sh

# especifico do python
**/__pycache__/
**/*.py[cod]
# C extensions
*.so
**/.ipynb_checkpoints/

.dockerignore

Acima temos um exemplo de dockerignore que resolve nosso problema, onde todos os arquivos são por padrão bloqueados, e então vamos criando exceções como arquivos de código-fonte.

Dockerfile v1

Com as lições aprendidas na versão anterior, bora arrumar os erros que encontramos?

FROM debian:bullseye

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    python3-pip python3-dev python3-venv \
    build-essential \
    curl \
    vim && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python . /home/python/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

ENV PATH="/home/python/app/.venv/bin:$PATH" # "ativa" o venv

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v1

O que mudamos da versão anterior? Colocamos a deleção dos arquivos desnecessários na mesma instrução (no caso do pip install utilizamos a opção –no-cache-dir).

Também usamos um ambiente virtual (venv) para melhor lidar com as dependências Python.

E por fim, para não rodar como root, criamos um usuário não root e o utilizamos sempre que possível. Se atente que o pip install foi executado como não root.

E o tamanho? Apesar de só termos mexido no cache do pip e os índices, a nova imagem é tem 520MB , aproximadamente 50MB menor (~10%).

User não root basta?

Criamos um usuário não root e paramos de usar o root, mas isso basta? A resposta é não, pois caso a aplicação esteja comprometida, o ataque pode usar qualquer binário presente na imagem para realizar ações mal-intencionadas. Um excelente site explorando isso é o GTFOBins que mostra como fazer essas explorações para cada binário.

Outro argumento é o princípio do privilégio mínimo que dita que devemos apenas usar as permissões mínimas necessárias para o funcionamento dos nossos sistemas, caso contrário as permissões excedentes podem ser abusadas.

Bora para uma revisão rápida de permissão de arquivos no Linux? O octeto de permissão é definido pelas permissões (do mais significativo para menos) ler (Read), escrever (Write) e executar (eXecute). E temos esse octeto três vezes (da esquerda pra direita): Para o dono, para o grupo e para outros.

Bora para um exemplo:

O dono vai poder ler (4), escrever (2) e executar (1) -> 4 + 2 + 1 = 7
O grupo vai poder ler (4) e executar (1) -> 4 + 1 = 5
Por fim outros vão poder apenas ler (4) -> 4

Resultado: Executando chmod 754 vai gerar o resultado que queremos.

Até aí tudo bem, mas além desses 3 dígitos tem um quarto dígito, normalmente omitido, à esquerda que define mais um octeto o Suid , Guid e o Sticky Bit. Se a gente setar o suid no nosso exemplo anterior, a permissão que tínhamos 754 vira 4754 (adicionando o 4 à esquerda).

E o que faz esse suid? Quando setado o arquivo quando executado não é executado por quem executa, mas por quem é dono do arquivo, que tipicamente é o root, ou seja, qualquer usuário “vira root” (o sudo funciona assim).

commitstrip.com/en/2016/06/29/chmod-what/

Bora mostrar na prática?

FROM debian:bullseye

RUN cp /bin/bash /bin/bash-suid && chmod u+s /bin/bash-suid

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/

Dockerfile-setuid

No dockerfile acima criamos um novo bash chamado bash-uid, com a permissão suid, agora mesmo que estejamos rodando como um usuário não root, se invocado esse bash especial escalamos o privilégio para root.

Para desarmar essa possibilidade, suba o container com a opção no-new-privileges que efetivamente protege contra a escalação de privilégio.

demonstrando o setuid

Repare que quando executamos o bash especial efetivamente se tornamos root, porém com a opção no-new-privileges habilitada resolvemos o problema.

Para outras boas práticas de segurança para containers docker consulte a excelente cartilha da OWASP (comunidade que publica diversas boas práticas de segurança para aplicações web): OWASP Docker Security Cheat Sheet

Dockerfile v2: introduzindo multistage

Até então estamos instalando compiladores necessários para o pip install, utilizando o pacote build-essential, porém em tempo de execução os mesmos não são necessários, esse é o cenário que a funcionalidade do multi-stage do docker resolve.

O multi-stage acontece quando utilizamos a instrução FROM múltiplas vezes, criando estágios separados, tipicamente para o build e um estágio final utilizado em tempo de execução, dessa forma os artefatos resultantes do build são passados pro estágio final, e os compiladores e outras ferramentas do build são instalados apenas no estágio de build, resultando uma imagem final menor.

FROM python:3.13 AS builder

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python . /home/python/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

FROM python:3.13-slim AS runtime

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python --from=builder /home/python/app/ /home/python/app/

ENV PATH="/home/python/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v2

Dessa vez optamos por usar as imagens oficiais do python, então não precisamos instalar o python em si e os compiladores que precisamos em tempo de build. Agora o grande pulo do gato do multi-stage, as imagens de build e runtime são diferentes, a de build (python:3.13) têm 1.1GB e a de runtime (python:3.13-slim) aproximadamente 10% do seu tamanho com 120MB.

Outra mudança na imagem base, até então estávamos usando a release bullseye do Debian, mas consultando o endoflife.date podemos ver que essa release perdeu suporte principal, agora com a imagem python a tag 3.13 aponta para a release corrente do stable do Debian. Além de usarmos a variante slim da imagem do debian, sempre que possível opte por essa opção.

Uma dica valiosa para sempre manter suas dependências atualizadas é utilizar o dependabot ou similares como o renovate, que periodicamente atualiza as dependências automaticamente abrindo um pull request com a atualização.

Como ficou o tamanho? Essa versão ficou com 130 MB, um quarto da nossa primeira versão.

Fazendo nosso app em Golang

Até agora estávamos usando Python no nosso app, porém para o próximo conceito de imagens distroless, usar uma linguagem compilada, em particular Go, pois ele permite a compilação estática, ou seja toda a aplicação fica “empacotada” em apenas um binário, sem precisar de outros arquivos/pacotes para que a nossa app funcione.

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "time"
)

func rootHandler(w http.ResponseWriter, req *http.Request) {
    log.Printf("%v", req)
    fmt.Fprintf(w, "hello world!\n")
}

func helloHandler(w http.ResponseWriter, req *http.Request) {
    log.Printf("%v", req)
    msg := req.PathValue("msg")
    fmt.Fprintf(w, "%s", msg+"\n")
}

func weatherHandler(w http.ResponseWriter, req *http.Request) {
    url := "https://wttr.in/?T&lang=pt-br"
    ua := "curl/8.5.0"
    log.Println("making a GET request to url=", url, "...")
    client := http.Client{ // set a request timeout
        Timeout: 20 * time.Second,
    }

    r, err := http.NewRequest("GET", url, nil)
    if err != nil {
        panic(err)
    }
    r.Header.Add("User-Agent", ua)

    resp, err := client.Do(r)
    if err != nil || resp.StatusCode != http.StatusOK {
        log.Println("making a GET request to url=", url, "Failed! Returning a 500")
        log.Println("err=", err)
        w.WriteHeader(500)
        fmt.Fprintf(w, "request failed!\n")
        return
    }
    defer resp.Body.Close()
    log.Println("making a GET request to url=", url, "Done! Response code=", resp.Status)

    written, err := io.Copy(w, resp.Body)
    if err != nil {
        log.Printf("Error writing response after %d bytes: %v", written, err)
    }

}

func main() {
    apiPort := "8000"

    http.HandleFunc("/", rootHandler)
    http.HandleFunc("/weather/", weatherHandler)
    http.HandleFunc("/hello/{msg}", helloHandler)

    log.Println("Listening on port=", apiPort)

    panic(http.ListenAndServe(":"+apiPort, nil))

}

app.go

Nosso app continua igual à versão em Python, mas agora temos um endpoint a mais que faz um request externo para o site wttr.in obter a previsão do tempo.

E como fica o nosso Dockerfile? Como Golang é uma linguagem compilada vamos mostrar nesse exemplo a funcionalidade do multi-stage ao extremo: Criando um container com apenas o binário da nossa app.

FROM golang:1.25 AS builder

RUN useradd -u 1000 -U -m --shell /bin/bash nonroot

USER nonroot

WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN CGO_ENABLED=0 go build -ldflags="-s -w" app

FROM scratch

COPY --from=builder /etc/passwd /etc/passwd
# truque pra rodar nonroot no scratch

COPY --from=builder /home/nonroot/app/app /usr/local/bin/

USER nonroot
EXPOSE 8000

ENTRYPOINT [ "app" ]

golang/Dockerfile-scratch

Como podemos ver, compilamos nosso app no estágio de build, usando uma imagem que contém os compiladores e outras ferramentas para gerar o nosso binário, e como estamos compilando estaticamente (usando opção CGO_ENABLED=0) apenas o nosso binário é necessário para a aplicação funcionar. E depois do estágio de build, o estágio final não está utilizando nenhuma imagem base (SCRATCH), ou seja, nossa imagem final vai conter apenas o binário do nosso app.

Para quem ficou curioso, essa imagem tem apenas 6 MB, ao passo que a imagem base de build (golang:1.25) tem 850MB.

Quem quiser se aprofundar em diminuir o tamanho do binário ainda mais dá pra usar o upx (github.com/upx/upx) que faz compressão de executáveis, que reduziu o tamanho para ~2MB. Porém, acho que não vale a pena adotar essa abordagem, pois o Docker já faz essa compressão quando faz o download das imagens, então usar o upx só vai fazer seu app demorar mais para inicializar.

Se subirmos o container, vemos que os endpoints “hello world” funcionam, mas o endpoint de previsão de tempo não, com o erro: “tls: failed to verify certificate: x509: certificate signed by unknown authority”. Não temos a cadeia de certificados

Essa foi a nossa deixa para falarmos do conceito de imagens distroless.

Imagens distroless (github.com/GoogleContainerTools/distroless) foram introduzidos pela Google, e a ideia é que as imagens base tem o mínimo necessário para rodar a aplicação, sem ter uma distribuição base como o debian por trás, ou seja não tem o apt para instalar pacotes ou shell, etc …

Quem tiver interesse no repositório oficial, tem exemplos para várias linguagens. O que é chato dessas imagens é que caso você precise adicionar algum pacote que a imagem base não tem você precisa aprender o sistema de build pouco intuitivo chamado Bazel.

No nosso caso a imagem base distroless é a gcr.io/distroless/static, ela tem apenas 2MB. Quais pacotes ela tem? Como não temos o apt, não vamos conseguir facilmente listar os pacotes.

Para resolver esse problema de identificar os pacotes vamos introduzir um conceito do Software Bill of materials (SBOM), é um “inventário” identificando todos os componentes presentes em um determinado artefato de software. Ele tem alguns formatos padrão, o mais difundido é o System Package Data Exchange (SPDX) , tipicamente representado em um arquivo json. Nesse arquivo teremos as versões de todos os componentes, suas licenças e por fim os relacionamentos (como dependências).

É uma boa prática gerar o SBOM junto ao build da imagem Docker, pois isso facilita demais auditorias de segurança, por exemplo, quando identificada uma vulnerabilidade em uma biblioteca que utilizamos, conseguimos facilmente encontrar se de fato estamos seguros ou onde precisamos atuar atualizando um pacote para uma versão não vulnerável.

Vamos gerar o nosso SBOM utilizando o syft (github.com/anchore/syft), nossa imagem tem os seguintes pacotes: a cadeia de certificados que precisamos e infos de fuso horários necessários para alguns apps.

Usando essa imagem como base no estágio final, nosso endpoint de previsão do tempo funciona \o/

endpoint weather funcioando \o/

Debugando imagens distroless

Uma das maiores dificuldades em utilizar as imagens mínimas distroless é a de fazer o debug das aplicações, por exemplo, rodar um debugger com breakpoints para investigar algum bug.

Vamos abordar duas formas de resolver isso, a primeira é ter duas versões do Dockerfile, uma mínima utilizada em produção e uma versão “desenvolvedor” que inclui um shell, o gerenciador de pacotes como o apt e outros pacotes para esse fim.

Outra abordagem é “anexar” um container de debug junto ao container da aplicação, também chamado de container sidecar, o container de debug tem um shell e as ferramentas necessárias para fazer o debug e atua lado-a-lado da aplicação rodando.

Bora ver os pacotes da aplicação? Subi nosso app Golang com um container chamado golang, então vamos subir outro container usando o mesmo namespace de processos (pid) e na mesma rede, conforme o comando abaixo:

docker run --rm -it --privileged --pid container:golang --network container:golang nicolaka/netshoot

Observação: a imagem nicolaka/netshoot (github.com/nicolaka/netshoot) é uma imagem com diversas ferramentas de rede instaladas. Para Kubernetes a imagem bretfisher/shpod (github.com/bretfisher/shpod) é ótima com diversas ferramentas para fazer debug do cluster.

Por que o container precisa ser privilegiado? Para conseguirmos acessar os arquivos do outro arquivo, vá em /proc/1/root , e você estará no filesystem da aplicação. Onde 1 é o id do processo do app.

wizardzines.com/comics/proc

Antes de capturar os pacotes, bora dar um tutorial rápido de Wireshark? O wireguark é um aplicativo desktop que faz 2 coisas em uma, primeiro ele captura os pacotes passando na maquina e depois ele tem uma interface muito completa para visualizar o tráfego, vendo detalhes de cada pacote, possibilitando filtros e fazendo visualizações como diagramas de estado e estatísticas para ajudar a entender o que está acontecendo.

No nosso caso, como estamos utilizando containers, não vamos ter a interface gráfica do Wireshark, então podemos fazer de duas formas: capturar os pacotes utilizando o tcpdump (que não tem interface gráfica), salvar um arquivo pcap e visualizar no Wireshark. A outra opção é utilizar uma alternativa “terminal” do Wireshark, o termshark, com ele teremos uma experiência parecida com a original.

Para abrir o termshark precisamos especificar uma interface da qual os pacotes serão capturados, no nosso caso só temos uma interface, então não precisamos. Uma vez aberto, podemos ver que mesmo sem mandar muitos requests pro nosso app tem muitos pacotes que não são do nosso interesse, como os pacotes do protocolo ARP. Então é uma mão na roda usar filtros, podemos filtrar por IP, por porta , protocolo, etc …. Tem uma colinha dos filtros nesse link: https://medium.comhacker-toolbelt/wireshark-filters-cheat-sheet-eacdc438969c

Com o termshark aberto e filtrando apenas pacotes HTTP, no print abaixo podemos ver a aplicação rodando no terminal superior esquerdo, um request sendo feito com curl no terminal da direita e abaixo estamos rodando a versão

Fechando o parêntese do nosso tutorial 101 do wireshark, se tiver interesse em um texto aprofundado escreva pra gente :)

Para facilitar nossa vida, tem uma ferramenta que faz essa abordagem de maneira simplificada, o cdebug (github.com/iximiuz/cdebug), com uma feature adicional: fazer redirecionamento de portas não públicas (semelhante ao kubectl port-forward).

Fazendo o scan de vulnerabilidades nas imagens

Até agora o nosso intuito era diminuir o tamanho das imagens, pois dessa forma teríamos uma superfície de ataque menor, mas não medimos se de fato temos menos vulnerabilidades.

Vamos adotar o grype (github.com/anchore/grype), outra opção muito boa é o trivy (github.com/aquasecurity/trivy)

A nossa primeira versão (v1) tem 1334 CVEs :/ , das quais 6 são critical, 257 high, 894 medium, etc.

Já a nossa versão multistage (v2) tem 10x menos vulnerabilidades: com 136 CVEs , das quais 4 critical, 6 high, 36 medium.

Como pode um simples hello world ter 1300 CVEs? Em resumo, é porque imagens baseadas em Debian não atualizam por completo as versões para corrigir as CVEs, vamos falar em mais detalhes na próxima seção.

Debian: Estamos sendo justos com ele?

Vimos que a nossa imagem tem mais de mil vulnerabilidades, mas por que isso acontece? Estou de fato em risco?

A resposta é que provavelmente o problema não é tão grave quanto parece, só que a maneira que os scanners funcionam não bate bem da maneira que o Debian opera. O Debian quando tem sua versão stable declarada todos os pacotes são congelados na versão que estão e são feitos diversos testes para que tudo funcione até que seja lançada ao público a release.

Quando bugs são encontrados, de segurança ou não, o Debian muitas vezes simplesmente aplica a mudança (patch) que corrige o problema em cima da versão que saiu no stable.

Ao passo que os scanners de segurança funcionam identificando os pacotes e outros componentes de software (SBOM) e cruzar com um banco de dados de vulnerabilidades.

Ou seja, os scanners não estão nem aí pras mudanças que o Debian aplicou.

Por exemplo, nossa primeira versão de ambos o trivy e grype reportaram a CVE-2023-23914 (HSTS ignored on multiple requests) no curl, que de fato é uma vulnerabilidade crítica. Pois bora tentar reproduzir a vulnerabilidade?

Na página da CVE (curl.se/docs/CVE-2023-23914.html), basta rodar o seguinte: curl --hsts "" https://curl.se http://curl.se, quando vulnerável, o curl vai fazer o segundo request sem https, mesmo com o site esforçando HSTS. Porém, o comando falha pois a feature de HSTS nem foi introduzida na versão do curl adotada no Debian Bullseye. Ou seja, é um falso positivo.

Um excelente blog post falando sobre essa situação é Image Vulnerability Scanning and You -- linuxserver, da linuxserver, grupo que disponibiliza imagens docker para diversas aplicações open source, no blog post eles mostram como esses resultados aparentemente alarmante de scanners de vulnerabilidades, são falsos positivos. Eles deram um exemplo de uma vulnerabilidade, a CVE-2020-16156, que só pode ser explorada caso um usuário altere configurações de maneira maliciosa, ou seja, para explorar a vulnerabilidade você já teria que estar comprometido, o que é um problema muito maior.

O scanner grype tem uma opção para apenas considerar vulnerabilidades que de fato serão corrigidas (–only-fixed), rodando essa opção na nossa v2, as 130 vulnerabilidades caem para 2, uma de severidade medium e outra unknown.

Imagens chainguard

As imagens da Chainguard são imagens produzidas pela empresa de mesmo nome que, além de serem menores, fazem um grande esforço para as imagens estarem com os pacotes atualizados e com as correções de segurança aplicadas.

Outra feature legal dessas imagens é que toda vez que um pacote é instalado o SBOM dele é automaticamente gerado, criando um melhor lastro do conteúdo da imagem.

Para quem está acostumado com imagens baseadas em debian precisa se acostumar pois as imagens do chainguard são baseadas no alpine, ou seja, ao invés do gerenciador de pacotes apt é utilizado o apk, então tem uma certa “curva de aprendizado” para se acostumar, uma dica pra encontrar os pacotes equivalentes é utilizar o apk search com cmd para procurar o pacote que contém aquele comando, por exemplo para instalar o ldd, faça: apk search cmd:ldd e o pacote associado será o posix-libc-utils.

Outra diferença entre as imagens baseadas no Debian e do Alpine é o shell, nas imagens Debian o shell adotado é o bash, enquanto no Alpine é um shell mais limitado o ash (provido pelo busybox), então se seus scripts contém “bashismos” você precisa ver o que faz mais sentido entre tornar eles interoperáveis (posix-compliant) ou instalar o bash na imagem.

Apesar de ser baseada no alpine, as imagens chainguard não utilizam a biblioteca padrão musl do alpine, mas sim a implementação mais difundida da GNU a glibc, vamos retomar essa diferença mais a frente.

Bora colocar nossa app Python para usar o Chainguard?

FROM cgr.dev/chainguard/wolfi-base

ARG pyversion=3.12

RUN apk add python-${pyversion} py${pyversion}-pip python-${pyversion}-dev \
    build-base openssl-dev vim curl && \
    rm -rf /var/cache/apk/*

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

ENV PATH="/home/nonroot/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v3

A imagem base da Chainguard é o wolfi, ela é uma imagem pequena da qual instalamos os pacotes de que precisamos.

A principal diferença é que os pacotes têm outros nomes, por exemplo, o equivalente do build-essential é o build-base, e diferentemente do Debian podemos escolher qual versão do Python vamos adotar.

Já vem com um usuário não root, então basta utilizar ele.

Quem tiver curiosidade em inspecionar a imagem com o dive, os SBOMs SPDX de cada pacote estão em /var/lib/db/sbom/.

E as CVEs? É aqui que a Chainguard brilha, nenhuma CVE reportada no Trivy ^_^, porém apesar da Chainguard ter uma postura bastante proativa para manter toda cadeia de suprimento segura e atualizada, você precisa periodicamente rebuildar as imagens para usar as versões mais atuais dos pacotes e das nossas bibliotecas de que dependemos (que permitimos que sejam atualizadas para versões compatíveis).

Quem tiver interesse em aprender mais sobre as imagens chainguard eles tem excelentes guias com passo-a-passo, exemplo e cursos em edu.chainguard.dev gostei bastante da dinâmica dos cursos, com vídeos curtos e acompanhados de um texto do que é mostrado no vídeo.

Criando imagens distroless da Chainguard com Melange

No exemplo anterior utilizamos a imagem base da Chainguard para o nosso app Python, porém ela não é uma imagem distroless, visto que ela tem um shell, o apk e etc. … A Chainguard tem imagens distroless do Python e outras linguagens e projetos, porém só podemos usar gratuitamente sua tag latest

Para termos uma imagem distroless pra chamar de nossa, vamos utilizar o sistema de build da Chainguard, o Melange.

edu.chainguard.dev/open-source/build-tools/melange/overview

Primeiramente precisamos empacotar nossa app python em um pacote alpine apk usando o melange, para fazer esse empacotamento teremos uma pipeline de build no melange declarada a partir do arquivo yaml abaixo:

package:
  name: hello-crud
  version: 0.0.1
  epoch: 0
  description: REST hello world
  copyright:
    - license: Apache-2.0
      paths:
        - "*"
  dependencies:
    runtime:
      - python-3.12

environment:
  accounts:
    groups:
      - groupname: nonroot
        gid: 65532
    users:
      - username: nonroot
        uid: 65532
    run-as: nonroot
  contents:
    keyring:
      - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
      - ./melange.rsa.pub
    repositories:
      - https://packages.wolfi.dev/os
    packages:
      - busybox
      - glibc
      - glibc-locale-posix
      - openssl-dev
      - build-base
      - python-3.12
      - py3.12-pip

pipeline:
  - name: Build Python application
    runs: |
      VENVDIR=/usr/share/webapps/hello-server/venv
      EXECDIR="${{targets.destdir}}/usr/bin"
      WEBAPPDIR="${{targets.destdir}}/usr/share/webapps/hello-server"
      mkdir -p "${EXECDIR}" "${WEBAPPDIR}" /usr/share/webapps/hello-server
      cd /usr/share/webapps/hello-server
      echo -e "\n\n#########################################\n"
      python3 -m venv ${VENVDIR}
      cd /home/build
      sh -c ". ${VENVDIR}/bin/activate && pip3 install --no-compile --no-cache-dir -r requirements.txt && pip3 uninstall -y pip"
      cp -r ${VENVDIR} ${WEBAPPDIR}
      cp app.py ${WEBAPPDIR}
      chown -R 65532:65532 ${WEBAPPDIR}

melange.yaml

Nesse yaml a gente declara as informações do nosso pacote, como nome, versão e licença e as dependências em tempo de execução dele, no nosso caso apenas o python3.12.

Em seguida declaramos o que o nosso ambiente de build precisa: os pacotes de build, o usuário não root e os repositórios wolfi para usarmos os pacotes da chainguard (poderíamos usar o alpine se quiser).

Por fim a pipeline de build em si, ou seja uma sequência de comandos shell que builda a app e copia tudo para uma pasta em targets.destdir.

Fizemos uma pequena alteração no nosso pip install, utilizando a flag –no-compile que não gera os arquivos .pyc, dessa forma o venv fica menor. Tem um excelente blog post explicando os trade-offs dessa abordagem: Stop putting this into your Python Dockerfiles -- Aleksa Cukovic

Bora buildar nosso pacote?

Na primeira vez precisamos gerar uma chave privada para assinar o pacote:

docker run --rm -v "${PWD}":/work cgr.dev/chainguard/melange keygen

Não se preocupe com os comandos, criei um makefile no repositório que executa os comandos em sequência.

Então o build:

docker run --privileged --rm -v "${PWD}":/work cgr.dev/chainguard/melange build melange.yaml --arch amd64 --signing-key melange.rsa

Pronto! Uma vez executado, teremos nosso pacote alpine na pasta packages.

Com o nosso pacote alpine pronto, bora criar o container que faz o deploy do nosso app? É agora que surge o apko, nele declaramos o container usado em tempo de execução (runtime) contendo o pacote previamente gerado, é como se fosse um Dockerfile, mas feito de forma declarativa.

Agora o nosso apko.yaml:

contents:
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
    - ./melange.rsa.pub
  repositories:
    - https://packages.wolfi.dev/os
    - '@local /work/packages'
  packages:
    - hello-crud@local
accounts:
  groups:
    - groupname: nonroot
      gid: 65532
  users:
    - username: nonroot
      uid: 65532
  run-as: nonroot
environment:
  PATH: /usr/share/webapps/hello-server/venv/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
work-dir: /usr/share/webapps/hello-server/
entrypoint:
  command: gunicorn -w 2 -b 0.0.0.0:8000 --access-logfile - --error-logfile - app:app

apko.yaml

No nosso apko declaramos os repositórios da chainguard (ou alpine), os pacotes: no nosso caso apenas o pacote da nossa app, o usuário não root e as condições pro nosso app rodar como variaveis de ambiente e o comando entrypoint.

Para buildar nossa imagem:

docker run --rm --workdir /work -v ${PWD}:/work cgr.dev/chainguard/apko build apko.yaml hello-crud:test hello-crud-server.tar --arch host

Cuidado que a imagem não é carregada automaticamente no docker, você precisa fazer docker image load -i hello-crud-server.tar

E o resultado? A imagem ficou com 65MB \o/

Em retrospectiva a nossa primeira versão do dockerfile tinha 570MB, a versão multistage usando debian 190MB e agora quase 10x menor com 65MB, não vai embora ainda não porque vamos melhorar ainda mais.

Distroless sem o melange e apko

Na seção anterior mostrei como usar o melange e o apko para declarativamente criar imagens mínimas para sua aplicação, porém é um sistema de build dedicado que você vai ter que aprender e manter, minha intenção era mostrar que não é um bicho de sete cabeças , pelo contrário o melange e o apko são bastante amigáveis.

Porém pra quem não quiser aprender um novo sistema de build e não se importa em quebrar a cabeça fazendo um Dockerfile especializado temos essa alternativa.

A peça crítica para esse Dockerfile funcionar é que o gerenciador de pacotes apk suporta chroot, ou seja podemos instalar pacotes em outro sistema de arquivos por “fora da caixa”, sem precisarmos instalar o apk em si ou ter um shell para conseguir rodar qualquer comando durante o build.

talk is cheap, show me the code:

ARG ROOTFS=/new_root
ARG pyversion=3.12
# nonroot user
ARG PGID=1000
ARG PUID=1000

FROM cgr.dev/chainguard/wolfi-base AS appbuilder

ARG pyversion

RUN apk add python-${pyversion} py${pyversion}-pip python-${pyversion}-dev build-base openssl-dev && \
    rm -rf /var/cache/apk/*

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-compile --no-cache-dir -r requirements.txt && \
    pip3 uninstall -y pip

FROM cgr.dev/chainguard/wolfi-base AS chrootbuilder

ARG ROOTFS
ARG pyversion
ARG PGID
ARG PUID

RUN mkdir -p $ROOTFS/etc/apk/keys && \
    cp -v /etc/apk/keys/* $ROOTFS/etc/apk/keys/ && \
    cp -v /etc/apk/repositories  $ROOTFS/etc/apk/repositories

RUN apk add shadow && \
    rm -rf /var/cache/apk/*

RUN apk add --no-commit-hooks --root $ROOTFS --initdb glibc glibc-locale-posix \
    python-${pyversion} &&\
    rm -rf $ROOTFS/var/cache/apk/*

RUN groupadd -g ${PGID} -R $ROOTFS nonroot &&\
    useradd -u ${PUID} -g nonroot -m --shell /bin/sh -R $ROOTFS nonroot

FROM scratch AS runtime

ARG ROOTFS

COPY --from=chrootbuilder $ROOTFS /

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot --from=appbuilder /home/nonroot/app/ /home/nonroot/app/

ENV PATH="/home/nonroot/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v4

O Dockerfile tem 3 estágios: um que faz o “build” do nosso venv e da app, um que gera o ambiente chroot com as dependências de tempo de execução e o estágio final que junta os dois. Fiz dessa forma para separar a nossa “imagem base” com o runtime de python, que é desacoplado da nossa app e o build do venv que aí sim depende da nossa app, dessa forma rebuilds com cache só fazem o build o que mudou.

O grande pulo do gato é o uso das flags do apk: -R apontando para chroot, –no-commit-hooks pois os hooks não se aplicam quando usando chroots e –initdb para inicializar o database do apk, sem isso o database não será gerado e ferramentas de SBOM não funcionam.

E o resultado? O tamanho ficou muito próximo do apko (65MB), com apenas alguns KBs de diferença.

glibc vs musl: O inimigo agora é outro

Quanto comecei minha jornada com Docker e comecei a colocar meus apps Python no docker, na época pelo menos era inviável usar imagens base alpine pois não tinha os wheels pré-compilados para biblioteca padrão c musl do alpine então qualquer app que precisava do numpy o build demorava demais pra compilar, então deixei de lado as imagens alpine.

Mas agora quando tentei novamente o pypi tem os wheels pré-compilados pro musl e outras arquiteturas como o arm \o/

Porém as imagens da chainguard apesar de serem baseadas no alpine não utilizam a musl, mas sim a implementação mais difundida a glibc, tem um artigo deles bastante completo explicando o diversos aspectos por trás dessa decisão, como compatibilidade com binários dinamicamente linkados:

glibc vs. musl -- Chainguard

O dockerfile ficou igual ao dockerfile-v4, porém mudando a imagem base do wolfi para a release mais recente do alpine (alpine:3.23). E o tamanho da imagem ficou uns ~15MB menor que a do melange (50MB).

Bora fazer uma retrospectiva de como foi evoluindo o tamanho da nossa imagem Python? Podemos ver na tabela abaixo que começamos com o nosso Dockerfile v0 bem tradicional com quase 600MB e com o multistage o tamanho caiu para um quarto da v0 e metade disso usando distroless.

Versão	Tamanho [MB]	Percentual de v0
v0	570	-
v1 (delete dos caches e índices)	520	91%
v2 (multistage)	130	22%
v4 (distroless chroot/melange)	65	11%
v5 (distroless com alpine+musl)	50	9%

Observação: Omitimos a v3 pois nela o objetivo era migrar para imagens baseadas em alpine, sem o foco em otimizar seu tamanho.

Hadolint

Pra fechar o texto, a última dica é utilizar o Hadolint (github.com/hadolint/hadolint), ele dá excelentes dicas para as boas práticas de que falamos aqui, tem extensão pro VSCode e de quebra roda o outro linter excelente para shell shellcheck.net dentro das instruções RUN, então você leva dois linters dentro de um.

Conclusão

Resgatando a provocação inicial, espero a essa altura ter te convencido de que dockerfile não é tudo igual, que não posta a aplicação funcionar para termos um bom dockerfile.

O princípio que mais exploramos é tornar a imagem enxuta possível, pois além de imagens menores serem mais performáticas, elas têm uma superfície de ataque menor e dessa forma conseguimos identificar quais dependências são realmente necessárias em tempo de execução da aplicação.

Para “enxugar” as imagens vimos como o dive é uma ferramenta muito prática para dissecar camada a camada as imagens e identificar os pontos de melhoria, e o conceito de multi-stage para separar o build e o runtime.

Por fim, levando ao extremo o objetivo do multi-stage , vimos o conceito das imagens distroless e como fazer elas com o melange e o apko, porém o desafio de debugar essas imagens.

Espero que esse texto te auxilie a criar imagens Docker melhores e muito obrigado por chegar até aqui!

Slides: Navegando logs usando lnav (CoffeOps)

Sat, 20 Dec 2025 01:00:00 +1100

Atividade realizada dia 20 dezembro 2025, no CoffeeOps Campinas SP no Laboratório Hacker de Campinas – LHC

slides (arquivo markdown editável e outros artefatos usados feito com Marp).

Slides: Primeiros passos com self-hosting (cryptorave 2024)

Tue, 07 May 2024 08:00:00 -0300

Atividade realizada dia 11 maio 2024, na cryptorave.

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Primeiros passos com self-hosting (cryptorave 2023)

Thu, 04 May 2023 08:00:00 -0300

Atividade realizada dia 5 maio 2023, na cryptorave.

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Primeiros passos com self-hosting (TOSCONF[3])

Fri, 17 Mar 2023 08:00:00 -0300

Atividade realizada dia 18 março 2023, na TOSCONF[3] no Laboratório Hacker de Campinas – LHC

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Testando playbooks com molecule

Mon, 03 Oct 2022 16:00:00 -0300

Atividade realizada dia 28 setembro 2022, no Eldorado

slides (arquivo markdown editável feito com Marp).

Slides: Primeiros passos com o Ansible

Thu, 04 Aug 2022 16:00:00 -0300

Atividade realizada dia 3 agosto 2022, no Eldorado

slides (arquivo markdown editável feito com Marp).

ansible localhost -a "/bin/echo Primeiros passos com o Ansible"

Tue, 12 Jul 2022 10:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 12Jul2022

Lembra quando precisou configurar pela primeira vez seu computador? Possivelmente precisou instalar o git, docker, VSCode, um navegador decente, um shell bacana como o zsh, mó trampo né?

Hoje vamos falar de uma ferramenta de automação de configuração, o Ansible, que permite que a configuração e manutenção dos ambientes seja feita de forma automatizada, poupando bastante tempo.

logo do Ansible

O que é o Ansible? O Ansible é uma ferramenta de automação de configuração e manutenção de ambientes, e atua agilizando e escalando essas atividades.

As principais vantagens do Ansible são sua facilidade de aprendizado, e não ter a necessidade de instalar um agente da ferramenta nas máquinas gerenciadas. A desvantagem acaba sendo que como não existe um agente executando o Ansible este processo não escala bem, ou seja para gerenciar muitos computadores o nó de controle do Ansible precisa ser potente.

Instalando o Ansible

Para instalar o Ansible é necessária a instalação da linguagem python e então basta instalar o executável através do pip install

pip install ansible

Uma funcionalidade que gosto muito no python são os ambientes virtuais (venv), eles são nativos da linguagem e permitem que você possa ter um “ambiente python” diferente para cada projeto, e assim instalar as dependências adequadas de cada projeto sem interferir nos demais.

Normalmente o venv fica dentro da pasta do projeto, e é ignorado no .gitignore. Para criar o venv faça

python3 -m venv venv

Agora toda vez que for utilizar o venv ative com:

source venv/bin/activate

Obs: se estiver usando zsh ou outro shell coloque a extensão do seu shell (no zsh ficaria activate.zsh).

Repare que o prompt (PS1) ficou diferente, contendo o nome do venv (venv).

Para evitar problemas, a primeira vez que crio o venv atualizo o pip e outras ferramentas:

pip install -U pip setuptools wheel

Com venv criado basta só instalar o ansible normalmente (pip install ansible).

Bora testar a instalação? Rode o seguinte

ansible -m ping localhost

Se tiver a seguinte saída significa que deu bom:

[WARNING]: No inventory was parsed, only implicit localhost is available

localhost | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Bora para o hello world?

ansible localhost -a "/bin/echo ola mundo"

[WARNING]: No inventory was parsed, only implicit localhost is available

localhost | CHANGED | rc=0 >>

ola mundo

Como o Ansible funciona?

O Ansible é executado no nó de controle e conecta via o protocolo ssh nos nós gerenciados. Para executar a ferramenta recebe como entrada um arquivo de texto que é o inventário com informações dos nós gerenciados, como os IPs e credenciais. A outra entrada é o playbook, um arquivo no formato yaml, que contém as instruções a serem executadas.

Um requisito para o ansible é que os nós gerenciados precisam do python instalado, porém é possível rodar o ansible de forma limitada para instalar o python para contornar isso ;)

Fonte: twitter.com/scienceshitpost

Montando o inventário

Antes de montar o inventário precisamos de pelo menos uma máquina para conectarmos via ssh, no meu caso utilizei uma raspberrypi e uma máquina virtual. Sem enrolação, vamos ao inventário:

inventario.ini:

[pies]
rpi4 ansible_host=192.168.1.205 ansible_user=piuser ansible_password=pipass ansible_become=yes

[vms]
rockylinux ansible_host=192.168.121.182 ansible_user=rockyuser ansible_password=rockypass

[vms:vars]
ansible_become=yes

[all:vars]
ansible_port=22
ansible_become_method=sudo
ansible_python_interpreter=python3
ansible_become_password="{{ ansible_password }}"

O inventário pode ser escrito no formato ini ou no formato yaml, aqui optei pelo ini.

Nesse exemplo foram definidas duas máquinas a rpi4 pertencente ao grupo pies e rockylinux pertencente ao grupo vms.

E essas variáveis?

ansible_host é o ip ou domínio da máquina.
ansible_port é porta usada pelo ssh, por padrão é a 22, ou seja nem precisaríamos mudar no nosso caso.
ansible_user e ansible_password usuário e senha do ssh utilizados para conectar.
ansible_become indica se deve elevar privilégios ou não, ou seja rodar como usuário root.
ansible_become_method indica o método utilizado para elevar privilégios, aqui estamos utilizando o sudo, mas poderia ser su e utilizar a senha do root.

O inventário pode ser montado de diversas formas e tem várias outras variáveis, consulte a documentação para saber mais: How to build your inventory. Uma coisa que gosto de fazer é utilizar a opção ansible_ssh_common_args com -F ssh_config, onde ssh_config (man page) é um arquivo de configuração do ssh.

As vezes não conseguimos acessar diretamente todas as máquinas, pois é exposto apenas uma máquina, chamada de bastião que atua como proxy para acessar as outras máquinas dentro da rede privada. No ssh_config podemos usar a opção ProxyJump.

Outra vantagem é que fica mais fácil de acessar manualmente uma máquina, basta fazer ssh -F ssh_config nome_maquina e pronto ;)

Bora testar o inventário? Rode

ansible -m ping -i inventario.ini all

Putz, deu ruim, to use the ‘ssh’ connection type with passwords or pkcs11_provider, you must install the sshpass program . Por padrão o ansible conecta autenticando com chaves ssh, não a senha, então precisamos instalar o sshpass. Bastou um sudo apt install sshpass , pra quem tem mac tem um pacote no brew (brew install hudochenkov/sshpass/sshpass).

Agora foi:

rockylinux | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

rpi4 | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Rodando comandos adhoc

Até aqui só fizemos -m ping, mas podemos fazer praticamente qualquer coisa, no ansible as tarefas são executadas através de módulos e vamos mostrar alguns deles aqui.

Caso não seja especificado nenhum módulo o ansible executa por padrão o módulo command, vou executar o comando hostnamectl, que exibe diversas informações do computador:

ansible -i inventario.ini -a hostnamectl all

rockylinux | CHANGED | rc=0 >>

   Static hostname: localhost.localdomain

         Icon name: computer-vm

           Chassis: vm

        Machine ID: 3d137ab51d6c4a1098281d0f08170bce

           Boot ID: 95f4fb49069040b484410562dbbf344c

    Virtualization: kvm

  Operating System: Rocky Linux 8.6 (Green Obsidian)

       CPE OS Name: cpe:/o:rocky:rocky:8:GA

            Kernel: Linux 4.18.0-372.9.1.el8.x86_64

      Architecture: x86-64

rpi4 | CHANGED | rc=0 >>

   Static hostname: rpi4

         Icon name: computer

        Machine ID: 8e5eb04e49a74e26952554ad422b19fb

           Boot ID: 18563abe0fa6420fb55488b28401304e

  Operating System: Debian GNU/Linux 11 (bullseye)

            Kernel: Linux 5.10.0-15-arm64

      Architecture: arm64

Deu bom! Conseguimos visualizar as infos sobre as máquinas. Por curiosidade, qual é desse rockylinux? A redhat descontinuou o centos em dez/2020, que é uma versão gratuita e comunitária do redhat enterprise linux (RHEL) e com o fim do centos dois projetos surgiram como sucessores compatíveis ao centos, o rockylinux e o almalinux.

Bora instalar um pacote como o neofetch? Só mandar um sudo apt install neofetch, certo? No nosso caso uma máquina tem uma distro baseada em redhat ou seja não utiliza o gerenciador de pacotes apt, mas o dnf. Por isso vamos utilizar o módulo package que é genérico e funciona com diversos gerenciadores de pacotes.

xkcd #1654

Vendo a documentação do módulo package, temos 3 argumentos, dos quais apenas 2 são obrigatórios, o nome dos pacotes (name) e o estado (state) como instalado (present) ou removido (absent).

ansible -i inventario.ini -m package -a "name=neofetch state=present" all

rpi4 | CHANGED => {

    "cache_update_time": 1655557364,

    "cache_updated": false,

    "changed": true,

    "stderr": "",

    "stderr_lines": [],

    "stdout": "Reading package lists...\nBuilding dependency tree… [...]

Rodando o neofetch: ansible -i inventario.ini -a neofetch all

Uma opção que facilita muito é a --limit que como o nome sugere limita a execução a algumas máquinas, pode ser especificada múltiplas vezes. Até então utilizamos o all que executa em todas as máquinas. Você pode trocar o all por um grupo(s) ou máquina(s) . E também podemos limitar qual não queremos que sejam incluídas, utilizando o ! como operador de negação.

Por exemplo, queremos reiniciar todas as máquinas, excepto as que pertencem ao grupo vms:

ansible -i inventario.ini -m reboot all --limit !vms

rpi4 | CHANGED => {

    "changed": true,

    "elapsed": 68,

    "rebooted": true

}

Usando o ansible-vault para proteger segredos

Quando criamos o inventário, colocamos as credenciais de acesso, isso não é uma boa prática pois pode acabar expondo essas credenciais. O que podemos fazer nesses casos?

Uma opção simples é tirar as senhas do inventário e digitar apenas quando precisar, utilizando as opções –ask-pass (ou abreviando -k) e –ask-become-pass (abreviando -K).

Mas vamos focar na abordagem do ansible-vault, que funciona como um gerenciador de senhas, onde os segredos ficam armazenados em um arquivo que está protegido por uma única senha.

Para usar o ansible-vault vamos primeiro tirar as senhas do inventário:

inventario.ini:

[pies]
rpi4 ansible_host=192.168.1.205 ansible_user=piuser  ansible_password="{{ rpi4_pass }}"

[vms]
rockylinux ansible_host=192.168.121.182 ansible_user=rockyuser ansible_password="{{ rocky_vm_pass }}"

[all:vars]
ansible_become=yes
ansible_become_method=sudo
ansible_python_interpreter=python3
ansible_become_password="{{ ansible_password }}"

Repare que em ambas as máquinas a variável a ansible_password estão sendo recebidas como referência.

Crie um arquivo que vamos chamar de vault.yml

vault.yml

---
rpi4_pass: 'pipass'
rocky_vm_pass: 'rockypass'

Agora que a mágica acontece, vamos criptografar o arquivo: ansible-vault encrypt vault.yml e digite a senha desejada. Por curiosidade, bora ver o conteúdo do arquivo?

$ANSIBLE_VAULT;1.1;AES256
33303863323038363938333365326637343733313432626231623735666433303965333266383934
6332633534626465353436666539646466633633393362370a353161653663633263663635643466
[...]

Quando precisar editar o vault, basta fazer ansible-vault edit vault.yml

E para carregar os segredos definidos no vault vamos usar a opção –extra-vars (abreviada por -e) onde podemos fazer -e “var=value” mas vamos apontar para um arquivo então -e @vault.yml. E a opção –ask-vault-pass para entrar com a senha do vault

ansible -i inventario.ini -m ping all -e @vault.yml --ask-vault-pass

rockylinux | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

rpi4 | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Preciso digitar a senha do vault toda vez? Não necessariamente, uma abordagem é colocar a senha em um arquivo local e utilizar a opção –vault-password-file , mas sou preguiçoso :P e vou deixar configurado em um arquivo de configuração, o ansible.cfg edai fica tudo setado lá 😊

ansible.cfg

[defaults]
host_key_checking = True
inventory = inventario.ini
vault_password_file = ../.arquivo_com_a_senha.txt

Documentação com todas opções do ansible.cfg: Ansible Configuration Settings

Outra abordagem é a conhecida pela buzzword GitOps, que consiste em rodar o ansible no próprio repositório onde ficam os playbooks do ansible, utilizando um sistema de integração contínua, como github actions que falamos anteriormente aqui. Dessa forma a senha do vault pode ser passada via variável de ambiente e colocada em temporariamente um arquivo ou via argumento do comando.

Escrevendo nosso primeiro playbook

Chegou a hora! Bora escrever nosso primeiro playbook. Para isso vamos subir um servidor web, o apache, para hospedar um site um site estático.

Quando fui instalar o apache no rockylinux deu ruim, porque o pacote no debian é o apache2 mas no rockylinux é httpd. Como faz agora? Como eu faço pro ansible detectar que a máquina é o rockylinux ou debian e tratar adequadamente cada caso?

A ferramenta roda automaticamente um módulo chamado setup que obtém diversas infos das máquinas, e disponibiliza em uma variável chamada ansible_facts.

Fazendo ansible -m setup -e @vault.yml all obtive:

rpi4 | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.1.205"
        ],
        [...]
        "ansible_distribution": "Debian",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/os-release",
        "ansible_distribution_file_variety": "Debian",
        "ansible_distribution_major_version": "11",
        "ansible_distribution_release": "bullseye",
        "ansible_distribution_version": "11",
        "ansible_os_family": "Debian",
        [...]
}

rockylinux | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.121.182"
        ],
        [...]
        "ansible_distribution": "Rocky",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/redhat-release",
        "ansible_distribution_file_variety": "RedHat",
        "ansible_distribution_major_version": "8",
        "ansible_distribution_release": "Green Obsidian",
        "ansible_distribution_version": "8.6",
        "ansible_os_family": "RedHat",
        [...]
}

Com isso, podemos usar a variável ansible_distribution (Debian e Rocky) ou ansible_os_family (Debian e RedHat), optei pela ansible_os_family para que nosso playbook seja mais genérico.

playbook.yml

---
- name: Configura um site estatico.
  hosts: all
  become: true

  vars:
    apache_name_dict:
      "Debian": apache2
      "RedHat": httpd

  handlers:
    - name: restart apache
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: restarted

  tasks:
    - name: Instala o apache.
      package:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: present

    - name: Copia o html da pag.
      copy:
        src: page.html
        remote_src: no
        dest: "/var/www/html/index.html"
        mode: 0664
      notify: restart apache

    - name: Habilita o servico do apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: started
        enabled: true

O playbook funciona da seguinte forma:

Primeiro é instalado o pacote do apache, usando uma variável para mapear o nome correto do pacote.
Copia o html do nosso site, o html precisa estar localizado ao lado do playbook, mas caso o arquivo já estivesse no nó gerenciado basta trocar a opção remote_src para yes.
Habita o serviço do apache para que o mesmo seja iniciado automaticamente quando a máquina é iniciada.

O que é esse notify na task de copiar o html? Pense no seguinte: depois de copiar o html preciso que o apache seja reiniciado para carregar o html da página que acabamos de enviar, mas e se o html que estiver lá não foi alterado? Dessa forma o Ansible só reinicia o apache caso necessário, chamando o handler previamente definido.

Bora escrever sem usar o handler, pra ficar mais claro?

playbook2.yml

---
- name: Configura um site estatico.
  hosts: all
  become: true

  vars:
    apache_name_dict:
      "Debian": apache2
      "RedHat": httpd

  tasks:
    - name: Instala o apache.
      package:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: present

    - name: Copia o html da pag.
      copy:
        src: page.html
        remote_src: no
        dest: "/var/www/html/index.html"
        mode: 0664
      register: html_copy

    - name: restart apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: restarted
      when: html_copy.changed

    - name: Habilita o servico do apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: started
        enabled: true

Nessa versão do playbook, repare que na task de copiar o html estamos fazendo register: html_copy como o nome sugere estamos registrando o resultado daquela task em uma variável. E na task de reiniciar o apache é acionada apenas quando mudou, em when: html_copy.changed.

Para rodar o comando é sugestivo: ansible-playbook -e @vault.yml playbook.yml

Será que o site tá de pé? Abrindo o navegador no ip da VM:

Uma coisa que você precisa ficar de olho quando escreve seus playbooks é se eles são idempotentes, que significa que o efeito de rodar o playbook é o mesmo independente de quantas vezes o mesmo foi executado. Para quem curte linguagens funcionais tá ligado qualé: O playbook não pode ter efeitos colaterais.

Na prática, assim que rodar a primeira vez execute novamente e veja no final se teve alguma task como changed.

O principal desafio para tornar os playbooks idempotentes acontece quando as tasks são do tipo command ou shell, afinal como o ansible vai saber se a task foi executada anteriormente com sucesso?

Nesses casos, uma possibilidade é utilizar o parâmetro chamado creates, disponível nos módulos de command e shell, que aponta para um arquivo marcador que seu shell script ou command precisa criar quando executado com sucesso.

Bora ver na prática?

playbook3.yml

---
- hosts: all
  become: true

  tasks:
    - name: inicializa um arquivo
      shell: echo "passei por aqui" > /etc/marcador_xpto.txt
      args:
        creates: /etc/marcador_xpto.txt

Repare que quando executamos a primeira vez no recap a task foi changed, mas na segunda vez não houve mudanças.

Quem tiver interesse, tem um texto excelente que até saiu no hacker news com várias dicas de como escrever scripts bash idempotentes: How to write idempotent Bash scripts – Fatih Arslan

Conclusão

Uma regra de ouro é: Antes de sair automatizando, primeiro documente o processo manual, quais recursos sua aplicação precisa? Com os recursos disponíveis, como deve ser feita a configuração da aplicação? Dessa forma fica fácil de vislumbrar o todo e não precisa sair caçando nos códigos. Apesar do manifesto ágil dar preferência a ter um software funcional a documentação abrangente, sugiro não deixar de documentar no início essas definições.

Para aprender ansible, a melhor referência é o livro do Jeff Geerling, Ansible for DevOps o livro tem vários exemplos e dicas. Pra quem prefere o formato de vídeos, no início da pandemia o autor trouxe o conteúdo do livro em forma de lives: Ansible 101 playlist. E pra quem prefere ir direto nos códigos os exemplos estão disponíveis nesse github: github.com/geerlingguy/ansible-for-devops

Obrigado por acompanhar esse texto, espero que te ajude, caso tenha algum feedback ou dúvida não hesite em entrar em contato.

Como contêineres funcionam?

Wed, 19 Jan 2022 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 19Janeiro2022

Existe muito ~~hype~~ quando o assunto é contêineres e Kubernetes, isso acaba gerando uma expectativa e confusão do que são e como funcionam essas tecnologias.

Hoje vamos falar o que de fato é um contêiner, como funciona e se cria um contêiner do zero (sem o docker).

Foto de ines mills, unsplash

O que é um contêiner?

Um contêiner é um processo rodando no kernel linux. E esse processo é isolado dos outros processos/contêineres e do host (através de features do kernel).

Essa é a principal diferença dos contêineres para máquinas virtuais (VM). Todos os contêineres compartilham o mesmo kernel, no passo que cada VM tem seu kernel.

Mas se é um kernel linux, como funciona quando uso o docker no Windows ou Mac? No fundo no Windows (mesmo WSL) e Mac tem uma máquina virtual rodando o linux.

E quais são essas features do kernel que fazem tudo isso acontecer? Vamos falar delas nesse texto.

Namespaces

Namespaces controlam o que um processo/contêiner consegue ver, existem atualmente os seguintes namespaces:

Processes ID (pid)
mount points (mnt)
Network (net)
IDs do usúario e group (user)
Interprocess communication (ipc)
Control Group (cgroup)
Unix Timesharing System (uts), apesar do nome complicado, representa o hostname e domínios.

/proc

O procfs (montado em /proc) é um tipo de filesystem especial, nele existem diversas informações do sistema como CPU, memória e principalmente os processos.

Se quiser entender como ler as infos do /proc, veja em man proc.

Para que os processos do host ficarem isolados do contêiner, o contêiner precisa ter um /proc próprio (além de um namespace pid).

chroot

Para que o contêiner não acesse os arquivos do host, o chroot (change root directory) faz com que o contêiner só consiga acessar um diretório do host.

Por exemplo, se fizermos um chroot /mnt/root, um arquivo em /mnt/root/arq1.txt no host será apenas /arq01.txt no chroot. Neste chroot só consegue acessar o que está em /mnt/root

Control groups (cgroup)

:(){ :|:& };:

Provavelmente é a forkbomb mais conhecida. Uma forkbomb é um ataque que quando executada são rapidamente criados muitos processos que que se multiplicam exponencialmente incapacitando totalmente o computador, sério! Só tirando da tomada pra conseguir parar.

Precisamos de uma forma de limitar quantos recursos um determinado contêiner consegue utilizar. Os control group (cgroup) limitam os recursos como CPU, memória, rede que cada contêiner pode utilizar.

Demo: Criando um contêiner do zero

Bora criar nosso contêiner sem usar o docker! Antes de tudo precisamos instalar o que vamos precisar:

sudo apt install debootstrap cgroup-tools util-linux

Primeiramente vamos criar uma instalação base do debian, para que o que fizermos no contêiner não contamine nossa máquina (o host), rode o seguinte no terminal:

sudo debootstrap bullseye ./deb11-rootfs https://deb.debian.org/debian/

O comando acima vai criar uma instalação do Debian 11 (bullseye) na pasta deb11-rootfs.

Agora vamos criar um cgroup

export cgroup_name="cg_$(shuf -i 2000-3000 -n 1)"
cgcreate -g "cpu,cpuacct,memory,pids:$cgroup_name"

Colocando limites no cgroup:

cgset -r cpu.shares=256 "$cgroup_name"
cgset -r memory.limit_in_bytes=100M "$cgroup_name"
cgset -r pids.max=100 "$cgroup_name"

Então nosso cgroup vai ter no máximo 100MB de RAM, 1/4 de cpu (256/1024 shares) e 100 processos simultâneos então uma forkbomb vai ser contida.

É agora, bora disparar um contêiner nesse cgroup:

cgexec -g "cpu,cpuacct,memory,pids:$cgroup_name" \
    unshare --fork --mount --uts --ipc --pid --mount-proc \
    chroot "./debian11-rootfs" \
    /bin/sh -c "/bin/mount -t proc proc /proc && hostname container && /bin/bash"

Calma, muita coisa ao mesmo tempo, vamos rodar o unshare no cgroup, o unshare vai criar os namespaces que queremos (uts, ipc e pid), então fazer um chroot no debian, montar um /proc próprio, mudar o hostname para contêiner e abrir um shell bash.

Sucesso! Temos um contêiner! O que vamos fazer?

Vamos ver que o contêiner não consegue ver os processos do host, faça ps aux (para listar os processos) e veja que são apenas listados os processos do contêiner, isso aconteceu porque o contêiner está num namespace pid (veja –pid no unshare e um /proc próprio).

Mas o host consegue ver o contêiner, faça sleep 1000 no contêiner e no host faça ps aux | grep 'sleep 1000', o host consegue ver todos os contêineres, repare que os mesmos processos no host tem um pid enquanto no contêiner tem outro PID.

Veja que o contêiner só consegue enxergar seus processos, ao passo que o host (parte inferior) consegue ver os processos do(s) contêiner(s), veja também que o processo bash no contêiner tem PID 4 enquanto no host 12885.

Faça cat /proc/self/cgroup no contêiner e compare com o host, esse arquivo lista os cgroups do processo, repare que os cgroup pids,memory,cpu,cpuacct são o cgroup que criamos.

No host vá em /sys/fs/cgroup/ e navegue por exemplo em pid/nome_do_cgroup veja que tem vários arquivos informando infos e limites como pids.current e pids.max.

Por fim vamos testar esses limites, no contêiner instale o python (apt update && apt install python3) então abra o python e faça vet = int(1e9)*[None], tentamos alocar um vetor com 1 bilhão (1e9) valores, apareceu o Killed. O que aconteceu? No host faça dmesg (que exibe mensagens do kernel) e veja que o kernel (out of memory (oom)) matou processo pois ele passou do constraint.

Para facilitar coloquei os comandos que usamos para criar um contêiner em um script:

#!/bin/bash

if [ $USER != 'root' ]; then
    echo "esse script deve rodar como root, rodeo novamente com sudo"
    exit 1
fi

echo "script para demonstrar como containers funcionam (namespaces, cgroups, chroot)"

# instala dependencias, caso nao tenha instaladas descomente
echo -e "instalando as dependencias necessarias (debootstrap cgroup-tools util-linux)\n"
sudo apt update && apt install debootstrap cgroup-tools util-linux

# cria a raiz de uma instalação debian na pasta debian11-rootfs
# descomente caso nao tenha feito ainda
if [ ! -d "./debian11-rootfs" ]; then
    echo -e "\n\ninstalando o debian 11 (bullseye) na pasta debian11-rootfs\n"
    debootstrap bullseye ./debian11-rootfs https://deb.debian.org/debian/
fi

echo "criando o cgroup: "

# cria um numero aleatorio entre 2000~3000 para ter cgroup unico
cgroup_name="cg_$(shuf -i 2000-3000 -n 1)"

cgcreate -g "cpu,cpuacct,memory,pids:$cgroup_name"

cgset -r cpu.shares=256 "$cgroup_name" # 0.25 cpu
cgset -r memory.limit_in_bytes=100M "$cgroup_name" # limite de 100MB RAM
cgset -r pids.max=100 "$cgroup_name" # no maximo 100 procesos simultaneos (forkbomb prevetion)

echo -e "\n\ncgroup criado, seu nome eh: $cgroup_name"
echo -e "iniciando o container, divirta-se\n"

# calma, muita coisa ao mesmo tempo: usa o cgroup que acabamos de criar (cgexec),
#     cria namespaces novos (unshare), faz chroot e muda o hostname do container

cgexec -g "cpu,cpuacct,memory,pids:$cgroup_name" \
    unshare --fork --mount --uts --ipc --pid --mount-proc \
    chroot "./debian11-rootfs" \
    /bin/sh -c "/bin/mount -t proc proc /proc && hostname container && /bin/bash"

Overlay filesystems

No nosso exemplo usamos uma instalação do debian como filesystem, dessa forma cada contêiner precisaria ter sua própria instalação, gastando muito espaço de disco (sem aproveitar o que é comum).

Os filesystem overlay permitem que contêineres diferentes aproveitem o mesmo espaço em disco. Isso acontece através das camadas que são reutilizadas e empilhadas para criar o filesystem final de cada contêiner.

Fonte

Na figura acima temos uma visualização bacana, partimos de uma instalação do sistema operacional Ubuntu, então é instalado o java e por fim são copiados os binários da aplicação elasticsearch essa é a imagem 1 (representada na 3a camada b108…). A imagem 2 são adicionados arquivos de configuração e por fim definidas algumas variáveis de ambiente.

Cada passo é uma camada (representada à direita), aproveitando aquela ação para outras imagens que usam aquilo como base.

Features de segurança

Capabilities, seccomp e apparmor são features de segurança para restringir o que os contêineres podem fazer, vamos falar brevemente delas a seguir:

Capabilities: São permissões especiais que permitem processos fazer determinadas ações. Por exemplo cap_net_bind_service permite usar portas privilegiadas (<=1024). As capabilities surgiram para dar permissões mais granulares aos programas, antes delas essas ações só eram permitidas para o root.
seccomp-bpf: Define quais chamadas de sistema (syscalls) são permitidas.
AppArmor ou SELinux: São sistemas concorrentes normalmente distribuições baseadas no RedHat (como fedora) usam o SELinux enquanto distros baseadas no Debian (como Ubuntu, linux mint e pop-os) usam o AppArmor. Eles tem um perfil que define quais arquivos podem ser acessados (ou não) e quais capabilities são permitidas.

Quem faz tudo isso acontecer?

Quem já usa docker não precisa criar os namespaces, cgroups etc … que falamos aqui, então quem faz isso? O docker? Quem se ocupa disso são os contêiner runtime.

Fonte

O diagrama acima mostra como tudo se relaciona, ao longo dos anos foram sendo criadas interfaces padronizadas, primeiramente a OCI (open containers iniciative) em jun/2015 e nasceu o runc. Depois foi criada a CRI (contêiner runtime interface) em Dez/2016 e nasceu o containerd.

Essas interfaces foram criadas principalmente por causa do Kubernetes, e com elas sendo padronizadas esses componentes podem ser substituídos facilmente. Por exemplo, se não quiser usar o containerd você pode usar uma alternativa mais leve como o cri-o.

Lembra em 2020 que na versão 1.20 do Kubernetes que o docker não ia ser mais suportado? Isso aconteceu porque o Kubernetes interagia com o docker de uma forma não padronizada. O dockershim não era a interface padronizada CRI, então o Kubernetes tinha que manter duas implementações separadas. Mais detalhes aqui: Não entre em pânico: Kubernetes e Docker

Tem uma talk legal que conta a história dessas interfaces: Below Kubernetes: Demystifying container runtimes

Rootless

Por padrão o docker daemon (e o containerd) roda como root no host, caso um contêiner consiga escapar o isolamento isso vai comprometer totalmente o computador host.

Uma vulnerabilidade grave no runc foi a CVE-2019-5736 que permitia um contêiner escapar e ter acesso root no host.

Rootless roda o docker (e os runtimes) como um usuário não root, trazendo um avanço significativo de segurança.

Até então o modo rootless no docker era experimental, mas na versão 20.10 (lançado em dez/2020) virou estável.

Um site ótimo que fala sobre contêineres rootless é o rootlesscontaine.rs, ele explica como tudo funciona e as instruções de como usar.

Conclusão

turnoff.us/geek/linux-containers/

Vimos as primitivas do kernel Linux que fazem os contêineres funcionarem e as diferenças com máquinas virtuais, quem se interessou e quiser aprender mais vou deixar algumas referências.

Pra quem tá começando recomendo os seguintes materiais:

docker-curriculum.com: É um tutorial bem prático e completo.
Descomplicando Docker: Curso do LINUXtips em português brasileiro, a LINUXtips tem vários cursos excelentes de Devops.
Docker Mastery: É o curso que mais gosto ;) ele é bem completo e passa várias dicas para depurar os contêineres e ainda faz uma breve introdução sobre orquestração de contêineres (docker swarm e kubernetes).

Para montar esse texto usei o livro da Liz Rice: Container Security: Fundamental Technology Concepts that Protect Containerized Applications, é bem completo e quem curte segurança vai adorar. A mesma autora tem uma talk legal Building a conteiner from scratch in Go.

Slides: Como contêineres funcionam? parte 1

Wed, 05 Jan 2022 16:00:00 -0300

Atividade realizada dia 5 janeiro 2022, no Eldorado

slides (arquivo markdown editável feito com Marp).

Slides: Como operar uma infra on premisses

Wed, 15 Dec 2021 08:00:00 -0300

Atividade realizada dia 15 dezembro 2021, no Eldorado

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Termux: Um terminal linux no seu Android

Fri, 10 Sep 2021 14:00:00 -0300

Originalmente publicado no portal embarcados dia 8 setembro de 2021, com apoio dos colegas do instituto Eldorado.

Hoje vamos falar do termux: um app open source para android que traz um terminal completo Linux com diversas possibilidades e facilidades, como fazer backups dos arquivos do Android e programar com python 🤓

Instalando o app: O que é a Fdroid?

O termux atualmente está apenas disponível na Fdroid, não é possível instalar a versão mais recente na play store. Mas afinal o que é a Fdroid?

Logo da Fdroid

A Fdroid é uma loja de apps para Android, tipo a Play Store, mas apenas com apps software livre/open source. Atualmente existem mais de 3 mil apps oferecidos lá, dê uma olhada se tem algum que te interesse.

Para usar a Fdroid basta ir no site fdroid.org clique em download e instale o apk.

Com a Fdroid instalada, busque pelo termux e instale-o de lá, a Fdroid periodicamente vai procurar por atualizações dos seus apps.

Instalei o Termux, e agora?

Com o termux instalado, podemos instalar alguns pacotes. Para fazer isso basta usar o comando pkg igual faria com apt ou apt-get (não precisa de sudo).

Então antes de tudo vamos atualizar os repos, para isto execute a seguinte linha de comando: pkg update .

Espere terminar e aceite atualizar os pacotes.

Agora vamos instalar o neofetch usando a linha de comando: pkg install neofetch.

Por fim rode o neofetch, ele exibirá o logo do Android (que no caso é a nossa “distro” Linux) e diversas informações como número de pacotes instalados, qual kernel, etc.

Créditos: @anubhavitis

Acessando remotamente o celular com ssh

Como o teclado e a tela do celular são pequenos, uma possibilidade seria usar um teclado externo bluetooth ou conectado no cabo OTG. Outra abordagem possível é acessar remotamente o termux via ssh com um computador na mesma rede. Para isto:

Instale o openssh: pkg install openssh
Crie uma senha para logar com o comando: passwd
- Digite a senha 2 vezes (é normal não aparecer nada enquanto digita a senha).
Inicie o servidor ssh com o comando: sshd
Descubra o IP do android: na cortina de notificações pressione e segure o ícone do WiFi, clique na rede conectada, avançado, e o seu endereço IP será apresentado no formato 999.999.9.9999
Agora no computador dispare o ssh no IP, porém na porta 8022 usando o comando: ssh <user>@<endereco_IP> -p 8022 . E digite a senha que configurou antes, para quem está no Windows uma possibilidade é instalar o WSL e ter um linux dentro do Windows ou usar o MobaXterm.

Prontinho! Agora é possível acessar remotamente o termux no computador via ssh. Porém logo vai perceber que o terminal começa a ficar lento, ou congela e as vezes volta. Isso acontece porque o Android está com a tela apagada e entrando num modo de “economia de energia”, nesses casos temos a opção do termux usar wakelocks para prevenir que o Android suspenda, isso vai consumir mais bateria mas se tudo bem basta abaixar a cortina de notificação e clicar em acquire wakelock.

Dica 1: O seu roteador WiFi provavelmente atribui os endereços dos dispositivos de forma sequencial, ou seja, pode ser que o IP do Android amanhã não seja mais aquele que vimos anteriormente. Vá na configuração do seu roteador e reserve um IP fixo para o Android. Segue abaixo a opção em um roteador D-Link:

Dica 2: Criando um alias no ssh: toda vez que vamos acessar o android temos que digitar tudo isso: ssh <user>@<endereco_IP> -p 8022, vamos criar um apelido que simplifica o comando para: ssh android . No computador edite o arquivo ~/.ssh/config colocando o seguinte:

Host android
  HostName <endereco_IP>
  User user
  Compression yes
  Port 8022

Instalando o python e jupyter notebook 🤯

Podemos instalar no nosso android um ambiente de computação científica python para fazer análises, testar coisas e levar pra onde quisermos. Para isto, basta executar as seguintes linhas de comando no termux:

pkg install python build-essential libzmq freetype libjpeg-turbo libpng
python3 -m venv venv
source venv/bin/activate
pip3 install -U pip wheel setuptools
pip3 install jupyter

Estas linhas de comando instalam o python e algumas dependências necessárias para instalar as bibliotecas do python. Em seguida, foi criado um “ambiente virtual” (venv) que permite instalar nossas bibliotecas de forma separada, para ter um ambiente python separado para cada projeto. Toda vez que quisermos usar o venv é necessário executar source venv/bin/activate, responsável por ativar o venv no shell atual do termux(linha 3). Nas linhas seguintes, 4 e 5, atualizamos nossas ferramentas do python (pip, wheel e setuptools) e por fim, instalamos o jupyter notebook.

jupyter notebook é iniciado com:

jupyter notebook --ip=0.0.0.0

Coloque o link no navegador e substitua pelo IP do android e pronto, tudo funcionando:

Sucesso! O jupyter notebook já está funcionando perfeitamente. É esperado que a instalação de pacotes python, como o numpy (usando o comando pip install) demore mais do que em uma máquina Linux convencional. Por que? O python distribui suas bibliotecas com os wheels que são pacotes pré-compilados mais rápidos de serem instalados, porém os wheels foram gerados para a arquitetura de processadores x86_64 e estamos usando um processador arm no nosso android então temos que compilar tudo. Outra coisa é que além da arquitetura os wheels são gerados para uma determinada biblioteca padrão a glibc mas o android usa outra libc, a bionic. Na wiki do termux tem uma pagina com todas as diferenças de uma maquina linux convencional: https://wiki.termux.com/wiki/Differences_from_Linux

Acessando os arquivos do celular

Podemos acessar as fotos e outros arquivos do celular pelo termux executando o comando: termux-setup-storage. É necessário permitir o acesso de arquivos pelo app. Podemos ver quais pastas estão consumindo mais espaço:

cd /sdcard
du -shxc * | sort -rh
4.0G	total
2.0G	DCIM
828M	Android
704M	Pictures
231M	Telegram
213M	syncthing
103M	Download

O comando acima (du) lista o espaço utilizado por cada pasta e em seguida pegamos sua saída para o comando sort através do | (chamado de pipe), para ordenar de forma decrescente. Outro comando interessante é o df que exibe o uso de disco de cada “partição” e quanto está livre.

Outra coisa legal de fazer agora que estamos acessando os arquivos do celular é deletar fotos (ou arquivos) de forma segura. Quando deletamos um arquivo, este não é removido de fato, simplesmente o espaço daquele arquivo é marcado como livre, dessa forma é possível recuperar arquivos deletados. Então para deletar um arquivo de forma segura temos que sobrescrever o conteúdo do arquivo com “lixo” para que o conteúdo original não seja recuperado, para fazer isso temos o comando shred, basta executar: shred -u <nome_arquivo>, como por exemplo:

shred -uv IMG_20210416_103105401.jpg

Outro comando, mais completo que o shred é o srm. Para instalar execute pkg install secure-delete. Ele permite deletar diretórios de forma recursiva e outras opções não presentes no shred.

Sincronizando arquivos com o PC

O protocolo ssh além de permitir acessar remotamente o Android, permite transferir arquivos. O comando que faz essa cópia é o scp, para copiar um arquivo basta executar no terminal do PC: scp arquivo.jpg user@<endereco_IP>:/sdcard/DCIM/, com o usuário, IP e caminho de destino.

Outro comando muito usado para essa tarefa é o rsync, ele permite sincronizar pastas entre o Android e o PC. Enquanto o comando scp vai “re copiar” todas as fotos para o PC, o rsync vai copiar apenas as novas e o que mudou, sendo na maioria das vezes mais eficiente. Primeiro vamos instalar o rsync no termux (o rsync precisa estar instalado tanto no PC quanto no android):

pkg install rsync

O rsync oferece várias opções, mas nesse caso o importante é: rsync -avh -P user@<endereco_IP>:/sdcard/DCIM/ fotos_celular/. Na primeira vez que for executado, esse comando vai copiar todas e fotos para o PC, e das próximas vezes copiará somente o que mudou.

Por fim vou indicar um app ótimo para sincronizar os arquivos entre o celular e pc: o syncthing.net, tem na Fdroid e com ele é possível fazer backup de todos meus arquivos do Android no PC.

Alguns apps para terminal

Para quem vive no terminal tem alguns apps que ajudam a realizar algumas tarefas e para quem não usa muito a interface gráfica.

Analisador de espaço: o ncdu. Da mesma forma que usamos o du para ver quais pastas estão usando mais espaço, o ncdu faz a mesma coisa, mas permite navegar de forma rápida e deletar os arquivos/pastas para liberar espaço.

Para navegar nas pastas temos o ranger: um gerenciador de arquivos como o explorer do Windows ou nautilus no Linux (gnome).

Por fim, um agregador de feeds RSS: o newsboat, o qual permite acompanhar os feeds RSS:

Feed do Computando Arte – Medium

Considerações finais

Neste texto tentei mostrar para nosso leitor sobre o que dá para fazer com termux e um terminal linux, ilustrando sobre como realizar as tarefas apenas no terminal. Para quem gostou do conceito de acessar remotamente os apps e arquivos, mas achou android um pouco lento, confira esse blogspot da linuxserver.io sobre a imagem webtop que fizeram: linuxserver.io/blog/2021-05-05-meet-webtops-a-linux-desktop-environment-in-your-browser fornecendo uma alternativa mais rápida.

Primeiros passos com self-hosting

Sun, 04 Jul 2021 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 05Julho2021

Neste post vamos fazer uma visão geral das principais partes do self-hosting.

Foto de Jainath Ponnala, unsplash

Vai usar a nuvem? Ou apenas on-premise? Que tal ambos?

Acredito que umas das primeiras considerações quando montamos nosso setup de self-hosting é pensar como isso vai se organizar e onde vai ficar cada coisa.

Self-hosting não é ser “contra a nuvem” mas sim um movimento para ter controle dos nossos dados e aplicações que usamos, mesmo usando a nuvem nós que vamos configurar tudo e ter controle de como cada coisa funciona.

Outro modelo é hospedar “tudo em casa” (chamado de on-premise), funciona muito bem. Mas um desafio que logo vamos abordar é abrir a conexão da sua operadora para acessar seus serviços fora de casa.

Daí surge um terceiro modelo: o híbrido, parte das coisas que necessitam de velocidade ficam em casa e o restante que precisa acessar fora de casa na nuvem. No meu caso, coloco na nuvem (uma virtual private server (VPS) da digital ocean) o nextcloud com apenas meus contatos e calendário (no android uso o davx5 para sincronizar a agenda e os contatos com o nextcloud) e em casa guardo meus backups (com uma cópia no rsync.net) e todo resto :P

Além de ser muito bonito e divertido de fazer, recomendo fazer um diagrama de como vai se organizar suas aplicações e dispositivos, acima é como organizo tudo.

Hardware usado para hospedar

Para hospedar nossas coisas em casa, precisamos de um hardware para fazê-lo, pode ser usado com computador velho ou, outras opções populares, são usar a Raspberry Pi, mini pc (tipo intel NUC) ou por fim um servidor de armazenamento conectado em rede (NAS, de Network Attached Storage). Embora seja uma melhor opção pelo reuso e sobrevida de um equipamento obsoleto, é importante ficar ciente e atento a falhas por fadiga que podem comprometer a disponibilidade ou a confiabilidade do serviço.

Quando eu comecei nessa jornada do self-hosting, havia comprado um SSD para meu notebook então peguei o disco que veio nele e conectei numa Raspberry Pi. Começar com uma Raspberry Pi é ótimo: é barato, consome pouca energia e atende aos requisitos de recursos de várias aplicações.

Mas existem outras necessidades que uma Raspberry Pi não consegue atender, como por exemplo rodar máquinas virtuais, e daí surge a necessidade de outros hardwares apropriados. Como um mini-pc (ou Intel NUC) que é literalmente um mini pc e os componentes tradicionais como processador x86 (ao invés do ARM do Raspberry Pi), slots de memória RAM que pode ser trocada, etc.

NAS Synology DS920+

Quer armazenar muitos arquivos? Talvez um NAS seja mais adequado. Este equipamento conta com conexão à rede e diversos slots para colocar os discos.

Por fim, um item de hardware que é opcional mas recomendo é um “no break”, para que em caso de cair a energia na sua casa não aconteça nada.

Storage e backups

Tudo, inclusive toda forma de tecnologia, está sujeita a falhas, mas enquanto peças podem ser substituídas, arquivos perdidos podem não serem recuperáveis, por isso surge a necessidade de cópias de segurança, os famosos backups. A regra de ouro é quanto mais importante, raro ou caro mais versões e de mais difícil acesso elas devem ser.

Isso é uma consideração importante principalmente com a Raspberry Pi, os SD cards não são muito confiáveis, depois de alguns anos de uso eles acabam “morrendo”. Comigo foi muito nítido isso, teve um SD card que me serviu fielmente por 2 anos, enquanto outros logo depois de 1 ano de uso contínuo eles morreram. Mesmo adotando alguns truques para diminuir sua leitura e escrita, como montar com a flag noatime, os logs e outras pastas como tmpfs e desativar o swap.

Outra preocupação com os backups são os ataques ransomware, se seu computador teve os arquivos sequestrados, depois de sincronizar os backups também podem estar comprometidos. Por isso é aconselhável ter backups versionados, no qual teremos um “histórico” dos arquivos e no caso de um ransomware, basta restaurar a penúltima versão dos backups no qual os arquivos originais estarão lá.

Uma prática indispensável quando falamos de storage é o Redundant Array of Independent Disks (RAID: Arranjo redundante de discos baratos) que permite combinar os discos para que o sistema operacional os enxergue tudo como um disco só. Os dois modos mais básicos são o RAID 0 e RAID 1. No RAID 0 temos 2 discos que vão somar suas capacidades, enquanto no RAID 1 teremos a capacidade de apenas 1 disco e outro é usado como redundância caso um disco falhe, bastando trocar o disco quebrado que os dados serão espelhados nele.

Existem outros níveis de RAID, que são no fundo combinações do 0 e 1, como o RAID 5 (no qual teremos 4 discos, mas apenas podendo utilizar apenas o espaço de 3, pois 1 drive é usado como redundância).

A fim de combinar os discos utilizando o RAID temos diversas implementações que podem ser usadas no Linux. A mais simples é o mdadm que mapeia os drives num “disco virtual”.

Outra solução um pouco mais avançada é utilizar o LVM que é um gerenciador de volumes que permite coisas mais avançadas como diminuir e aumentar as partições usadas e realizar snapshots, que é um “retrato” do sistema de arquivos que pode ser acessado depois, dessa forma criando um “ponto de restauração”.

Por fim os sistemas de arquivos recentes como BTRFS e ZFS podem ser usados RAID e tem recursos legais como os snapshots, compressão nativa dos arquivos (dessa forma aqueles arquivos de texto como dados em csv ficam bem menor) e por fim como esses sistemas de arquivos usam o conceito de copy-on-write ou seja para toda escrita será feita uma cópia para manter a versão anterior, isso permite que para realizar a manutenção dos disco (o fsck, a checagem da integridade do sistema de arquivos) não precise desligar tudo (nesses sistemas o equivalente do fsck é o scrub).

A única ressalva para usar o ZFS e BTRFS são bancos de dados, o copy-on-write nos bancos de dados prejudica o desempenho, nesses casos talvez seja uma boa manter o sistema operacional num sistema de arquivos tradicional como ext4 e os bancos de dados nele e o armazenamento restante no ZFS ou BTRFS.

Outra preocupação é a criptografia dos discos, para proteger os arquivos em caso de furto, nesses casos é uma boa instalar o pacote dropbear-initramfs (tutorial) que permite entrar com a senha da criptografia de forma remota (por ssh), sem precisar ter um teclado in loco.

Fonte: https://twitter.com/nixcraft/status/1313909322905083905

Uma regra de ouro dos backups é a regra 3-2-1, que diz que devemos ter ao menos 3 cópias, em 2 mídias diferentes e 1 “fora de casa” em caso de incêndio. Para ter esse backup fora de casa é mais prático usar a nuvem, mas como utilizar a nuvem de forma segura? Podemos utilizar uma solução de backup que tenha criptografia, como o borgbackup, outra opção para utilizar o Google Drive, Dropbox e similares é utilizar o cryptomator.org que criptografa seus dados antes de enviá-los para a nuvem.

Partindo para as indicações, veja o vídeo do Fabio Akita: Quebrei 3 HDs: Entendendo Armazenamento explicando como os discos rígidos funcionam. E o meu texto de como montei minha solução de backups criptografados com o borgbackup e syncthing no Android: Como parei de me preocupar e passei a adorar minha solução de backups.

Como acessar meus serviços fora de casa?

Em algumas operadoras como a NET, seu modem tem um IP “interno” dentro da rede da operadora, pois os IPs IPV4 são muito escassos, o famigerado Carrier-grade NAT (CGNAT), dessa forma não é possível acessar sua casa através da internet.

Explicação sobre o NAT (fonte)

O único jeito é ligar na operadora e pedir para sair do CGNAT, permitindo assim hospedar na internet seus serviços. Foi o que fiz (tenho NET), mas não consigo abrir algumas portas como a 80 (http) e 443 (https), pois na NET isso só é permitido comprando o plano para empresas 😞

Pesquise e pergunte no /r/InternetBrasil, lá tem muito conteúdo sobre isso.

Outra questão é que os IPs não são fixos. Dentro da sua casa, quando a Raspberry Pi liga ela “pede” um IP pro seu roteador, o Dynamic Host Configuration Protocol (DHCP) que atribui um IP para a Raspberry Pi, mas os IPs muitas vezes são alocados de sequencial, ou seja nem sempre a Raspberry Pi vai ter o mesmo IP, quebrando o encaminhamento de portas do roteador. Então no roteador na configuração do DHCP atribua um IP fixo para a Raspberry Pi.

Outro IP que não é fixo é o do seu modem, que é o seu IP público na internet, infelizmente às vezes ele acaba mudando (de novo no plano para empresas o IP é fixo), daí surgem os serviços de DNS dinâmico, como o DynDNS ou NOIP, eu utilizo o duckdns e no google domínios tem a opção de DNS dinâmico.

A partir daí é só fazer os encaminhamentos de portas no seu modem, evite a opção DMZ, que expõe completamente a Raspberry Pi na internet, encaminhe apenas as portas que realmente precisa expor. Outra opção é ter um roteador próprio, e o usar o modem da operadora apenas como modem colocando no modo bridge e o seu roteador vai atuar como firewall encaminhando apenas algumas portas. Eu faço isso com meu roteador usando o OpenWRT e criei algumas VLANs (redes lógicas separadas para segregar os equipamentos) para minha rede.

Diagrama do proxy reverso (ngrok)

Outra opção é utilizar um serviço de proxy reverso, que basicamente torna seu localhost público, como ngrok, ou a solução open source pagekite.

Na mesma linha pode ser utilizada a sua VPS na cloud como proxy para acessar suas coisas em casa, pode ser algo simples como o autossh que cria tunnels ssh permitindo acessar sua casa passando pela VPS.

Ou criar uma VPN com wireguard na sua VPS e conectar sua Raspberry Pi, viabilizando seu acesso externo. O legal dessa solução é que você pode criar duas configurações no seu computador/celular: uma que usa a VPN apenas para acessar seus serviços e uma que passa todo seu tráfego pela VPN para usar em WiFis não confiáveis como WiFis públicos.

Por fim, outra possibilidade é usar o Tor, para criar um .onion que permite hospedar seus serviços em casa, sem precisar abrir suas portas, veja a documentação: onion-services.

Uma preocupação em expor seus serviços na internet é a de segurança, pois os mesmos podem ser hackeados e o hacker estará na sua rede. Isso pode ser feito de forma segura adotando as medidas de segurança que falaremos, mas outra possibilidade é utilizar o port knocking, no qual as portas dos seus serviços ficam fechadas e depois de “bater” numa sequência de portas corretas (tipo uma senha) a porta é aberta, apenas para o IP, e por um período de tempo, escondendo e protegendo seus serviços. Utilizo o knockd com o firewall ufw.

Contêiners

Os contêineres vieram para ficar e são uma maneira simples e rápida para colocar seus serviços no ar. Mas é preciso tomar cuidado em usar apenas imagens confiáveis, no fundo você está rodando um software feito por um terceiro na sua máquina.

Foram encontradas imagens maliciosas minerando bitcoin, ou imagens desatualizadas e vulneráveis. Antes de utilizar uma imagem dá uma olhada no Dockerfile no github para procurar por coisas suspeitas.

Imagens oficiais do dockerhub são confiáveis, outra fonte excelente de imagens é o LinuxServer.io com diversas imagens ótimas.

Partiu para as indicações? Tem um site excelente para aprender docker, bem direto ao ponto o docker-curriculum.com, curso eu indico o docker-mastery na udemy que até fala um pouco de clusters com docker swarm e kubernetes, por fim no youtube tem o vídeo excelente da TechWorld with Nana Docker Tutorial for Beginners.

Proxy Reverso

Quando vamos hospedar diversos serviços uma construção comum que é utilizada é o proxy reverso, com ele quando vamos acessar nossos serviços evitamos de ter que usar uma porta diferente para cada coisa, dessa forma podemos configurar o proxy reverso para como cada serviço vai ser acessado, normalmente por um subdomínio tipo nextcloud.seu-dominio.tld ou como uma subpasta seu-dominio.tld/nextcloud.

Ilustração de um proxy reverso

As opções mais populares são o Secure Web Application Gateway (swag), da linuxservers.io, que é um nginx, com let’s encrypt (para ter o https) e fail2ban (que bloqueia bots e IPs que estão tentando te invadir).

A outra opção é o traefik que tem a vantagem de já ser integrado com o docker e kubernetes, dessa forma ao invés de configurar as “rotas” de cada serviço em arquivos de configuração (como é feito no nginx) as configurações vivem nos labels do contêiner de cada serviço, muito mágico ✨

Aliado com o proxy reverso, podemos utilizar o authelia, que permite ter o mesmo usuário e senha (single sign-on) sincronizado com todos seus serviços e autenticação em 2 fatores integrada em todos seus serviços, tornando tudo mais prático e seguro.

Bora para um exemplo?

version: "2.1"

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=PathPrefix(`/whoami/`)"
      - "traefik.http.routers.whoami.entrypoints=web"

  bitwarden:
    image: bitwardenrs/server
    container_name: bitwarden
    restart: unless-stopped
    #environment: 
    #- SIGNUPS_ALLOWED=false
    volumes:
      - ./docker_vols/bwdata/:/data/
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.bitwarden.rule=PathPrefix(`/vault/`)"
      - "traefik.http.routers.bitwarden.entrypoints=web"
      - "traefik.http.middlewares.bw.stripprefix.prefixes=/vault/"
      - "traefik.http.routers.bitwarden.middlewares=bw"

Esse é um arquivo docker-compose, é um arquivo yaml que define vários contêineres, no fundo é como se o fizesse vários docker run, um para cada contêiner.

Para executá lo, basta baixar esse arquivo como docker-compose.yml e rodar o docker-compose up -d

Temos 3 contêineres definidos: o traefik, o whoami (usado para debugar o traefik) e o bitwarden (gerenciador de senhas). Repare como as “rotas” para o traefik estão definidas nos labels de cada contêiner ✨

Espere um pouco e vamos testar tudo: abra seu navegador no endereço localhost/whoami/ , e veja a rota para o whoami funcionando. Depois vá para localhost/vault/ e acesse o bitwarden. Por fim localhost:8080 e veja o dashboard do traefik (não se esqueça de colocar uma senha depois).

No bitwarden, repare na parte volumes, aqui os dados da aplicação serão salvos na pasta docker_vols/bwdata, para ser feito o backup.

No traefik, veja em volumes: /var/run/docker.sock:/var/run/docker.sock:ro, isso vai “conectar” o docker no contêiner do traefik, fazemos isso para que o mesmo consiga “mapear” os outros contêineres e ler suas regras de roteamento em suas labels. Tome cuidado e só faça isso com contêineres que confia pois isso pode dar a permissão de acessar e comprometer os todos seus contêineres e seu computador.

Por fim repare que todos os contêineres têm restart: unless-stopped, isso é a política de restart do docker, dessa forma caso o computador seja desligado quando for ligado os contêineres serão iniciados automaticamente, unless stopped, ou seja a menos que sejam parados.

Ultimo exemplo:

version: "2.1"

networks:
  web:
    external: true
  internal_net:
    external: false

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    networks:
      - web
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  ttrss:
    image: wangqiru/ttrss:latest
    container_name: ttrss
    restart: unless-stopped
    networks:
    - internal_net
    - web
    environment:
      - DB_PASS=E7WaTdu9KPLXxYXTqtrA
      - SELF_URL_PATH=http://localhost/
      - DB_HOST=ttrss_db
      - PUID=1000
      - PGID=1000
      - TZ=America/Sao_Paulo
    depends_on:
      - ttrss_db
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.ttrss.rule=PathPrefix(`/ttrss/`)"
      - "traefik.http.routers.ttrss.entrypoints=web"
      - "traefik.http.middlewares.sp1.stripprefix.prefixes=/ttrss/"
      - "traefik.http.routers.ttrss.middlewares=sp1"
      - "traefik.docker.network=web"

  ttrss_db:
    image: postgres:13-alpine
    container_name: ttrss_db
    restart: unless-stopped
    networks:
      - internal_net
    environment:
      - POSTGRES_PASSWORD=E7WaTdu9KPLXxYXTqtrA
    volumes:
      - ./docker_vols/ttrss_db/:/var/lib/postgresql/data
    labels:
      - "traefik.enable=false"

Continuamos com o nosso conhecido traefik, mas agora vamos colocar no ar o tt-rss, que é um leitor de feeds RSS, que utiliza um banco de dados postgres, essa é a primeira coisa diferente nesse exemplo repare que no topo estão definidas 2 redes (uma chamada web e outra internal_net). O traefik que é o contêiner que está exposto está apenas na web, a aplicação (ttrss) em ambas as redes e o banco de dados apenas na internal_net. Fizemos isso para segregar o banco de dados (que contêm dados sensíveis) do traefik para que o mesmo caso comprometido não acesse o(s) banco de dados.

Outra coisa a destacar é a opção depends_on, que cria um relação de dependência entre o contêiner da aplicação (ttrss) e o seu banco de dados, iniciando o banco de dados antes da da aplicação.

Segurança

A fim de manter tudo isso seguro, existem diversas práticas e níveis de segurança, um bom começo é ter senhas fortes e únicas (evitar o famoso usuário admin com senha admin) com um gerenciador de senhas e realizar as atualizações de segurança.

Para deixar todos seus contêineres atualizados, tem o Diun, que “conecta” no docker (como fizemos com o traefik) e verifica periodicamente se existem atualizações para seus contêineres, disparando uma notificação via email ou telegram etc …

Já para manter o host atualizado, uma possibilidade é utilizar o UnattendedUpgrades que atualiza os pacotes automaticamente, e se quiser pode até reiniciar automaticamente quando necessário. Porém, talvez seja melhor assinar as listas de email/rss de segurança da sua distro (debian security-announce, Ubuntu USN), do docker e das suas aplicações e frameworks e veja se faz aquelas atualizações de fato te afetam e se realmente faz sentido aplica-lás.

https://twitter.com/nixcraft/status/878903460871061504

Um site excelente para deixar nos favoritos é o Open Web Application Security Project (owasp) é uma comunidade de segurança com diversas dicas e recomendações, por exemplo: como armazenar senhas de forma segura e no nosso caso Docker security.

Uma forma excelente para aprender segurança é praticar nas Capture the flag (CTF) que são ambientes controlados para testar a segurança como um todo e revelar a flag (tipo uma senha), comprovando que conseguiu comprometer a segurança. Tem vários sites, tenho mais contato com o overthewire e o hackthebox.

Um vídeo que gostei foi do LiveOverflow: Protect Linux Server From Hackers, no qual ele disseca as dicas populares de boas práticas para proteger seus servidores linux e ele mostrou que essas boas práticas nem sempre são tão positivas e “preto no branco”. Depois ele fez uma continuação bem interessante: Understand Security Risk vs. Security Vulnerability! pontuando as diferenças e semelhanças entre riscos de segurança e vulnerabilidades.

Monitoramento

Na seção anterior sobre storage, como saberemos se um disco falhou? Quando tudo parar de funcionar? Ou tem algum jeito de “ficar de olho”, por isso que precisamos ter uma solução de monitoramento.

As soluções mais populares de monitoramento são o zabbix e o prometheus, que depois de configurados te notificam em caso de alguma falha.

No caso dos discos, temos dois indicativos que os discos estão para falhar: As informações S.M.A.R.T. – Self-Monitoring, Analysis, and Reporting Technology (tecnologia de automonitoramento, análise e relatório) geradas pelo próprio disco com diversas informações da “saúde” do disco, o disco não gera isso sozinho, sua solução de monitoramento precisa disparar os auto-testes e monitorar essas infos. Porém um estudo de 2007 do Google, mostrou que os dados S.M.A.R.T sozinho não são um bom indicativo da falha dos discos, daí surgem o segundo indicativo o tempo de escrita e leitura, se o disco começa a demorar muito para ler ou escrever isso pode indicar uma falha, essa informação é gerada na solução de monitoramento.

Outra solução legal de monitoramento é o healthchecks.io, serviço para monitorar seus cronjobs (tarefas executadas periodicamente), por exemplo imagine que você configurou para fazer backup do seu laptop na sua Raspberry Pi, mas por algum problema o backup para de ser feito com sucesso. Como vai saber que parou de funcionar? No healthchecks.io você configura uma periodicidade que os backups devem ser feitos e quando é feito o backup seu laptop “pinga” o serviço, e em caso de falha ou o backup deixou de rodar uma notificação é enviada.

Infraestrutura como código

Essa é a parte mais legal 🤩, chegou o dia que seu SD card da Raspberry Pi morreu 😞 , tranquilo só fazer a restauração do backup no SD novo e instalar e configurar tudo mas isso pode ser demorado, com a infraestrutura como código (IaC) você cria uma “receita” que configura toda sua infra automaticamente.

A ferramenta que tenho mais contato é o ansible, ele é similar ao chef e puppet. A principal vantagem do ansible é que ele é agentless, ou seja não precisa de um ter software instalado esperando por instruções do controle, basta ter o python instalado e acesso ssh e na máquina que vai disparar o ansible basta instalar com um pip install, super prático.

Apesar de ser muito legal automatizar a configuração dos ambientes com IaC, se tudo é importante nada é importante, a IaC não precisa estar no topo das suas prioridades quando configurando seu setup.

Considerações finais

Espero com essa visão geral dos aspectos do self-hosting tenha uma noção do que se trata e comece a aprender mais sobre o tema e adotar esse movimento.

Além de todas indicações que já fiz vou fechar indicando um podcast: o Self-Hosted podcast que me ajudou muito a aprender sobre esses tópicos e o canal do YouTube: Techno Tim que tem várias dicas de como montar seu homelab.

O que é selfhosting e por que adotá-lo

Fri, 28 May 2021 16:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 28Maio2021

Muitos dos serviços digitais que utilizamos no nosso dia a dia estão na “nuvem”, como Gmail, LinkedIn, Google Drive/Docs etc … e como diria um famoso ditado “essa tal de “nuvem” não existe, são apenas computadores de outras pessoas”. Mas, então quais as implicações da maioria das nossas vidas digitais estar nesses computadores dessas grandes empresas? Essas implicações no geral são positivas para os usuários?

Neste texto, que vai ser o primeiro de uma série, vamos falar de uma alternativa simples chamada self hosting, ou seja, hospedar os serviços que usamos em computadores que de fato temos controle, e como fazê-lo.

Motivos para adotar o self-hosting

Dentre todos os motivos para adotar o self-hosting, vale destacar os seguintes:

Segurança

Com muita frequência, vemos notícias de vazamentos envolvendo nossos dados, e mesmo assim muitos dos vazamentos não são percebidos pelas próprias empresas e logo não são noticiados, ou seja, a quantidade de vazamentos pode ser ainda maior.

Hospedando as próprias coisas não é um alvo tão grande para os cibercriminosos quanto das big tech, pense nos incentivos, se comprometer uma big tech o cibercriminoso vai ter os dados de milhões de pessoas , enquanto comprometer sua pequena infra não rendera tanto dados assim. Além disso outro incentivo para atacar as big tech é que muitas delas tem programas de bug bounty para recompensar a descoberta da suas inseguranças.

E também isso vai te ensinar quais são as boas práticas de segurança e como adota-lá.

Privacidade

Outro ditado famoso diz que se o serviço é gratuito, o produto é você. E isso é verdade, você está pagando o serviço com seus dados.

Com selfhosting, seus dados ficam apenas com você, retomando totalmente sua privacidade, afinal foi você quem montou o esquemas de criptografia de disco, gerenciamento de senhas (afinal como as senhas sempre vazam não pode usar a mesma senha em mais de um lugar, é bom se inscrever no haveibeenpwned.com para ser notificado se suas senhas vazaram)

Aprendizado e experiência

Pra min essa é a principal vantagem, hospedar suas próprias coisas vai proporcionar um conhecimento e experiência enorme em diversas disciplinas como:

Sistemas operacionais (principalmente Linux e talvez BSD).
Redes
Segurança
Contêineres
Linguagens de script
Infraestrutura como código
Monitoramento
E principalmente Inglês

Ter o seu “ambiente controlado” vai te possibilitar aprender, testar e quebrar as coisas que te proporcionará um aprendizado enorme que num ambiente profissional do trabalho muitas vezes não te permitiria.

Exemplos de aplicações

As aplicações mais comuns que normalmente são hospedadas são:

Pi-Hole: Permite bloquear anúncios, domínios que te rastreia e maliciosos a nível de rede, ou seja em todos seus dispositivos não apenas no navegador.
syncthing: É um app pra Android no PC que permite sincronizar pastas do seu android com o PC e vice versa. Dessa forma você consegue fazer backup do seu celular e sincronizar arquivos sem precisar de uma nuvem das big tech. Se tiver interesse leia meu texto de como montei meu setup de backups: Como parei de me preocupar e passei a adorar minha solução de backups.
nextcloud: É uma solução de nuvem completa, permite sincronizar arquivos como dropbox, sincronizar contatos e agenda, quadro kanban (tipo trello), videochamadas e muito mais.
Home Assistant: Gosta da sua alexa ou google assistant controlando suas luzes e outras coisas da sua smart home? Com o Home assistant você consegue ter seu próprio hub de automação com total privacidade e controle. Gosta de eletrônica? O projeto esphome consegue integrar suas plaquinhas ESP8266/ESP32 com o Home Assistant.

Considerações finais

Com o selfhosting você terá privacidade e controle total dos seus dados e vai aprender muito nessa jornada, nós próximos textos vamos abordar de fato começar.

Vale uma pequena ressalva, casos você seja uma pessoa dev e só quer colocar seu app no ar, e seu objetivo principal agora é apenas isso, talvez ir pelo caminho do selfhosting não seja a melhor alternativa agora, administração de sistemas é muitas vezes um trabalho de tempo integral e talvez seja melhor usar serviços como heroku, vercel e netlify que cuidaram de tudo para você, para que consiga fazer essa entrega mais rápido. E quanto tiver disponibilidade estudar e adotar o selfhosting :P

O que é um tarpit de rede e como colocar um no ar

Mon, 18 Jan 2021 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 18Jan2021

Foto de Ariel Besagar, Unsplash

Quando vemos as notícias de cyber ataques, como o WannaCry, é impressionante o impacto desses ataques, infectando milhares de computadores. No caso do WannaCry existia uma atualização de segurança que foi publicada 1 mês antes do ataque, quem não atualizou e estava exposto na internet provavelmente foi infectado. Moral da historia é deve se tomar todas precauções de segurança antes de expor algum computador na Internet. Se tiver interesse, leia as essas estatísticas:

Assim que se coloca algum serviço na internet pública, em poucos minutos, já vemos que os logs de acesso do ssh (protocolo para acessar remotamente computadores) estão lotados de tentativas de combinações de usuário e senha, para conseguir acesso no servidor. Neste texto vamos mostrar como se proteger e como colocar um tarpit no lugar, uma especie de “armadilha” que deixa os atacantes “parados” perdendo tempo e recursos sem atacar ninguém, protegendo quem está vulnerável.

Logs de acesso do ssh: Fonte

Começando pelo começo: protegendo seu servidor ssh

De todas as mitigações para proteger seu servidor ssh, a medida mais efetiva é desativar a autenticação por senha e utilizar apenas a autenticação por chaves privadas. Se ainda não tem uma chave ssh, gere uma com o comando ssh-keygen.

Copie sua chave pro seu servidor: ssh-copy-id -i ~/.ssh/id_rsa usuario@servidor, se necessário ajuste o caminho da chave depois do -i .
Teste se está funcionando: ssh usuario@servidor , se o ssh conectar sem pedir senha então está tudo certo.

Desativando autenticação por senha: logue no servidor (ssh usuario@servidor), e edite o arquivo /etc/ssh/sshd_config como root (sudo nano /etc/ssh/sshd_config), por fim encontre a linha PasswordAuthentication e coloque no, não se esqueça de não deixar a linha comentada (tire o # no começo da linha). Por fim, reinicie o ssh, sudo systemctl restart sshd

Testando: Tente logar com um usuário que não existe: tipo ssh usr123321@servidor, e deve aparecer Permission denied (publickey).

É isso que vai acontecer com quem tentar acessar seu servidor, uma permissão negada sem nem pedir senha.

endlessh: O que faz um tarpit?

A tradução de Tarpit é “poço de areia movediça”, no nosso contexto de redes é um serviço que intencionalmente insere um atraso, atrasando os clientes que estão conectando e os forçando esperar.

O endlessh é um tarpit de ssh, ele explora um “brecha” na especificação do ssh (RFC 4253) que diz que quando um cliente está conectando o servidor pode mandar um “banner” (aqueles avisos legais avisando a politica de segurança), mas a especificação não coloca um limite do tamanho desse banner. É assim que o endlessh funciona, um cliente conectando fica esperando mandar o resto do banner, e o endlessh fica mandando o banner de pouco em pouco só pra manter a conexão ativa. Dessa forma o atacante fica gastando banda e recursos sem acontecer nada ao invés de atacar os clientes que de fato estão inseguros.

Exemplo de banner ssh, Fonte: https://www.healthcareitnews.com/news/warning-banners-often-work-heres-how-hospitals-can-use-them-ward-hackers

Colocando o endlessh no ar

Primeiramente vamos instalar as dependências necessárias:

sudo apt install git build-essential

O apt , ou similarmente apt-get, é um gerenciador de pacotes de distribuições Debian. Pense no gerenciador de pacotes como a app store de seu celular, um programa que instala, remove e atualiza os softwares do seu sistema. É uma maravilha, pois imagine que precisa atualizar o VLC, ao invés de ir ao site e baixar o instalador mais recente basta fazer sudo apt update, para verificar se existem atualizações e finalmente sudo apt upgrade para baixar e instalar as atualizações.

O comando acima então instala o git e o pacote build-essential.

Para saber o que um pacote é, podemos utilizar o info do apt, com apt into build-essential temos:

Package: build-essential
Version: 12.9
Priority: optional
Build-Essential: yes
Section: devel
Maintainer: Matthias Klose <doko@debian.org>
Installed-Size: 20.5 kB
Depends: libc6-dev | libc-dev, gcc (>= 4:10.2), g++ (>= 4:10.2), make, dpkg-dev (>= 1.17.11)
Tag: devel::packaging, interface::commandline, role::data, role::program,
 scope::utility, suite::debian
Download-Size: 7,704 B
APT-Manual-Installed: yes
APT-Sources: <https://deb.debian.org/debian> bullseye/main amd64 Packages
Description: Informational list of build-essential packages
 ...
 This package contains an informational list of packages which are
 considered essential for building Debian packages.  This package also
 depends on the packages on that list, to make it easy to have the
 build-essential packages installed.
 ...

Instalamos o build-essential pois ele instala o compilador gcc e o make que vamos utilizar (veja na linha Depends).

Clonando o projeto:

git clone https://github.com/skeeto/endlessh.git

Agora precisamos compilar o projeto. Felizmente o projeto tem um makefile, que é um arquivo com os comando de compilações configurados. Dessa forma basta fazer make e sudo make install para gerar o binário do endlessh e copiar para /usr/local/bin.

Agora pasta rodar o endlessh:

/usr/local/bin/endlessh -v

2021-01-14T01:22:10.091Z Port 2222
2021-01-14T01:22:10.091Z Delay 10000
2021-01-14T01:22:10.091Z MaxLineLength 32
2021-01-14T01:22:10.091Z MaxClients 4096
2021-01-14T01:22:10.091Z BindFamily IPv4 Mapped IPv6

O endlessh está rodando na porta 2222, então abra outra aba no terminal e faça ssh usuario@servidor -p 2222 e veja o que acontece … ou seja nada 😆

Mas como faço pro endlessh iniciar sozinho? Na próxima secção vamos mostrar como :)

systemd: Como manejar serviços

O systemd é um sistema init, que é o primeiro processo iniciado durante o boot do sistema e ele é responsável por iniciar e gerenciar todos os serviços do sistema. Por exemplo, se está rodando um servidor web com nginx, o systemd vai iniciar o nginx automaticamente e em caso dele travar vai ser iniciado novamente, certificando-se que está sempre no ar.

Na maioria das distribuições Linux, o systemd é o sistema init padrão, que é controlado através do comando systemctl. Por exemplo: veja o status de todos os serviços: sudo systemctl status --all . aqui podemos ver a que serviço cada processo está associado.

Mão na massa: na pasta util do endlessh temos o arquivo para subir o endlessh como serviço, o endlessh.service (dentro da pasta util). Não vamos entrar no detalhe das diretivas definidas desse arquivo, aos interessados veja o artigo sobre systemd na arch wiki.

Vamos apenas mudar apenas uma coisa no arquivo, na linha exec coloque o -v, para ele rodar mostrando mais detalhes, como os exibir os clientes conectando, ficando assim: ExecStart=/usr/local/bin/endlessh -v

Vamos copiar o arquivo para ser identificado: sudo cp endlessh.service /etc/systemd/system/, agora faça sudo systemctl daemon-reload para que seja reconhecido, e então finalmente sudo systemctl enable endlessh, agora o endlessh está habilitado e deve iniciar automaticamente, para iniciá-lo agora faça sudo systemctl start endlessh.

Só para ter certeza, faça sudo systemctl status endlessh. Podemos ver o status do serviço

Como queríamos, o serviço está rodando.

Também podemos reiniciar o serviço com restart (sudo systemctl restart endlessh), e stop para parar. Para desativar temos o disable, porém caso o serviço seja dependência de outro serviço ele pode acabar sendo iniciado. Nesses casos utilize o mask que previne que o serviço seja iniciado. Por fim, temos o reload que faz que com o serviço carregue sua nova configuração sem derrubar o serviço.

journalctl: Acessando os logs

Agora que o endlessh está rodando e é iniciado automaticamente, como faço para acessar a saída dele para vem quem está conectando?

No systemd os logs de todos serviços podem ser acessados através do comando journalctl, faça sudo journalctl e veja os logs de todos serviços, inclusive do kernel.

Para vermos apenas do endlessh: sudo journalctl -u endlessh

logs do endlessh

Bora analisar os dados? 🤓

Podemos pegar a saída do journalctl e jogar num arquivo para ser lido e parseado para ser colocado num dataframe, por exemplo.

para fazer isso, basta rodar o comando:

journalctl -u endlessh.service > /tmp/endlessh.log

Dessa forma os logs estarão em /tmp/endlessh.log. Depois disso basta fazer um programa que lê o arquivo, para fazer suas análises. Mas né, sem tempo irmão 😛. Vamos pela solução simples, usar comandos de processamento de texto, do Unix ✨:

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | wc -l
1044

Da mesma forma que o operador > joga a saída pra um arquivo o | (chamado de pipe) redireciona a saída para o outro comando, dessa forma o commando acima conta quantas linhas CLOSE tinha. Ou seja no período de 1 dia tivemos 1044 conexões.

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | awk '{print $8}' | sort | uniq -c | sort -hr
    
    705 host=::ffff:218.92.0.210
     32 host=::ffff:87.251.77.206
     12 host=::ffff:81.161.63.103
     10 host=::ffff:221.181.185.220
      9 host=::ffff:81.161.63.100
      9 host=::ffff:222.187.222.53
      9 host=::ffff:221.181.185.148
      8 host=::ffff:221.181.185.135
      8 host=::ffff:122.194.229.122
      7 host=::ffff:218.92.0.211
      6 host=::ffff:81.161.63.252
      6 host=::ffff:81.161.63.101
[...]

O comando acima mostra os IPs que fizeram mais conexões.

Conclusão

Neste texto aprendemos como proteger seu servidor ssh, dessa forma ninguém não autorizado vai conseguir acessar seu servidor. E mostramos como colocar no ar um tarpit para ajudar a proteger quem ainda está vulnerável. Além disso aprendemos como manejar serviços e fazer processamento de texto de uma forma bem rápida, usando ferramentas Unix, que são tarefas muito importantes na administração de sistemas.

Como continuação dessa jornada de implementar as boas praticas de segurança, sugiro o seguinte tutorial da DigitalOcean: 7 Medidas de Segurança para Proteger Seus Servidores. Para segurança digital pessoal, o vídeo da Eva Galperin é excelente: Especialista em Internet desmistifica cyber segurança.

Slides: Treinamento de DevOps

Sun, 25 Oct 2020 16:00:00 -0300

Atividade realizada nos dias 5 até 9 outubro 2020, no Eldorado

Nesse treinamento de 5h, apresentei diversos conceitos e ferramentas de DevOps: como manejar serviços systemd, rede e firewall, como criar seu pacote Debian para deploy mais eficiente, security, monitoramento, backups, docker e ansible.

Slides: An intro to setting up Linux servers and maintaining it

Thu, 11 Jun 2020 14:00:00 -0300

Atividade realizada dia 11 junho 2020, no Eldorado

Nessa apresentação interna, mostrei o que considero mais importante saber para fazer o trabalho que venho fazendo de DevOps.

(Obs: Em alguns slides tinham alguns detalhes sensíveis da infra da empresa, nessa versão publicada essas partes foram censuradas, mas isso não prejudica o entendimento do conteúdo)

slides (arquivo odp editável)