NixOS e segredos

• No NixOS, se você deixar segredos em texto puro na configuração do Nix, em um repositório Git privado ou no git-crypt, a Nix store fica legível por qualquer pessoa, então quem tiver acesso à máquina poderá ler os segredos
• O sops-nix criptografa arquivos de segredos com regras em .sops.yaml e o fluxo de edição do sops, e na ativação os descriptografa com a chave SSH do host, deixando o texto puro em tmpfs em /run/secrets/<name>
• O agenix define, em secrets.nix, as chaves públicas destinatárias de cada segredo e descriptografa arquivos .age para tmpfs em /run/agenix/<name>; ao adicionar um novo host ou trocar chaves, é preciso fazer rekey
• A abordagem de manter segredos diretamente no sistema de arquivos pode servir para um único servidor ou notebook, mas deve-se evitar ler no momento da avaliação, como em builtins.readFile "/var/lib/myservice/token", porque o valor vai parar na Nix store
• Se você está começando e tem só alguns tokens independentes, o agenix exige menos etapas; se o host tem muitos segredos relacionados, como um servidor de e-mail, o sops-nix se encaixa melhor por agrupar vários valores em um só arquivo

---

Risco básico ao lidar com segredos no NixOS

• O gerenciamento de segredos no NixOS normalmente se divide entre sops-nix, agenix/ragenix, uso do sistema de arquivos, repositórios Git privados, git-crypt e escrever diretamente na configuração do Nix
• Repositórios Git privados, git-crypt e escrever diretamente na configuração do Nix não devem ser usados se você compartilha a máquina ou pretende tornar a configuração pública
  • A Nix store pode ser lida por qualquer pessoa, então alguém com acesso à máquina pode ler os segredos
  • Esse risco é especialmente importante quando existem vulnerabilidades como CVE-2026-31431(copyfail) e CVE-2026-43284 e CVE-2026-43500(dirtyfrag)
• Já houve pelo menos dois casos de vazamento de segredos em configurações públicas, e os exemplos seguem em 1, 2

sops-nix

