Comment empêcher les secrets Jellyfin de se retrouver dans les fichiers Compose ou les sauvegardes
Ne considérez pas un fichier Compose, un dépôt Git et une archive de sauvegarde comme des emplacements équivalents pour stocker les identifiants Jellyfin. La recette de déploiement peut être largement copiée ; les valeurs secrètes doivent avoir un cycle de vie, une limite d’accès et un parcours de récupération plus restreints.
Pour une pile Jellyfin, les informations sensibles peuvent inclure des clés API, des identifiants de proxy inverse ou de tunnel, des jetons de fournisseur DNS, des mots de passe de dépôt de sauvegarde, des clés de chiffrement, les identifiants de bases de données des services auxiliaires, ainsi que d’autres jetons utilisés par les extensions ou l’automatisation. Répertoriez-les d’abord, puis déterminez lesquels doivent être reproductibles, lesquels doivent pouvoir être récupérés et lesquels peuvent simplement être réémis.
Séparez les références aux secrets de leurs valeurs
Gardez Compose déclaratif : les images de services, réseaux, montages, ports, noms de variables et références aux secrets doivent figurer dans le fichier ; les identifiants bruts ne le doivent pas. Un espace réservé tel que BACKUP_PASSWORD documente l’exigence sans transformer le fichier Compose en magasin d’identifiants.
Les fichiers d’environnement en clair sont pratiques, mais faciles à copier dans le contrôle de version, des dossiers de dépannage ou des sauvegardes non chiffrées. Un guide actuel sur la gestion des secrets Docker distingue les fuites d’images lors de la construction, la prolifération des fichiers locaux .env et l’exposition de l’environnement au moment de l’exécution : autant de chemins différents menant à la même fuite d’identifiants.
Utilisez un gestionnaire de secrets, le mécanisme de fichiers de secrets pris en charge par Compose ou une autre méthode d’injection à l’exécution adaptée au service dépendant. Ne supposez pas que tous les paramètres Jellyfin prennent en charge la convention _FILE ; utilisez l’injection basée sur des fichiers uniquement lorsque le composant concerné la prend en charge.
Empêchez les secrets d’entrer dans les images, les dépôts et l’historique du shell
Excluez les fichiers de secrets locaux à la fois du contrôle de version et du contexte de build Docker. Le fait qu’un fichier soit répertorié dans .gitignore n’empêche pas un COPY trop large dans le Dockerfile de le placer dans une image si .dockerignore l’autorise encore.
Ne transmettez pas directement des identifiants à longue durée de vie sur une ligne de commande qui sera enregistrée dans l’historique du shell. N’affichez pas les secrets lors du débogage du démarrage. Évitez d’imprimer l’environnement résolu dans des tickets ou des conversations partagées lorsqu’une seule variable suffit à diagnostiquer le problème.
Après une fuite présumée, supprimer la ligne du dernier fichier Compose ne constitue pas une correction. Faites tourner l’identifiant exposé, invalidez les anciens jetons lorsque c’est possible, inspectez l’historique du dépôt et des images, puis supprimez la valeur divulguée des sauvegardes et diagnostics futurs.
Concevez les sauvegardes pour que les secrets nécessaires soient récupérables sans être lisibles à la légère
Certains secrets sont indispensables à la récupération. Une sauvegarde chiffrée est inutile si le mot de passe du dépôt ou la clé de déchiffrement disparaît avec le même serveur, et une pile de proxy ou d’automatisation restaurée peut nécessiter des identifiants qui ne peuvent pas être reconstitués à partir de la seule recette Compose.
Un inventaire pratique de récupération pour l’auto-hébergement considère les clés, jetons, codes de récupération et mots de passe de sauvegarde comme des éléments essentiels à la récupération, tout en conservant les clés qui déverrouillent les sauvegardes en dehors du serveur sauvegardé. Cela diffère du fait de placer un fichier .env en clair dans chaque archive.
Créez un manifeste de récupération des secrets indiquant chaque identifiant requis, son responsable, l’emplacement de la copie faisant autorité, la manière de le restaurer ou de le réémettre, ainsi que la sauvegarde qu’il permet de déverrouiller. Stockez les valeurs sensibles dans un gestionnaire de mots de passe chiffré, un jeu de sauvegardes chiffré ou un paquet de récupération protégé séparément, avec des contrôles d’accès adaptés au foyer.
Empêchez les journaux et les dossiers de dépannage de devenir un second magasin de secrets
Les URL de requêtes du proxy, les vidages d’environnement, les sorties de débogage des applications et les transcriptions du shell peuvent exposer des jetons même lorsque Compose est propre. Avant de partager des journaux, recherchez les en-têtes d’autorisation, les clés API, les jetons dans les chaînes de requête, les cookies, les noms d’hôtes privés et les identifiants.
Les recommandations en matière de journalisation préconisent de masquer les champs sensibles avant que la télémétrie ne quitte le système. Appliquez la même règle aux dossiers d’assistance du serveur domestique : conservez l’original localement si nécessaire au diagnostic, mais partagez une copie expurgée.
Limitez séparément l’accès aux sauvegardes et aux journaux. Une personne qui peut lire les sauvegardes multimédias n’a pas automatiquement besoin d’accéder aux jetons DNS ou aux identifiants du proxy inverse. L’exposition des secrets relève autant de l’étendue des accès que du format des fichiers.
Effectuez ensemble un test de fuite et un test de récupération
Créez un secret leurre avec une fausse valeur reconnaissable, déployez la pile, puis recherchez cette valeur dans le répertoire Compose, l’historique des images, la sortie d’inspection des conteneurs, les journaux, le catalogue des sauvegardes et une restauration de test extraite. Vous découvrirez ainsi où le flux actuel copie des secrets, sans mettre en danger un véritable identifiant.
Effectuez ensuite le test inverse : restaurez la pile Jellyfin sur une cible isolée en utilisant uniquement les éléments de récupération documentés. Si la récupération nécessite un identifiant qui n’existe que sur l’hôte défaillant, la conception manque de secrets indispensables ; si chaque sauvegarde ordinaire expose tous les identifiants en clair, elle contient trop de secrets.
La limite du moindre privilège de ZimaSpace constitue la vérification finale : chaque service, tâche de sauvegarde, administrateur et processus de récupération ne doit recevoir que les secrets nécessaires à son rôle. Faites tourner tout secret qui franchit cette limite de manière inattendue.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin doit-il utiliser un compte partagé unique ou des comptes distincts pour chaque membre du foyer ?
Choisissez les comptes familiaux Jellyfin selon les limites d’identité, d’accès, de contrôle parental et de récupération dont vous avez besoin.
Pourquoi l’utilisation de la mémoire de Jellyfin reste-t-elle élevée une fois la tâche terminée ?
Distinguez la croissance du processus Jellyfin du cache Linux, et n’intervenez que lorsque la mémoire continue d’augmenter ou crée une réelle pression.
Signes indiquant qu’une configuration de stockage Jellyfin devient un risque pour la récupération des données
Auditez les rôles de stockage de Jellyfin, séparez l’état actif des sauvegardes et des données reconstructibles, puis validez la disposition par une restauration.
