NixOS y los secretos

 (isabelroses.com)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Si en NixOS dejas secretos en la configuración de Nix, en un repositorio Git privado o en git-crypt en texto plano, el Nix store puede ser leído por cualquiera, así que cualquier persona con acceso a la máquina puede leer esos secretos
  • sops-nix cifra archivos de secretos con reglas de .sops.yaml y el flujo de edición de sops, y al activar descifra con la clave SSH del host para dejar el texto plano en el tmpfs de /run/secrets/<name>
  • agenix especifica en secrets.nix las claves públicas receptoras para cada secreto, descifra archivos .age en el tmpfs de /run/agenix/<name>, y requiere volver a cifrar al agregar hosts nuevos o rotar claves
  • El método de poner secretos directamente en el sistema de archivos puede servir en un solo servidor o laptop, pero si se leen en tiempo de evaluación como builtins.readFile "/var/lib/myservice/token", el valor entra al Nix store, así que hay que evitarlo
  • Si estás empezando y solo tienes unos cuantos tokens independientes, agenix requiere menos pasos; si tienes un host con muchos secretos relacionados, como un servidor de correo, sops-nix encaja mejor porque agrupa varios valores en un solo archivo

Riesgo básico al manejar secretos en NixOS

  • La gestión de secretos en NixOS suele dividirse entre sops-nix, agenix/ragenix, usar el sistema de archivos, repositorios Git privados, git-crypt y escribirlos directamente en la configuración de Nix
  • No deberías usar repositorios Git privados, git-crypt ni escribirlos directamente en la configuración de Nix si compartes la máquina o planeas hacer pública la configuración
  • Los secretos se han filtrado al menos dos veces en configuraciones públicas, y los ejemplos siguen disponibles en 1, 2