• O sops-nix pode parecer difícil de configurar no começo, mas a documentação melhorou bastante, e o fato de o sops agora oferecer suporte nativo a criptografar e descriptografar segredos com chaves SSH é uma grande melhora
• Ainda assim, o sops-nix continua atrasado nesse suporte a chaves SSH, com trabalho em andamento em sops-nix#779 e sops-nix#922
• O fluxo de uso consiste em criar regras de criptografia/descriptografia em .sops.yaml e editar os arquivos de segredos com o comando sops
  • Um exemplo é definir chaves públicas SSH como destinatárias age para o caminho secrets/*.yaml
  • Ao executar sops secrets/shush.yaml, o editor escolhido é aberto, e você pode escrever valores YAML como hello: sops
  • Ao sair do editor, os valores são criptografados no formato ENC[AES256_GCM,...], e o mesmo comando pode ser usado depois para editar novamente
• Na configuração do NixOS, o módulo sops-nix cuida da maior parte do trabalho
  • defaultSopsFile = ./secrets/shush.yaml; define o arquivo padrão de segredos
  • age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]; define a chave SSH do host
  • Em secrets."hello", você define owner, group e mode para configurar as permissões do arquivo
• No momento da ativação, o sops-nix descriptografa o arquivo com a chave SSH do host e deixa o texto puro em /run/secrets/<name>
  • Esse caminho fica em tmpfs, então os segredos não tocam o disco
  • Os serviços que precisam do valor só precisam ler esse caminho
• O recurso de templates é útil em configurações compartilhadas ou referenciadas por outros usuários
  • Quando um arquivo de configuração de serviço exige texto puro junto com alguns segredos, não é necessário criptografar o arquivo inteiro
  • Por exemplo, SMTP_USER=isabel pode ficar em texto puro, enquanto SMTP_PASSWORD=${config.sops.placeholder."mailserver/smtp_password"} pode ser usado como marcador do segredo

agenix

• O agenix, ao contrário do sops-nix, configura os segredos e as chaves com acesso em secrets.nix, o que dá uma sensação de uso mais próxima do Nix
• Em secrets.nix, você faz bindings das chaves públicas SSH de usuários e hosts e define quais chaves públicas podem acessar cada arquivo .age
  • Por exemplo, "secret1.age".publicKeys = [ isabel host1 ]; e "secret2.age".publicKeys = [ isabel host2 ]; permitem listas diferentes de destinatários para cada segredo
• Os arquivos de segredos precisam ser criados com a CLI do agenix
  • O comando agenix -e secret1.age cria secret1.age ou permite editá-lo novamente depois
• A forma de conectar isso à configuração do host é parecida com a do sops-nix, mas cada segredo fica em um arquivo separado, então a superfície aparente é menor
  • age.secrets.secret1.file = ./secrets/secret1.age; define o arquivo
  • owner, group e mode definem proprietário e permissões
• Na inicialização, a chave SSH do host é usada para descriptografar cada arquivo .age em /run/agenix/<name>
  • Esse caminho também fica em tmpfs
• O ponto em que mais se tropeça é o rekeying
  • Ao adicionar um novo host ou trocar chaves, todos os segredos cuja lista publicKeys mudou em secrets.nix precisam ser criptografados novamente
  • agenix --rekey faz isso, mas precisa da chave privada de um dos destinatários atuais para ler o texto cifrado existente
  • Na prática, o rekey costuma ser feito na máquina mais confiável, e não no host novo que você quer subir

Abordagem usando apenas o sistema de arquivos

• Manter segredos diretamente no sistema de arquivos tem o custo de a configuração deixar de descrever completamente a máquina
• Em uma reinstalação, todos os arquivos precisam ser recolocados nos lugares corretos com a propriedade correta
  • Em uma recuperação de servidor às 2 da manhã, isso pode virar um grande desastre
• O padrão a evitar é algo como builtins.readFile "/var/lib/myservice/token"
  • Essa abordagem lê o arquivo no momento da avaliação e inclui o conteúdo na Nix store
  • Como a Nix store pode ser lida por qualquer pessoa, isso vira exatamente o mesmo modo de falha alertado no começo
• Em vez disso, deve-se passar ao serviço o caminho, e não o valor em si
  • Por exemplo, é possível usar opções como services.*.environmentFiles
• Em um único servidor ou notebook, isso pode ser aceitável, mas para uma frota ou para um ambiente que você queira reconstruir do zero só com a configuração, sops-nix ou agenix são mais adequados
• Também pode servir quando cada máquina tem um ou dois valores que realmente não devem entrar no repositório, mas aí a responsabilidade de recolocá-los no futuro fica para você mesmo

Comparando sops-nix e agenix

• O principal motivo para escolher sops-nix é poder agrupar o máximo possível de dados em um único arquivo
  • Em casos com muitos segredos relacionados, como um servidor de e-mail, você pode manter mais segredos em um único arquivo em vez de dividi-los em cerca de cinco arquivos, como aconteceria com o agenix
  • É uma ferramenta poderosa para uso contínuo e vale ser a primeira opção em hosts com muitos segredos, como um servidor de e-mail
• O agenix se destaca pela simplicidade
  • Não há esquema YAML para aprender
  • Não existe .sops.yaml para sincronizar
  • Como secrets.nix é apenas Nix, você pode usar nas chaves os mesmos bindings let ... in que já usa para hosts e usuários
  • O modelo mental é “um segredo, um arquivo, uma lista de destinatários”, o que combina bem com a forma de controle de acesso
  • Como é a opção com menos peças móveis e ainda oferece controle de acesso por chave para cada host, é uma boa recomendação para quem pergunta pela primeira vez sobre gerenciamento de segredos em máquinas NixOS
• As duas ferramentas resolvem o problema, e hoje a diferença é principalmente de usabilidade
  • Se você está começando e vários serviços exigem conjuntos de segredos relacionados, o sops-nix escala melhor
  • Se você está começando e tem basicamente só alguns tokens independentes, o agenix leva ao objetivo com menos etapas
  • Se for escolher sua primeira ferramenta de segredos, vale começar com agenix para se acostumar com o fluxo e migrar para sops-nix quando o desconforto real de “um arquivo por segredo” começar a pesar
• O trecho sobre resistência a computação quântica foi corrigido
  • age e sops oferecem suporte a chaves de criptografia seguras contra ataques quânticos
  • age#578 foi fechada e a v1.3.0 foi lançada
  • Ao criar uma chave age, basta incluir -pq, por exemplo: age-keygen -pq -o key.txt

[GN⁺]

Comentários no Lobste.rs

• Vi explicações de que sops-nix e agenix não armazenam segredos descriptografados no disco, mas fico me perguntando qual é a vantagem prática disso
  O segredo criptografado e a chave dele não ficam ambos no disco? Ou um dos dois fica armazenado em algum lugar como um TPM?
  Comecei a usar Nix há pouco tempo e, em implantações pequenas de self-hosting, estou usando o método simples de colocar no sistema de arquivos com scp
  Pesquisando um pouco, parece que dá para proteger a chave privada SSH com TPM, e eu também estava me perguntando se isso funcionaria em VMs, mas ao ver que pode haver suporte a vTPM acabei encontrando minha própria resposta
  • No meu servidor eu uso sops-nix, e considero que funciona bem e é suficiente para o meu modelo de ameaça. Agora fiquei curioso sobre a abordagem de guardar a chave privada SSH no TPM
    Também existe a abordagem do NixOps no lado do servidor. Dá para ver como o Colmena faz: https://colmena.cli.rs/0.4/features/keys.html
    A ideia central é que uma máquina confiável que tem os segredos faz o push para o servidor remoto. É parecido com o que você faz hoje com scp, mas faz esse processo de um jeito mais alinhado ao Nix
  • Chegou a hora de usar minha expressão favorita: “depende!” Aqui, o gerenciamento de segredos lida com dois problemas ao mesmo tempo: proteger arquivos secretos no disco e proteger segredos dentro da configuração usada para construir o sistema. No fim das contas, esses valores precisam estar em algum lugar
    Como passei as últimas noites reconfigurando a parte da família agenix no flake do meu sistema, só posso falar sobre agenix. Para quem tiver interesse, escolhi agenix-rekey, porque ele evita a necessidade de manter um arquivo .yml com segredos e permite configurar todos os segredos diretamente no Nix, como talvez você já faça
    Os segredos criptografados ficam na Nix store e, como outras coisas na Nix store, são legíveis globalmente. A chave privada SSH que os descriptografa normalmente é a chave privada do servidor SSH real, embora opcionalmente não precise ser assim. Os segredos são descriptografados no momento da ativação, aproximadamente no boot, e colocados em /run/agenix/<user>
    Uma ferramenta chamada secrix vai além e vincula segredos a serviços systemd, e depois vincula esse serviço ao serviço que precisa do segredo. Assim, o segredo só fica descriptografado enquanto aquele serviço estiver em execução. Na prática, porém, usuários de NixOS raramente ficam iniciando e parando serviços com frequência, então na maioria dos casos isso acaba significando “enquanto o sistema estiver rodando”. Pode fazer sentido para segredos usados na ativação do sistema, como criação de usuários
    O agenix-rekey torna o rekey menos trabalhoso e substitui secrets.nix por saídas do flake. Em uma das metades da chave ele usa um split ID do YubiKey. O rekey consiste em autenticar com essa chave e a outra metade para descriptografar o segredo, depois criptografá-lo novamente para a chave pública SSH do servidor. A chave pública é gerada no momento da instalação do sistema, e eu uso --copy-host-keys no nixos-anywhere para pegar a chave gerada no closure de instalação. Eu deixo os segredos criptografados no repositório, mas em um submódulo separado acessível apenas a builders confiáveis
    Só para constar, vTPM normalmente não é baseado em hardware, e muitos provedores, mesmo quando oferecem TPM, geralmente oferecem apenas TPM v1.2 e não TPM v2. Esse é o caso do meu provedor, a BinaryLane. É verdade que isso adiciona uma camada extra de segurança, mas não é um HSM mágico como um TPM de verdade, e não protege contra comprometimento do provedor ou do nó hospedeiro. Para permitir vTPM real baseado em HSM, imagino que o custo para o provedor seria bem alto, e a AWS aparentemente oferece isso a preço de AWS
  • Eu uso agenix + agenix-rekey + age-plugin-1p
    Minha chave mestra fica no 1Password, então consigo editar, visualizar e fazer rekey das senhas de qualquer servidor sem deixar nenhuma credencial no disco do notebook
    Também posso conceder acesso a servidores que precisam de acesso à chave em tempo de execução. Você informa ao agenix-rekey quais chaves aquele servidor pode ver e executa agenix rekey; então uma versão criptografada da chave, que aquele servidor pode descriptografar, é gravada na Nix store. A chave privada SSH do servidor fica apenas naquele servidor e nunca sai de lá. O agenix-rekey só precisa da chave pública para fazer o rekey
    Portanto, os casos em que meus segredos seriam comprometidos são: minha conta do 1Password ser invadida, ou o servidor que usa aquele segredo ser comprometido
  • No Agenix, por padrão, o segredo criptografado é descriptografado com /etc/ssh/ssh_host_ed25519_key e depois colocado em um ramfs montado em /run/agenix.d
    Então sim. O conteúdo criptografado, a chave de criptografia e o conteúdo descriptografado ficam todos acessíveis no sistema de arquivos
  • Isso também permite compartilhar toda a configuração do NixOS publicamente. Não são tantas pessoas que fazem isso, mas sinto que metade da proposta do Nix é permitir que outras pessoas também consigam ajudar a depurar problemas no meu sistema
• Eu vinha só pensando em experimentar agenix e agenix-rekey. Parece que isso reduziria bastante vários dos pontos de dor que muita gente menciona, mas ainda não testei
  https://github.com/oddlama/agenix-rekey
• Eu gerenciava credenciais com agenix, mas acabei migrando para simplesmente deixá-las no sistema de arquivos. É mais simples e, para mim, reinstalações são raras mesmo
  Além disso, credenciais de longa duração estão ficando cada vez menos comuns. Estamos saindo da cópia de credenciais de longo prazo e indo para credenciais baseadas em hardware, usando-as diretamente ou trocando-as por credenciais de curta duração