Behandel een Compose-bestand, een Git-repository en een back-uparchief niet als gelijkwaardige plaatsen om Jellyfin-inloggegevens op te slaan. Het implementatierecept kan breed worden gekopieerd; geheime waarden moeten een beperktere levenscyclus, toegangsgrens en herstelroute hebben.
Voor een Jellyfin-stack kunnen gevoelige gegevens bestaan uit API-sleutels, inloggegevens voor reverse proxies of tunnels, tokens van DNS-providers, wachtwoorden voor back-uprepositories, versleutelingssleutels, databasegegevens voor ondersteunende services en andere tokens die door plug-ins of automatisering worden gebruikt. Breng ze eerst in kaart en bepaal vervolgens welke reproduceerbaar moeten zijn, welke herstelbaar moeten zijn en welke eenvoudig opnieuw kunnen worden uitgegeven.
Scheid verwijzingen naar geheimen van geheime waarden
Houd Compose declaratief: service-images, netwerken, mounts, poorten, variabelenamen en verwijzingen naar geheimen horen in het bestand; onbewerkte inloggegevens niet. Een tijdelijke aanduiding zoals BACKUP_PASSWORD documenteert de vereiste zonder van het Compose-bestand een opslagplaats voor inloggegevens te maken.
Platte omgevingsbestanden zijn handig, maar kunnen eenvoudig in broncodebeheer, probleemoplossingsbundels of niet-versleutelde back-ups terechtkomen. Een actuele handleiding voor geheimenbeheer in Docker maakt onderscheid tussen lekken tijdens het bouwen van images, het rondzwerven van lokale .env-bestanden en blootstelling van de runtime-omgeving; dat zijn verschillende routes naar hetzelfde lek van inloggegevens.
Gebruik een secretsmanager, een door Compose ondersteund mechanisme voor geheime bestanden of een andere runtime-injectiemethode die geschikt is voor de afhankelijke service. Ga er niet van uit dat elke Jellyfin-instelling de conventie _FILE ondersteunt; gebruik injectie via bestanden alleen waar het specifieke onderdeel dit ondersteunt.
Voorkom dat geheimen in images, repositories en shellgeschiedenis terechtkomen
Sluit lokale bestanden met geheimen uit van zowel versiebeheer als de Docker-buildcontext. Als een bestand in .gitignore staat, voorkomt dat niet dat een brede COPY in een Dockerfile het bestand in een image plaatst wanneer .dockerignore het nog toestaat.
Geef langdurig geldige inloggegevens niet rechtstreeks mee op een opdrachtregel die in de shellgeschiedenis wordt opgeslagen. Echo geheimen niet tijdens het debuggen van de opstart. Vermijd het afdrukken van de volledige opgeloste omgeving in tickets of gedeelde chats wanneer één variabele voldoende is om het probleem te diagnosticeren.
Na een vermoedelijk lek is het verwijderen van de regel uit het nieuwste Compose-bestand geen herstelmaatregel. Roteer de blootgestelde inloggegevens, maak oude tokens waar mogelijk ongeldig, controleer de geschiedenis van repositories en images en verwijder de gelekte waarde uit toekomstige back-ups en diagnostische gegevens.
Ontwerp back-ups zo dat vereiste geheimen herstelbaar maar niet zomaar leesbaar zijn
Sommige geheimen maken deel uit van herstel. Een versleutelde back-up is nutteloos als het wachtwoord van de repository of de ontsleutelingssleutel samen met dezelfde server verloren gaat, en een herstelde proxy- of automatiseringsstack kan inloggegevens nodig hebben die niet alleen uit het Compose-recept kunnen worden gereconstrueerd.
Een praktische inventaris voor herstel bij self-hosting behandelt sleutels, tokens, herstelcodes en back-upwachtwoorden als volwaardig herstelmateriaal, terwijl de sleutels waarmee back-ups worden ontgrendeld buiten de back-upserver blijven. Dit verschilt van het plaatsen van een plat .env-bestand in elk archief.
Maak een manifest voor geheimherstel waarin elke vereiste inloggegeven wordt benoemd, samen met de eigenaar, de locatie van de gezaghebbende kopie, de manier waarop deze wordt hersteld of opnieuw uitgegeven en de back-up die ermee wordt ontgrendeld. Bewaar gevoelige waarden in een versleutelde wachtwoordmanager, een versleutelde back-upset of een afzonderlijk beveiligd herstelpakket met toegangscontroles die passen bij het huishouden.
Voorkom dat logs en probleemoplossingsbundels een tweede opslagplaats voor geheimen worden
URL's van proxyaanvragen, omgevingsdumps, foutopsporingsuitvoer van toepassingen en shelltranscripten kunnen tokens blootleggen, zelfs wanneer Compose schoon is. Zoek vóór het delen van logs naar autorisatieheaders, API-sleutels, tokens in querystrings, cookies, privéhostnamen en inloggegevens.
Richtlijnen voor logging adviseren om gevoelige velden te redigeren voordat telemetrie het systeem verlaat. Pas dezelfde regel toe op supportbundels voor thuisservers: bewaar het origineel lokaal als dat nodig is voor de diagnose, maar deel een geredigeerde kopie.
Beperk lezers van back-ups en logs afzonderlijk. Iemand die mediaback-ups kan lezen, heeft niet automatisch toegang nodig tot DNS-tokens of reverse-proxygegevens. Blootstelling van geheimen is evenzeer een probleem van toegangsbereik als van bestandsindeling.
Voer een lektest en een hersteltest samen uit
Maak een canary-geheim met een herkenbare nepwaarde, implementeer de stack en zoek die waarde in de Compose-map, de imagegeschiedenis, de uitvoer van containerinspectie, logs, de back-upcatalogus en een uitgepakte testherstelbewerking. Zo wordt zichtbaar waar de huidige workflow geheimen kopieert zonder een echte inloggegeven in gevaar te brengen.
Voer vervolgens de omgekeerde test uit: herstel de Jellyfin-stack naar een geïsoleerd doel met uitsluitend de gedocumenteerde herstelmaterialen. Als voor herstel een inloggegeven nodig is die alleen op de defecte host bestaat, bevat het ontwerp te weinig geheimen; als elke gewone back-up alle inloggegevens in platte tekst blootlegt, bevat het te veel geheimen.
De grens van minimale toegangsrechten van ZimaSpace is de laatste controle: elke service, back-uptaak, beheerder en elk herstelproces mag alleen de geheimen ontvangen die voor zijn rol vereist zijn. Roteer alles wat die grens onverwacht overschrijdt.
Ondersteuning & Tips
Meer om te lezen

Moet Jellyfin één gedeeld account of afzonderlijke huishoudaccounts gebruiken?
Kies Jellyfin-huishoudaccounts op basis van de identiteits-, toegangs-, ouderlijketoezichts- en herstelgrenzen die je nodig hebt.

Waarom blijft het geheugengebruik van Jellyfin hoog nadat het werk is voltooid?
Maak onderscheid tussen geheugengroei van het Jellyfin-proces en de Linux-cache, en onderzoek het alleen wanneer het geheugengebruik blijft stijgen of daadwerkelijk voor druk zorgt.

Signalen dat een Jellyfin-opslagindeling een herstelrisico begint te vormen
Controleer de opslagrollen van Jellyfin, scheid de actieve toestand van back-ups en opnieuw opbouwbare gegevens, en toon met een herstel aan dat de indeling...

