Uma única porta de entrada para cada ferramenta interna: um padrão de self-hosting

Todas as equipas de operações acumulam pequenas ferramentas. Um task board, um servidor de dashboards, uma consola de containers, um password vault, umas quantas web apps internas que alguém escreveu. Cada uma começa a vida na sua própria porta, com o seu próprio certificado e a sua própria ideia de autenticação, e ao fim de um ano ninguém tem a certeza de quais estão expostas, quais estão atualizadas ou quais ainda têm um certificado válido. Este é o padrão que usamos para correr um conjunto inteiro de ferramentas internas como um único serviço bem cuidado: uma porta de entrada, uma forma de arrancar as coisas, uma política de acesso.

A forma da stack

O padrão tem quatro camadas, e cada uma tem uma função:

1. DNS: um nome wildcard, como *.tools.example.com, a apontar para um host.
2. Reverse proxy: Traefik nesse host, a terminar o TLS e a encaminhar cada hostname para o container certo.
3. Containers: cada ferramenta no seu próprio container Podman numa rede de containers privada, sem nenhuma porta publicada no host exceto a do proxy.
4. Supervisão: o systemd arranca, reinicia e ordena tudo, para que a stack sobreviva a um reboot sem intervenção humana.

Com isto no lugar, acrescentar uma ferramenta é uma checklist curta e não um projeto: arrancar um container na rede, acrescentar uma rota, feito. Não há um novo buraco na firewall, um novo registo DNS nem um novo pedido de certificado.

DNS: um wildcard, e depois esqueça-o

Um registo wildcard significa que tasks.tools.example.com, grafana.tools.example.com e vault.tools.example.com resolvem todos para o host do proxy sem ninguém voltar a tocar no DNS. Junte-lhe um certificado wildcard para o mesmo nome, e cada nova ferramenta nasce com TLS válido.

Mantenha o wildcard num subdomínio dedicado. Não quer que anything.example.com vá parar ao seu host de ferramentas.

O proxy: rotas como ficheiros que se leem

O Traefik consegue descobrir rotas a partir de labels dos containers ou de ficheiros de configuração simples. Para uma stack pequena e de longa duração preferimos os ficheiros: são fáceis de rever, fáceis de pôr em controlo de versões, e não mudam porque alguém reiniciou um container com labels diferentes. Uma rota para um gestor de tarefas tem este aspeto:

http:
  routers:
    tasks:
      rule: "Host(`tasks.tools.example.com`)"
      entryPoints: [websecure]
      service: tasks
      middlewares: [mgmt-only]
      tls: {}
  services:
    tasks:
      loadBalancer:
        servers: [{ url: "http://tasks:3456" }]
  middlewares:
    mgmt-only:
      ipAllowList:
        sourceRange: ["192.0.2.0/24"]

O middleware é a parte importante. O proxy é o único sítio onde decide quem pode chegar a uma ferramenta, por isso coloque a decisão aí.

Acesso: duas fechaduras, não uma

As ferramentas internas têm os seus próprios logins, e a qualidade deles varia. Não confie apenas neles. Coloque dois controlos à frente:

• Uma lista de origens permitidas no proxy, limitada às redes a partir das quais a sua equipa realmente trabalha. Expanda cada CIDR antes de o escrever e volte a lê-lo depois. Um comprimento de prefixo mal escrito pode transformar a gama de um único escritório numa grande parte da internet:

python3 -c "import ipaddress,sys; n=ipaddress.ip_network(sys.argv[1],strict=False); print(n, n[0], '->', n[-1], n.num_addresses)" 192.0.2.0/24

• Um middleware de autenticação (basic auth sobre TLS no mínimo, ou forward authentication para o seu fornecedor de identidade) para ferramentas que não devem ser acessíveis nem a partir de dentro sem uma segunda credencial.

O password vault merece uma reflexão especial. Um servidor compatível com Bitwarden, como o Vaultwarden, guarda o conteúdo do vault encriptado pelos clientes, pelo que o servidor nunca o detém em forma legível. É uma propriedade forte, mas não elimina a necessidade de restringir quem pode chegar ao servidor.

Containers sob systemd

Correr containers à mão funciona até ao primeiro reboot. O Podman integra-se com o systemd através do Quadlet: descreve o container num pequeno unit file e o systemd trata-o como qualquer outro serviço.

# /etc/containers/systemd/tasks.container
[Unit]
Description=Task manager
After=network-online.target

[Container]
Image=docker.io/vikunja/vikunja:<pinned-tag>
Network=tools.network
Volume=/srv/tools/tasks:/app/vikunja/files:Z

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Depois de systemctl daemon-reload, systemctl start tasks executa-o, e a partir daí arranca no boot. Fixe as image tags em vez de seguir latest, para que uma atualização seja uma decisão que toma, com um dump e um rollback prontos, e não algo que lhe acontece no próximo reinício.

Mantenha o SELinux enforcing. Aplique a label a cada volume para o container que o detém (:Z para um volume privado, :z para um que mais do que um container tenha de partilhar).

Renomear sem partir nada

Mais cedo ou mais tarde uma ferramenta muda: um novo host, um novo domínio, um nome mais arrumado. Mantenha o nome antigo a funcionar fazendo o proxy responder-lhe com um redirecionamento permanente para o novo. Use 308 Permanent Redirect em vez de 301, porque um 308 diz aos clientes para repetirem o mesmo método e o mesmo body no novo endereço.

Há uma armadilha que apanha scripts, não browsers. Os browsers seguem redirecionamentos. Muitos clientes de linha de comandos e bibliotecas não o fazem, a menos que se lhes diga. Um script que envia um POST para o nome antigo recebe um 308, não o segue, e continua. Nada foi criado, nada falhou de forma audível, e se o script só verifica que algo respondeu, reporta sucesso. Com o curl, use -L para seguir, e verifique sempre o código de estado e o body:

curl -s -o out.json -w '%{http_code}\n' -X POST https://tasks.tools.example.com/api/v1/...

Um body de resposta com as palavras «Permanent Redirect» onde esperava JSON é o sinal. Quando renomear, procure nos seus scripts e integrações o nome antigo e atualize-os, e mantenha o redirecionamento apenas como rede de segurança.

Backups, monitorização e atualizações

Monitorize cada rota a partir de fora do host pela página esperada, não apenas por uma resposta, e atualize uma ferramenta de cada vez, mantendo a imagem anterior até a nova ter corrido durante algum tempo.

Uma checklist para as suas próprias ferramentas

• Consegue listar todas as ferramentas internas, o seu hostname e quem pode chegar a elas?
• Alguma ferramenta publica a sua própria porta no host ou na internet, contornando o proxy?
• Todas as gamas da sua lista de permissões são tão estreitas como pensa? Expanda-as e veja.
• Os seus containers voltam sozinhos depois de um reboot?
• Os seus scripts verificam códigos de estado, ou apenas que algo respondeu?
• Quando foi a última vez que fez restore do seu password vault?

Uma porta de entrada, uma política e uma forma de arrancar as coisas transformam uma gaveta de ferramentas soltas num serviço sobre o qual consegue raciocinar.

CTA

Se quer as ferramentas da sua equipa operadas desta forma, na sua própria instância, os nossos engenheiros podem ajudar. Fale com um engenheiro

Related

Relacionados: Ferramentas de operações self-hosted e geridas · O hardening baseline em cada host