NixOS et les secrets

 (isabelroses.com)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Sur NixOS, si vous laissez des secrets en clair dans la configuration Nix, un dépôt Git privé ou git-crypt, le Nix store est lisible par tous, donc toute personne ayant accès à la machine peut lire ces secrets
  • sops-nix chiffre les fichiers de secrets via des règles .sops.yaml et le flux d’édition de sops, puis les déchiffre à l’activation avec la clé SSH de l’hôte pour placer le texte en clair dans le tmpfs de /run/secrets/<name>
  • agenix permet de définir dans secrets.nix les clés publiques destinataires pour chaque secret, déchiffre les fichiers .age dans le tmpfs de /run/agenix/<name>, et nécessite un rechiffrement lors de l’ajout d’un nouvel hôte ou d’une rotation de clé
  • Placer directement des secrets sur le système de fichiers peut convenir à un serveur unique ou à un portable, mais si vous les lisez au moment de l’évaluation, comme avec builtins.readFile "/var/lib/myservice/token", la valeur finit dans le Nix store, donc il faut l’éviter
  • Pour démarrer avec quelques jetons indépendants, agenix demande moins d’étapes, tandis que pour un hôte comme un serveur mail avec beaucoup de secrets liés, sops-nix est plus adapté pour regrouper plusieurs valeurs dans un seul fichier

Risque de base lors de la gestion des secrets sur NixOS

  • Sur NixOS, la gestion des secrets se répartit entre sops-nix, agenix/ragenix, l’usage direct du système de fichiers, les dépôts Git privés, git-crypt et l’écriture directe dans la configuration Nix
  • Il ne faut pas utiliser les dépôts Git privés, git-crypt ou l’écriture directe dans la configuration Nix si la machine est partagée ou si vous prévoyez de rendre la configuration publique
  • Des secrets ont déjà fuité au moins deux fois dans des configurations publiées, et on peut encore en voir des exemples ici : 1, 2

