A armadilha das duas tailnets: uma chave velha que editou a rede errada
Os clientes acessam o Mac alugado pelo Tailscale. Guardamos a regra de acesso SSH na política da tailnet e gerenciamos essa regra por código. Quando um aluguel começa, o endereço do cliente é adicionado. Quando termina, é removido. É um sistema pequeno e sem graça. Até que ele nos disse que todos os clientes tinham perdido o acesso, e estava mentindo.
O que a ferramenta informou
Uma verificação de rotina anunciou que a regra SSH dos clientes estava vazia. Três clientes pagantes, segundo ela, não conseguiam mais conectar. Para um negócio cujo produto é acesso a uma máquina, esse é um alarme máximo.
A regra não estava vazia. Estávamos lendo outra tailnet.
Duas redes, um atalho
A conta tinha duas tailnets. Uma tem a frota: os Macs alugados, o hub, todo compartilhamento com cliente. A outra era uma rede pessoal antiga que sobrou da configuração inicial, com uma máquina morta e um laptop.
A API do Tailscale deixa você dar o nome de uma tailnet, ou passar -, que significa "a tailnet dona da chave que está chamando". Nosso código passava -. Tudo bem, até existirem duas chaves. As chaves são strings impossíveis de diferenciar, então o - segue em silêncio a que estiver no ambiente. Uma chave velha tinha entrado em um arquivo de configuração.
A parte perigosa foi a gravação
Uma leitura que mente desperdiça uma tarde. Uma gravação que mente causa um incidente. A mesma ferramenta tem um modo de reparo que ajusta a regra de acesso aos clientes atuais. Rodando contra a tailnet errada, ele gravou fielmente três endereços de email de clientes reais na política da rede antiga, onde não faziam nada.
Nenhum cliente foi afetado de verdade, porque a tailnet da frota ficou intacta e correta o tempo todo. Mas por alguns minutos a automação estava editando o controle de acesso da rede errada e informando sucesso.
A solução: dar nome à rede
Paramos de passar -. Agora o código usa o nome da tailnet da frota. Uma chave que não consegue ver essa tailnet falha de forma ruidosa, em vez de deslizar para o que ela consegue ver.
Toda execução agora mostra a tailnet com que falou. Se essa linha não for a da frota, os resultados abaixo dela não significam nada, e você sabe disso antes de agir.
A lição geral
Um padrão de conveniência que significa "o que esta credencial apontar" vira armadilha no momento em que você tem mais de uma credencial. Ele transforma uma chave errada, que seria um erro, em um redirecionamento silencioso. Tudo que grava deve dar o nome do alvo, para que usar a credencial errada falhe, em vez de dar certo em um lugar que você não queria.
É o mesmo formato das outras falhas silenciosas que descrevemos em verificações que não podem falhar. A ferramenta estava confiante. A ferramenta estava errada. E nada do que ela mostrava teria avisado você, até ela dizer o nome da rede que estava editando.
Perguntas
- Como uma chave de API do Tailscale escolhe qual tailnet ela edita?
- A chave pertence a uma tailnet, e o nome de tailnet '-' na API significa 'a tailnet dona desta chave'. Duas chaves de duas tailnets parecem iguais, então o '-' segue a chave sem avisar.
- Como diferenciar duas tailnets com segurança?
- Nunca no olho. Compare quais dispositivos cada chave consegue listar. A chave certa vê a sua frota; a errada vê o que mais aquela conta tiver.
- Uma ferramenta deve usar o atalho '-' para a tailnet?
- Não para nada que grava. Escreva o nome da tailnet, para que uma chave da rede errada falhe com 404 em vez de editar a ACL errada em silêncio.
Faça suas próprias contas na calculadora ou alugue um runner.