Beryl::Encryption
Gestion des clés de chiffrement ZFS (datasets data) côté opérateur.
Modèle « SSH unlock manuel » :
- La clé (32 bytes / 256 bits) est générée côté opérateur au moment du bootstrap. Jamais sur le serveur.
- Stockée dans
~/.config/beryl/<société>/<domaine>/<host>.key, chmod 0400 (lecture par owner uniquement). Dossier parent chmod 0700. - Format sur disque : 64 caractères hexadécimaux + newline.
Lisible avec
cat, copiable visuellement, audit possible. - Format ZFS correspondant :
keyformat=hex -O keylocation=prompt. ZFS attend exactement 64 chars hex sur stdin (le\nfinal n'est PAS consommé). - Sauvegardée naturellement par Time Machine + (v1) iCloud
Keychain via
project_beryl_secrets_vault.md.
Voir zpool-encryption-architecture.adoc pour l'architecture
complète (pourquoi keyformat=hex, pourquoi pas raw, pourquoi
SSH unlock plutôt que keyfile sur le serveur, etc.).
Constants
Permissions du dossier parent (~/.config/beryl/<société>/<domaine>/).
0700 : seul owner peut entrer. Si le dossier existe déjà avec
un autre mode, on ne le modifie pas (pas notre rôle d'écraser
les permissions d'un dossier existant), mais on log un warning.
Permissions du fichier de clé. 0400 = lecture seule par owner,
rien pour group ni other. Toute clé qui n'aurait pas ce mode
exact est rejetée par read (sécurité par défaut).
Taille en bytes de la clé symétrique. ZFS native encryption accepte AES-256-{GCM,CCM} dont la clé fait 256 bits.
Class methods
Vrai si une clé existe déjà à cet emplacement (permet d'éviter
un Errno::ENOENT au moment d'Open quand on veut juste savoir).
Génère une clé ZFS aléatoire en 64 chars hex. Source d'entropie :
Random::Secure (puise dans /dev/urandom sur les Unix). Pas
de seed reproductible — chaque appel donne une clé différente.
Chemin canonique du fichier de clé pour un host donné.
~/.config/beryl/<société>/<domaine>/<host>.key
Le <host> est le short_name (ex: quantas), pas le FQDN.
Cohérent avec le reste de l'arborescence beryl où les YAML host
vivent à ~/.config/beryl/<société>/<domaine>/<host>.yml.
Lit une clé depuis le disque. Vérifications :
- Le fichier existe.
- Mode = 0400 strict. Si autre, erreur explicite (la clé est potentiellement compromise par un autre processus, on ne la touche plus).
- 64 chars hex après strip du newline final.
Retourne la chaîne hex (sans newline). C'est le format attendu
par zfs load-key quand keyformat=hex.
Génère et écrit une nouvelle clé. Refuse si le fichier existe
déjà — une clé écrasée = pool définitivement illisible. Si
vraiment besoin de regénérer, l'opérateur supprime le .key
à la main puis relance (mais alors les datasets chiffrés
actuellement avec l'ancienne clé deviennent inaccessibles).
Crée le dossier parent en 0700 si absent. Pose le fichier en 0400. Retourne la clé hex générée.