Så förhindrar du att Jellyfin-hemligheter läcker in i Compose-filer eller säkerhetskopior

Behandla inte en Compose-fil, ett Git-arkiv och ett säkerhetskopieringsarkiv som likvärdiga platser för lagring av Jellyfin-autentiseringsuppgifter. Distribueringsreceptet kan kopieras brett, medan hemliga värden bör ha en mer begränsad livscykel, åtkomstgräns och återställningsväg.

För en Jellyfin-stack kan känsligt material omfatta API-nycklar, autentiseringsuppgifter för reverse proxy eller tunnlar, token för DNS-leverantörer, lösenord till säkerhetskopieringsarkiv, krypteringsnycklar, databasautentiseringsuppgifter för stödtjänster samt andra token som används av insticksprogram eller automatisering. Inventera dem först och avgör sedan vilka som måste kunna återskapas, vilka som måste kunna återställas och vilka som helt enkelt kan utfärdas på nytt.

Separera referenser till hemligheter från själva hemlighetsvärdena

Håll Compose deklarativt: tjänstbilder, nätverk, monteringar, portar, variabelnamn och referenser till hemligheter hör hemma i filen; råa autentiseringsuppgifter gör det inte. En platshållare som BACKUP_PASSWORD dokumenterar kravet utan att göra Compose-filen till ett lager för autentiseringsuppgifter.

Oformaterade miljöfiler är praktiska men kopieras lätt till källkodshantering, felsökningspaket eller okrypterade säkerhetskopior. En aktuell genomgång av hantering av Docker-hemligheter skiljer mellan läckage från byggtidens avbildningar, spridning av lokala .env-filer och exponering av runtime-miljön – olika vägar till samma läcka av autentiseringsuppgifter.

Använd en hemlighetshanterare, en Compose-kompatibel mekanism för hemlighetsfiler eller en annan metod för injicering vid körning som passar den beroende tjänsten. Anta inte att alla Jellyfin-inställningar stöder konventionen _FILE; använd filbaserad injicering endast där den specifika komponenten stöder det.

Förhindra att hemligheter hamnar i avbildningar, arkiv och skalkommandots historik

Undanta lokala hemlighetsfiler från både versionshantering och Dockers byggkontext. Att en fil står i .gitignore hindrar inte en bred COPY i Dockerfilen från att placera den i en avbildning om .dockerignore fortfarande tillåter den.

Skicka inte långlivade autentiseringsuppgifter direkt på en kommandorad som sparas i skalkommandots historik. Skriv inte ut hemligheter vid felsökning av uppstart. Undvik att skriva ut hela den upplösta miljön i ärenden eller delade chattar när en enda variabel räcker för att diagnostisera problemet.

Efter en misstänkt läcka är det inte tillräckligt att ta bort raden från den senaste Compose-filen. Rotera den exponerade autentiseringsuppgiften, ogiltigförklara gamla token där det är möjligt, granska arkivens och avbildningarnas historik och ta bort det läckta värdet från framtida säkerhetskopior och diagnostik.

Utforma säkerhetskopior så att nödvändiga hemligheter kan återställas men inte läsas utan vidare

Vissa hemligheter ingår i återställningen. En krypterad säkerhetskopia är värdelös om lösenordet till arkivet eller dekrypteringsnyckeln försvinner med samma server, och en återställd proxy- eller automatiseringsstack kan behöva autentiseringsuppgifter som inte kan återskapas enbart från Compose-receptet.

En praktisk återställningsinventering för självhosting behandlar nycklar, token, återställningskoder och säkerhetskopieringslösenord som centralt återställningsmaterial, samtidigt som nycklarna som låser upp säkerhetskopiorna förvaras utanför servern som säkerhetskopieras. Det skiljer sig från att lägga en oformaterad .env-fil i varje arkiv.

Skapa ett manifest för återställning av hemligheter som anger varje nödvändig autentiseringsuppgift, dess ägare, var den auktoritativa kopian finns, hur den återställs eller utfärdas på nytt och vilken säkerhetskopia den låser upp. Förvara känsliga värden i en krypterad lösenordshanterare, en krypterad säkerhetskopieuppsättning eller ett separat skyddat återställningspaket med åtkomstkontroller som passar hushållet.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Se till att loggar och felsökningspaket inte blir ett andra hemlighetslager

Begärans-URL:er till proxyer, miljödumpar, programmets felsökningsutdata och skalkommandots utskrifter kan avslöja token även när Compose är rent. Innan du delar loggar bör du söka efter auktoriseringshuvuden, API-nycklar, token i frågesträngar, kakor, privata värdnamn och autentiseringsuppgifter.

Riktlinjer för loggning rekommenderar att känsliga fält maskeras innan telemetrin lämnar systemet. Tillämpa samma regel på supportpaket för hemservrar: behåll originalet lokalt om det behövs för diagnos, men dela en maskerad kopia.

Begränsa läsare av säkerhetskopior och loggar separat. En person som kan läsa säkerhetskopior av medier behöver inte automatiskt ha åtkomst till DNS-token eller autentiseringsuppgifter för reverse proxy. Exponering av hemligheter är lika mycket ett problem med åtkomstomfattning som med filformat.

Genomför ett läckagetest och ett återställningstest tillsammans

Skapa en testhemlighet med ett igenkännbart falskt värde, distribuera stacken och sök efter värdet i Compose-katalogen, avbildningshistoriken, containerns inspektionsutdata, loggarna, säkerhetskopiekatalogen och en extraherad teståterställning. Det visar var det aktuella arbetsflödet kopierar hemligheter utan att en verklig autentiseringsuppgift riskeras.

Genomför sedan det omvända testet: återställ Jellyfin-stacken till ett isolerat mål med endast de dokumenterade återställningsmaterialen. Om återställningen kräver en autentiseringsuppgift som endast finns på den havererade värden är designen för hemlighetsfattig; om varje vanlig säkerhetskopia exponerar alla autentiseringsuppgifter i klartext är den för hemlighetsrik.

ZimaSpaces gräns för minsta privilegium är den slutliga kontrollen: varje tjänst, säkerhetskopieringsjobb, administratör och återställningsprocess bör endast få de hemligheter som krävs för dess roll. Rotera allt som oväntat passerar den gränsen.