sops-nix

  • sops-nix puede sentirse difícil de configurar al principio, pero la documentación ha mejorado mucho y una gran mejora es que sops ahora soporta de forma nativa cifrar y descifrar secretos con claves SSH
  • Aun así, sops-nix todavía va rezagado en ese soporte de claves SSH, y hay trabajo en curso en sops-nix#779, sops-nix#922
  • El flujo de uso consiste en crear reglas de cifrado y descifrado en .sops.yaml y editar los archivos de secretos con el comando sops
    • Un ejemplo es definir claves públicas SSH como receptores age para la ruta secrets/*.yaml
    • Si ejecutas sops secrets/shush.yaml, se abre el editor que hayas elegido y puedes escribir valores YAML como hello: sops
    • Al cerrar el editor, los valores se cifran en una forma como ENC[AES256_GCM,...], y puedes volver a editarlos con el mismo comando
  • En la configuración de NixOS, el módulo de sops-nix se encarga de casi todo el trabajo
    • defaultSopsFile = ./secrets/shush.yaml; define el archivo de secretos predeterminado
    • age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]; define la clave SSH del host
    • En secrets."hello" puedes definir owner, group y mode para establecer los permisos del archivo
  • En el momento de la activación, sops-nix descifra el archivo con la clave SSH del host y deja el texto plano en /run/secrets/<name>
    • Esa ruta está en tmpfs, así que los secretos no tocan el disco
    • Los servicios que necesitan el valor solo tienen que leer esa ruta
  • La función de plantillas es útil en configuraciones compartidas o referenciadas por otros usuarios
    • Si un archivo de configuración de un servicio requiere texto plano junto con algunos secretos, no hace falta cifrar el archivo completo
    • Por ejemplo, puedes dejar SMTP_USER=isabel en texto plano e insertar un marcador de secreto como SMTP_PASSWORD=${config.sops.placeholder."mailserver/smtp_password"}

agenix

  • agenix, a diferencia de sops-nix, define los secretos y las claves con acceso en secrets.nix, así que se siente más cercano a Nix
  • En secrets.nix vinculas las claves públicas SSH de usuarios y hosts, y especificas qué claves públicas pueden acceder a cada archivo .age
    • Por ejemplo, "secret1.age".publicKeys = [ isabel host1 ];, "secret2.age".publicKeys = [ isabel host2 ]; permite tener una lista distinta de receptores para cada secreto
  • Los archivos de secretos deben crearse con la CLI de agenix
    • Con agenix -e secret1.age puedes crear secret1.age o volver a editarlo después
  • La forma de conectarlo con la configuración del host es parecida a sops-nix, pero como cada secreto es un archivo separado, la superficie es menor
    • age.secrets.secret1.file = ./secrets/secret1.age; define el archivo
    • owner, group y mode definen propiedad y permisos
  • Durante el arranque, cada archivo .age se descifra con la clave SSH del host y se deja en /run/agenix/<name>
    • Esa ruta también vive sobre tmpfs
  • La parte donde más suele trabarse la gente es el rekeying
    • Si agregas un host nuevo o rotas una clave, hay que volver a cifrar todos los secretos cuyo listado publicKeys cambió en secrets.nix
    • agenix --rekey se encarga de eso, pero necesita la clave privada de uno de los receptores actuales para poder leer el cifrado existente
    • En la práctica, el rekeying se hace desde la máquina en la que más confías, no desde el host nuevo que vas a incorporar

Método usando solo el sistema de archivos

  • Poner secretos directamente en el sistema de archivos tiene el costo de que la configuración ya no describe por completo la máquina
  • En una reinstalación, tienes que volver a colocar todos los archivos en el lugar correcto y con la propiedad correcta
    • En tareas de recuperación, como restaurar un servidor a las 2 de la mañana, eso puede ser un desastre enorme
  • El patrón que hay que evitar es algo como builtins.readFile "/var/lib/myservice/token"
    • Ese método lee el archivo en tiempo de evaluación e incluye el contenido en el Nix store
    • Como el Nix store puede ser leído por cualquiera, terminas exactamente en el mismo modo de fallo del que se advirtió al principio
  • En cambio, al servicio debes pasarle la ruta, no el valor en sí
  • Puede estar bien para un solo servidor o una laptop, pero si tienes una flota o quieres poder reconstruir todo desde cero solo con la configuración, sops-nix o agenix son más adecuados
  • También puede servir cuando cada máquina tiene uno o dos valores que de verdad no deben ir al repositorio, pero entonces le dejas a tu yo del futuro la responsabilidad de volver a colocarlos después

Comparación entre sops-nix y agenix

  • La razón principal para elegir sops-nix es que te permite agrupar la mayor cantidad posible de datos en un solo archivo
    • Si tienes muchos secretos relacionados, como en un servidor de correo, puedes poner más valores en un solo archivo en vez de dividirlos en unos cinco archivos como con agenix
    • Es una herramienta potente para seguir usando a largo plazo y vale la pena considerarla primero en hosts con muchísimos secretos, como un servidor de correo
  • agenix destaca por su simplicidad
    • No hay que aprender un esquema YAML
    • No hay un .sops.yaml que mantener sincronizado
    • Como secrets.nix es simplemente Nix, puedes reutilizar para las claves los mismos bindings let ... in que ya usas para hosts y usuarios
    • El modelo mental es “un secreto, un archivo, una lista de receptores”, y encaja bien con la forma de controlar acceso
    • Como tiene la menor cantidad de piezas en movimiento y aun así ofrece control de acceso por host, es una opción muy recomendable para quien pregunta por primera vez cómo manejar secretos en una máquina NixOS
  • Ambas herramientas resuelven el problema, y hoy la diferencia es mayormente de usabilidad
    • Si vas empezando y varios servicios requieren grupos de secretos relacionados, sops-nix escala mejor
    • Si vas empezando y en su mayoría solo tienes unos cuantos tokens independientes, agenix te lleva al objetivo con menos pasos
    • Si vas a elegir tu primera herramienta para secretos, conviene familiarizarte con el flujo usando agenix y pasarte a sops-nix cuando de verdad sientas la incomodidad del enfoque “un archivo por secreto” por cada valor
  • Se corrigió la parte relacionada con resistencia cuántica
    • age y sops soportan claves de cifrado seguras frente a computación cuántica
    • age#578 fue cerrado y se lanzó v1.3.0
    • Al crear claves age, solo hay que incluir -pq; el ejemplo es age-keygen -pq -o key.txt

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Opiniones en Lobste.rs
  • Vi la explicación de que sops-nix y agenix no guardan los secretos descifrados en disco, pero me pregunto cuál es la ventaja real
    ¿No están tanto el secreto cifrado como su clave en el disco? ¿O uno de los dos se guarda en algún lugar como un TPM?
    Recién empecé a usar Nix y, en un despliegue pequeño de self-hosting, estoy usando el método simple de meterlo al sistema de archivos con scp
    Buscando un poco, parece que se puede proteger una clave privada SSH con TPM, y me preguntaba si también sería posible en una VM, pero al ver que puede haber soporte para vTPM prácticamente me respondí solo
    • En mi servidor uso sops-nix, y para mi modelo de amenaza es suficiente y funciona bien. Ahora me dio curiosidad la idea de guardar la clave privada SSH en el TPM
      Del lado del servidor también tienes el enfoque de NixOps. Puedes ver cómo lo hace Colmena: https://colmena.cli.rs/0.4/features/keys.html
      La idea central es que una máquina confiable que tiene los secretos los empuja al servidor remoto. Es parecido a lo que haces ahora con scp, pero ejecutado de una forma más alineada con Nix
    • Ya es hora de sacar mi frase favorita: “¡depende de la situación!”. Aquí la gestión de secretos resuelve dos problemas al mismo tiempo: proteger los archivos secretos en disco y proteger los secretos dentro de la configuración usada para construir el sistema. Al final, esos valores tienen que estar en algún lado
      Como en los últimos días volví a configurar todo el ecosistema de agenix en el flake de mi sistema, solo puedo hablar de agenix. Para quien le interese, elegí agenix-rekey porque no hace falta tener archivos .yml con secretos y, como ya venía haciendo, se pueden definir todos los secretos directamente en Nix
      Los secretos cifrados están en el Nix store y, como todo lo demás en el Nix store, se pueden leer globalmente. La clave privada SSH que los descifra normalmente es la clave privada del servidor SSH real, aunque opcionalmente puede no ser así. Los secretos se descifran en el momento de activación, más o menos al arrancar, y se colocan en /run/agenix/<user>
      Una herramienta llamada secrix va más allá y vincula secretos a servicios de systemd, y luego esos servicios a los servicios que necesitan los secretos. Así que los secretos solo se descifran mientras ese servicio está en ejecución. Aunque en la práctica, como los usuarios de NixOS rara vez andan prendiendo y apagando servicios seguido, muchas veces eso termina significando que quedan siempre en ejecución. Puede servir para secretos de activación del sistema, como la creación de usuarios
      agenix-rekey hace que el rekeying sea menos molesto y reemplaza secrets.nix por salidas del flake. Usa una split identity de YubiKey como una mitad de la clave. El rekeying consiste en autenticarse con esa clave y con la otra mitad para descifrar el secreto, y luego volver a cifrarlo con la clave pública SSH del servidor. La clave pública se genera al instalar el sistema, y yo uso --copy-host-keys de nixos-anywhere para traerme las claves generadas en el closure de instalación. Los secretos cifrados se guardan en el repositorio, pero dentro de un submódulo separado al que solo pueden acceder builders confiables
      Como referencia, vTPM por lo general no está basado en hardware, y muchos proveedores, incluso si ofrecen TPM, normalmente solo ofrecen TPM v1.2 y no TPM v2. Ese es también el caso de mi proveedor, BinaryLane. Sí, agrega una capa más de seguridad, pero no es un HSM mágico como un TPM real, y no te protege contra compromisos del proveedor o del nodo host. Permitir un vTPM realmente basado en HSM probablemente sería muy costoso para el proveedor, y AWS parece ofrecerlo a precios de AWS
    • Yo uso agenix + agenix-rekey + age-plugin-1p
      Mi clave maestra está en 1Password, así que puedo editar, ver y rekeyear la contraseña de cualquier servidor sin dejar ninguna credencial en el disco de mi laptop
      Puedes dar acceso a servidores que necesiten acceso a claves en tiempo de ejecución. Le dices a agenix-rekey qué claves puede ver ese servidor y ejecutas agenix rekey; entonces se registra en el Nix store una versión cifrada de la clave que ese servidor puede descifrar. La clave privada SSH de ese servidor solo existe en ese servidor y nunca sale de ahí. agenix-rekey solo necesita la clave pública para hacer rekeying
      Así que los casos en los que se filtrarían los secretos serían si hackean mi cuenta de 1Password, o si comprometen el servidor que usa esos secretos
    • En Agenix, por defecto los secretos cifrados se descifran con /etc/ssh/ssh_host_ed25519_key y luego se colocan en un ramfs montado en /run/agenix.d
      Así que sí. El contenido cifrado, la clave de cifrado y el contenido descifrado están todos accesibles desde el sistema de archivos
    • Esto también te permite compartir públicamente toda tu configuración de NixOS. No mucha gente lo hace, pero siento que la mitad de la promesa de Nix está en que otras personas también puedan ayudarte a depurar problemas de tu sistema
  • Había estado pensando en probar agenix y agenix-rekey. Parece que alivian bastante varios de los puntos de dolor que mucha gente menciona, pero todavía no lo probé
    https://github.com/oddlama/agenix-rekey
  • Estuve gestionando credenciales con agenix, pero al final volví a dejarlas directamente en el sistema de archivos. Es más simple, y reinstalar tampoco es algo frecuente para mí
    Además, cada vez quedan menos credenciales de larga duración. Nos estamos alejando de copiar credenciales de largo plazo para pasar a credenciales basadas en hardware, ya sea usándolas directamente o intercambiándolas por credenciales de corta duración