sops-nix

  • sops-nix peut sembler difficile à configurer au premier abord, mais la documentation s’est nettement améliorée, et le fait que sops prenne désormais en charge par défaut le chiffrement et le déchiffrement des secrets avec des clés SSH constitue une avancée importante
  • Cependant, sops-nix est encore en retard sur cette prise en charge des clés SSH, avec des travaux en cours dans sops-nix#779 et sops-nix#922
  • Le flux d’utilisation consiste à définir des règles de chiffrement et déchiffrement dans .sops.yaml, puis à éditer les fichiers de secrets avec la commande sops
    • Par exemple, on peut définir pour le chemin secrets/*.yaml des clés publiques SSH comme destinataires age
    • En exécutant sops secrets/shush.yaml, l’éditeur choisi s’ouvre et l’on peut saisir des valeurs YAML comme hello: sops
    • En quittant l’éditeur, les valeurs sont chiffrées sous une forme comme ENC[AES256_GCM,...], puis peuvent être modifiées à nouveau avec la même commande
  • Dans la configuration NixOS, le module sops-nix gère l’essentiel du travail
    • defaultSopsFile = ./secrets/shush.yaml; définit le fichier de secrets par défaut
    • age.sshKeyPaths = [ "/etc/ssh/ssh_host_ed25519_key" ]; indique la clé SSH de l’hôte
    • Dans secrets."hello", on peut définir owner, group et mode pour régler les permissions du fichier
  • Au moment de l’activation, sops-nix déchiffre le fichier avec la clé SSH de l’hôte et place le texte en clair dans /run/secrets/<name>
    • Ce chemin étant sur tmpfs, les secrets ne touchent pas le disque
    • Les services qui en ont besoin n’ont qu’à lire ce chemin
  • La fonctionnalité de template est utile dans des configurations partagées ou référencées par d’autres utilisateurs
    • Si un fichier de configuration de service doit contenir à la fois du texte en clair et certains secrets, il n’est pas nécessaire de chiffrer tout le fichier
    • Par exemple, SMTP_USER=isabel peut rester en clair, tandis qu’un espace réservé de secret peut être inséré comme SMTP_PASSWORD=${config.sops.placeholder."mailserver/smtp_password"}

agenix

  • agenix, contrairement à sops-nix, configure les secrets et les clés autorisées dans secrets.nix, ce qui donne une expérience plus proche de Nix
  • Dans secrets.nix, on associe des clés publiques SSH d’utilisateurs et d’hôtes, puis on définit quelles clés publiques peuvent accéder à chaque fichier .age
    • Par exemple, on peut définir "secret1.age".publicKeys = [ isabel host1 ]; et "secret2.age".publicKeys = [ isabel host2 ];, avec une liste de destinataires différente pour chaque secret
  • Les fichiers de secrets doivent être créés avec l’interface en ligne de commande agenix
    • La commande agenix -e secret1.age permet de créer secret1.age ou de l’éditer plus tard
  • La façon de les rattacher à la configuration de l’hôte ressemble à sops-nix, mais comme chaque secret est un fichier distinct, la surface visible est plus réduite
    • age.secrets.secret1.file = ./secrets/secret1.age; permet de spécifier le fichier
    • owner, group et mode servent à définir le propriétaire et les permissions
  • Au démarrage, chaque fichier .age est déchiffré avec la clé SSH de l’hôte puis placé dans /run/agenix/<name>
    • Ce chemin se trouve lui aussi sur tmpfs
  • Le point qui bloque le plus souvent est le rekeying
    • Quand on ajoute un nouvel hôte ou qu’on remplace une clé, il faut rechiffrer tous les secrets dont la liste publicKeys a changé dans secrets.nix
    • agenix --rekey s’en charge, mais il faut la clé privée de l’un des destinataires actuels pour relire le texte chiffré existant
    • En pratique, le rechiffrement se fait donc sur la machine la plus fiable, et non sur le nouvel hôte à déployer

Approche basée uniquement sur le système de fichiers

  • Placer directement les secrets sur le système de fichiers a un coût : la configuration ne décrit alors plus entièrement la machine
  • Lors d’une réinstallation, il faut remettre tous les fichiers au bon endroit avec les bons propriétaires
    • Dans une opération de restauration, comme lorsqu’il faut remettre un serveur sur pied à 2 heures du matin, cela peut devenir catastrophique
  • Le motif à éviter est une forme comme builtins.readFile "/var/lib/myservice/token"
    • Cette approche lit le fichier au moment de l’évaluation et inclut son contenu dans le Nix store
    • Comme le Nix store est lisible par tous, on retombe exactement dans le mode d’échec signalé au début
  • À la place, il faut transmettre au service le chemin, et non la valeur elle-même
  • Cela peut convenir à un serveur unique ou à un portable, mais pour une flotte de machines ou un environnement que l’on souhaite pouvoir reconstruire entièrement à partir de la configuration, sops-nix ou agenix sont plus appropriés
  • C’est acceptable quand chaque machine n’a qu’une ou deux valeurs qu’il ne faut vraiment pas mettre dans le dépôt, mais cela reporte sur vous-même, plus tard, la responsabilité de les remettre en place

Comparaison entre sops-nix et agenix

  • La principale raison de choisir sops-nix est sa capacité à regrouper autant de données que possible dans un seul fichier
    • Pour des cas comme un serveur mail avec de nombreux secrets liés, on peut mettre davantage de secrets dans un seul fichier au lieu de les répartir dans environ cinq fichiers comme avec agenix
    • C’est un outil puissant, adapté à un usage prolongé, et un bon premier choix pour des hôtes comme des serveurs mail qui accumulent beaucoup de secrets
  • agenix se distingue par sa simplicité
    • Il n’y a pas de schéma YAML à apprendre
    • Il n’y a pas de .sops.yaml à synchroniser
    • Comme secrets.nix est simplement du Nix, on peut réutiliser pour les clés les mêmes liaisons let ... in que pour les hôtes et les utilisateurs
    • Son modèle mental est « un secret, un fichier, une liste de destinataires », ce qui s’accorde bien avec sa manière de contrôler les accès
    • C’est l’option avec le moins de pièces mobiles tout en offrant un contrôle d’accès par clé selon l’hôte, ce qui en fait une bonne recommandation pour les personnes qui découvrent la gestion des secrets sur des machines NixOS
  • Les deux outils résolvent le problème, et la différence actuelle tient surtout à la facilité d’usage
    • Pour démarrer avec plusieurs services ayant besoin de groupes de secrets liés, sops-nix évolue mieux
    • Pour démarrer avec surtout quelques jetons indépendants, agenix permet d’atteindre l’objectif avec moins d’étapes
    • Si vous choisissez votre premier outil de gestion des secrets, mieux vaut commencer avec agenix pour vous familiariser avec le flux, puis passer à sops-nix lorsque le modèle « un secret par fichier » devient réellement gênant
  • Les points liés à la résistance quantique ont été corrigés
    • age et sops prennent en charge des clés de chiffrement sécurisées face au quantique
    • age#578 a été clos et la v1.3.0 a été publiée
    • Lors de la création d’une clé age, il suffit d’inclure -pq, par exemple : age-keygen -pq -o key.txt

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs
  • J’ai vu l’explication selon laquelle sops-nix et agenix ne stockent pas les secrets déchiffrés sur le disque, mais je me demande quel est l’avantage concret
    Le secret chiffré et sa clé ne sont-ils pas tous les deux sur le disque ? Ou bien l’un des deux est-il stocké dans un TPM ou quelque chose du genre ?
    Je commence tout juste à utiliser Nix, et pour un petit déploiement auto-hébergé, j’utilise simplement la méthode consistant à les copier dans le système de fichiers avec scp, parce que c’est simple
    En cherchant un peu, j’ai l’impression qu’on peut protéger une clé privée SSH avec un TPM, et je me demandais si c’était aussi possible dans une VM ; le fait qu’il puisse y avoir un support du vTPM répond en quelque sorte à ma propre question
    • Sur mon serveur, j’utilise sops-nix, et je considère que c’est suffisant pour mon modèle de menace, tout en fonctionnant bien. Maintenant, je suis curieux de voir comment stocker la clé privée SSH dans un TPM
      J’ai aussi un accès NixOps côté serveur. On peut regarder comment Colmena s’y prend : https://colmena.cli.rs/0.4/features/keys.html
      L’idée essentielle, c’est qu’une machine de confiance qui détient les secrets les pousse vers le serveur distant. C’est similaire à ce que tu fais actuellement avec scp, mais le processus est orchestré d’une manière plus conforme à l’esprit de Nix
    • Il est temps de sortir mon expression préférée : « ça dépend ! » Ici, la gestion des secrets traite deux problèmes à la fois : protéger les fichiers de secrets sur le disque, et protéger les secrets dans la configuration utilisée pour construire le système. Après tout, ces valeurs doivent bien être quelque part
      Comme j’ai passé plusieurs soirées ces derniers jours à reconfigurer tout l’écosystème agenix dans la flake de mon système, je ne peux parler que d’agenix. Pour les personnes intéressées, j’ai choisi agenix-rekey, parce qu’il évite d’avoir à garder des fichiers .yml contenant des secrets, et permet de configurer tous les secrets directement dans Nix, comme je le faisais déjà
      Les secrets chiffrés sont dans le Nix store, et sont lisibles globalement comme tout le reste du Nix store. La clé privée SSH qui permet de les déchiffrer est en général la vraie clé privée du serveur SSH, même si on peut faire autrement. Les secrets sont déchiffrés au moment de l’activation, en gros au démarrage, puis placés dans /run/agenix/<user>
      Un outil appelé secrix va plus loin en liant les secrets à des services systemd, puis en liant ces services à ceux qui ont besoin des secrets. Ainsi, les secrets ne sont déchiffrés que lorsque le service concerné tourne. En pratique, comme les utilisateurs de NixOS démarrent et arrêtent rarement leurs services en permanence, cela revient souvent à dire qu’ils restent déchiffrés en continu. Cela peut néanmoins convenir pour des secrets liés à l’activation du système, comme la création d’utilisateurs
      agenix-rekey rend la rotation des clés moins pénible et remplace secrets.nix par des sorties de flake. Il utilise un split identity YubiKey comme l’une des moitiés de la clé. La rotation consiste à s’authentifier avec cette clé et l’autre moitié, à déchiffrer les secrets, puis à les rechiffrer pour la clé publique SSH du serveur. Cette clé publique est générée lors de l’installation du système, et j’utilise nixos-anywhere avec --copy-host-keys pour récupérer les clés générées depuis la clôture d’installation. Je garde les secrets chiffrés dans le dépôt, mais dans un sous-module séparé accessible uniquement aux builders de confiance
      À noter que vTPM n’est généralement pas basé sur du matériel, et que beaucoup de fournisseurs, même lorsqu’ils proposent un TPM, n’offrent le plus souvent qu’un TPM v1.2 plutôt qu’un TPM v2. C’est aussi le cas de mon fournisseur, BinaryLane. Cela ajoute bien une couche de sécurité supplémentaire, mais ce n’est pas un HSM magique comme un vrai TPM, et cela ne protège pas contre la compromission du fournisseur ou du nœud hôte. Permettre un vTPM réellement fondé sur un HSM serait probablement très coûteux pour les fournisseurs, et AWS semble le proposer à des prix AWS
    • J’utilise agenix + agenix-rekey + age-plugin-1p
      Ma clé maîtresse est dans 1Password, ce qui me permet de modifier, consulter et faire la rotation des mots de passe de n’importe quel serveur sans laisser le moindre identifiant sur le disque de mon portable
      Je peux donner des droits d’accès aux serveurs qui ont besoin d’accéder aux clés à l’exécution. Il suffit d’indiquer à agenix-rekey quelles clés un serveur donné peut voir et d’exécuter agenix rekey ; une version chiffrée de la clé que ce serveur peut déchiffrer est alors enregistrée dans le Nix store. La clé privée SSH de ce serveur ne se trouve que sur ce serveur et n’en sort jamais. agenix-rekey n’a besoin que de la clé publique pour faire la rotation
      Donc, les seuls cas où les secrets fuient sont soit un piratage de mon compte 1Password, soit la compromission du serveur qui utilise ces secrets
    • Dans Agenix, par défaut, les secrets chiffrés sont déchiffrés via /etc/ssh/ssh_host_ed25519_key, puis placés dans une ramfs montée sur /run/agenix.d
      Donc oui : le contenu chiffré, la clé de chiffrement et le contenu déchiffré sont tous accessibles via le système de fichiers
    • Cela permet aussi de partager publiquement toute la configuration NixOS. Peu de gens le font, mais j’ai l’impression qu’une moitié de la promesse de Nix, c’est justement que d’autres peuvent aider à déboguer les problèmes de mon système
  • J’envisageais d’essayer agenix et agenix-rekey depuis un moment. Ça semble réduire pas mal des points de friction dont beaucoup parlent, mais je ne l’ai pas encore fait
    https://github.com/oddlama/agenix-rekey
  • J’ai géré mes identifiants avec agenix, puis je suis revenu à une approche où je les mets simplement dans le système de fichiers. C’est plus simple, et les réinstallations restent rares dans mon cas
    En plus, les identifiants de longue durée deviennent de plus en plus rares. On s’éloigne de la copie d’identifiants à long terme pour aller vers des identifiants fondés sur du matériel, utilisés directement ou échangés contre des identifiants à courte durée de vie