fran314/secrets-manager-rsUn outil en ligne de commande pour sauvegarder, restaurer et vérifier en toute sécurité des secrets en utilisant des standards interopérables comme le chiffrement age et coreutils, garantissant une accessibilité à long terme sans dépendance à un fournisseur.
secs-man est un outil pour gérer les sauvegardes de secrets en gardant à l'esprit l'indépendance vis-à-vis des outils : si vous chiffrez vos secrets avec ce logiciel, vous devriez pouvoir les déchiffrer et les restaurer sans ce logiciel. Même si secs-man disparaît de la surface de la Terre, vos données restent accessibles.
secs-man peut être utilisé pour gérer les secrets de machines locales et distantes, et est idéal pour créer des sauvegardes locales uniquement pour des données trop sensibles pour être sauvegardées dans le cloud.
Vous ne devriez dépendre d'aucun logiciel spécifique pour sauvegarder vos données extrêmement importantes.
Tout logiciel qui vous oblige à rester dans son écosystème après utilisation (par exemple : "si vous le chiffrez avec ce logiciel, vous ne pouvez le déchiffrer qu'avec ce logiciel") vous rend dépendant de celui-ci.
Ainsi, le chiffrement, le déchiffrement et la restauration de vos données importantes devraient être découplés, c'est-à-dire que si vous les avez chiffrées avec un logiciel X, vous devriez toujours pouvoir les déchiffrer sans le logiciel X.
En pratique, vous ne pouvez pas créer une configuration où vos secrets sont 100% à l'abri de la perte de données. Même si votre logiciel X est compatible avec Y, Z et W, vous perdrez toujours l'accès à vos données si X, Y, Z et W cessent tous de fonctionner en même temps.
Ce que vous faites en pratique, c'est vous assurer de ne dépendre que de technologies qui sont des « standards » ou qui s'en approchent. Je suis d'accord pour dépendre de l'existence d'interpréteurs bash, de ports USB et de machines Linux.
Le vrai objectif de secs-man devient alors d'être parfaitement reproductible uniquement avec :
cp, mv et sha256sumLa dépendance à
ageest la plus délicate, mais la dépendance à une bibliothèque cryptographique est inévitable, etagebénéficie à la fois d'une grande popularité et de bonnes liaisons en Rust.
Cela garantit que même si quelque chose arrivait à ce logiciel vous empêchant de l'utiliser à nouveau, en supposant que age existe toujours et que vous êtes prêt à passer 30 minutes de votre vie, vous pourriez toujours récupérer tous vos secrets.
La section récupération manuelle explique comment importer les secrets exportés par ce logiciel sans utiliser ce logiciel, c'est-à-dire uniquement avec coreutils, age et un terminal.
secs-man n'est publié nulle part (ce n'est pas une crate publiée, ni sur nixpkgs, l'AUR ou similaire). Il ne peut être installé que directement depuis ce dépôt, de l'une des manières suivantes.
nix runSi vous n'avez besoin d'exécuter secs-man qu'occasionnellement, vous pouvez l'exécuter directement sans l'installer (nécessite l'activation des flakes)
nix run github:Fran314/secrets-manager-rs -- export /path/to/secrets /path/to/export/endpoint
Pour rendre secs-man disponible à l'échelle du système, vous pouvez importer ce dépôt dans votre configuration Nix avec fetchGit et ajouter le package résultant à environment.systemPackages (ou home.packages avec home-manager)
let
secs-man = pkgs.callPackage "${builtins.fetchGit {
url = "https://github.com/Fran314/secrets-manager-rs.git";
ref = "main";
# rev = "<commit>"; # pin a specific commit for reproducibility
}}/default.nix" { };
in
# add `secs-man` to environment.systemPackages or home.packages
cargoSi vous n'êtes pas sur NixOS, vous pouvez installer le binaire secs-man en pointant cargo vers ce dépôt
cargo install --git https://github.com/Fran314/secrets-manager-rs
notez qu'aucune de ces méthodes n'installe le script secs-man-ssh nécessaire pour les machines distantes : c'est un script autonome qui doit être copié depuis ce dépôt séparément
Cet outil permet d'exporter et de chiffrer des fichiers depuis un répertoire source donné, et de les récupérer en important dans le même répertoire. La manière recommandée d'utiliser cet outil est d'avoir tous vos "secrets" (clés, fichiers, ...) dans un répertoire centralisé.
À la racine du répertoire des secrets, il doit y avoir un fichier texte .secrets-manifest contenant la liste des secrets à gérer, sous forme de chemins relatifs au répertoire des secrets. Les chemins de fichiers ne peuvent pas contenir d'espaces. Chaque entrée peut également spécifier un owner et un mode qui seront utilisés pour définir les autorisations correctes lors de l'import. Voir .secrets-manifest.example pour la syntaxe.
Lors d'une exportation, les fichiers listés dans le manifeste sont chiffrés via age avec une phrase de passe demandée via une invite interactive (secs-man ne la lit jamais depuis un fichier, un argument ou une variable d'environnement). La même phrase de passe est demandée à nouveau lors de l'importation pour déchiffrer les fichiers. L'intégrité des fichiers est garantie par un fichier *.sha256 compagnon, qui est automatiquement généré s'il est manquant. Les fichiers chiffrés sont exportés dans un snapshot horodaté dans le répertoire cible d'exportation.
Les fichiers peuvent ensuite être déchiffrés et importés soit en pointant vers le répertoire cible d'exportation (pour importer le dernier snapshot), soit vers un snapshot spécifique à l'intérieur de ce répertoire.
Les commandes suivantes peuvent être exécutées sans sudo, mais elles échoueront si le manifeste spécifie un propriétaire différent de l'utilisateur exécutant la commande (car l'appel interne à chown échouera).
Pour exporter vos secrets, exécutez
sudo secs-man export /path/to/secrets /path/to/export/endpoint
Pour vérifier l'intégrité d'une exportation existante (voir la note ci-dessous), exécutez
# to verify the integrity of all the exported snapshots
sudo secs-man verify-export /path/to/export/endpoint
# to verify the integrity of a specific snapshot
sudo secs-man verify-export /path/to/export/endpoint/export-YYYY-MM-DD_HH-MM-SSZ
notez qu'une vérification d'intégrité est automatiquement effectuée à chaque exportation. Cela n'est nécessaire que si vous souhaitez vérifier l'intégrité d'une ancienne exportation qui pourrait s'être dégradée et corrompue
Pour importer vos secrets, exécutez
# to import the latest snapshot
sudo secs-man import /path/to/export/endpoint /path/to/secrets
# to import a specific snapshot
sudo secs-man import /path/to/export/endpoint/export-YYYY-MM-DD_HH-MM-SSZ /path/to/secrets
# to import only specific secrets
sudo secs-man import /path/to/export/endpoint /path/to/secrets --pick ssh/id_ed25519 wg/wg0.key
Cet outil peut également être utilisé pour déployer et sauvegarder des secrets sur des machines distantes.
La façon la plus simple d'exporter des secrets distants est de les exporter dans un répertoire temporaire sur l'hôte distant, puis de copier le snapshot exporté vers une sauvegarde locale. De même, pour importer une sauvegarde locale, l'approche la plus simple est de copier le snapshot local dans un répertoire temporaire sur l'hôte distant, puis de les importer à partir de là. Cependant, cela pose le problème que la phrase de passe de chiffrement/déchiffrement doit passer par l'hôte distant, qui peut être considéré comme non fiable.
Afin de déployer vers / sauvegarder depuis des hôtes distants non fiables sans faire passer la phrase de passe par le réseau distant, vous pouvez utiliser le script secs-man-ssh. Ce script ne suppose pas de connexion root via SSH (car cela pourrait être désactivé pour des raisons de sécurité), mais il suppose que l'utilisateur distant dispose des privilèges sudo (afin de permettre à secs-man d'exécuter chown et chmod).
Pour exporter depuis un hôte distant, exécutez :
secs-man-ssh export <user@host> <remote-secrets-dir> <local-backup>
# The flow is the following:
# 1. the script copies the remote secrets to a temporary directory on the remote host
# 2. the temporary directory gets chowned to the remote normal user, so that it can be sudo-less read and copied locally
# 3. the temporary directory is copied on the local host and deleted from the remote host
# 4. the local directory gets exported to the local backup, then deleted
Pour importer vers un hôte distant, exécutez :
# secs-man has to be installed on the remote for the script import to work
secs-man-ssh import <user@host> <local-container> <remote-secrets-dir>
# The flow is the following:
# 1. the latest snapshot gets imported to a temporary local directory with the `--skip-chown-chmod` flag, so that it can be sudo-less read and copied to the remote host
# 2. the local directory gets copied to the remote host in a temporary directory, and deleted from the local host
# 3. the remote temporary directory gets imported to the remote secrets directory with `--from-plaintext`, as the files have already been decrypted
# 4. the remote temporary directory is deleted
Les fichiers exportés sont chiffrés avec age en utilisant une phrase de passe. Le nom du fichier exporté est le nom original avec l'extension supplémentaire .age.
Pour obtenir le même comportement, vous pouvez utiliser ce qui suit :
age --passphrase --output filename.txt.age --encrypt filename.txt
Notez que :
Vérifier l'intégrité d'une exportation consiste à vérifier que chaque somme de contrôle correspond. Pour ce faire, on peut simplement exécuter
find . -name "sha256sums.txt" -execdir sha256sum -c sha256sums.txt \;
Les fichiers importés sont déchiffrés avec age en utilisant une phrase de passe. Le nom du fichier importé est le nom exporté sans l'extension .age. Si owner et/ou mode sont spécifiés dans le manifeste pour une entrée donnée, le fichier importé est défini avec le propriétaire et le mode spécifiés. Si aucun mode n'est spécifié, la valeur par défaut est 600.
Pour obtenir le même comportement, vous pouvez utiliser ce qui suit :
age --output filename.txt --decrypt filename.txt.age
# if no mode is specified, it defaults to 600
chmod <mode> filename.txt
# if no owner is specified, skip this step
chown <owner> filename.txt
Notez que :
Cet outil crée automatiquement des snapshots lors de l'exportation qui ne sont pas nettoyés par l'outil lui-même. Cela signifie qu'il faut faire attention lors de l'exportation de secrets avec cet outil.
Lors de l'exportation de secrets « d'authentification » (clés SSH/WireGuard, jetons), qui peuvent facilement être renouvelés, l'existence du snapshot ne présente aucun risque supplémentaire.
Cependant, lors de l'exportation de secrets « de déchiffrement » (clés de disque, identités age/PGP, mot de passe principal du gestionnaire de mots de passe), l'existence des snapshots signifie que, si les secrets à l'intérieur des exportations venaient à fuiter et à être déchiffrés d'une manière ou d'une autre, un attaquant pourrait avoir accès aux clés de déchiffrement actuelles et passées. Pour cette raison, lors du renouvellement de secrets « de déchiffrement », il serait prudent de supprimer également les anciens snapshots exportés (ce qui peut être facilement fait avec rm -r /path/to/export/endpoint/export-YYYY-MM-DD_HH-MM-SSZ). Notez que le chemin critique qui expose les anciennes clés de déchiffrement implique également la connaissance des secrets actuels, ce qui est probablement une préoccupation plus importante.