Docker Composen .env ei ole salaisuusholvi – siirrä avaimet secrets-tiedostoiksi

Siirrä salasana .env-tiedostosta erilliseen tiedostoon, määritä tiedosto Docker Compose -secretin lähteeksi ja anna secret vain sitä tarvitseville palveluille. Kontissa arvo löytyy polusta /run/secrets/db_password. Dockerin secrets-ohje kuvaa palvelukohtaisen pääsyn, tiedostoliitoksen ja Linux-kontteja koskevan rajauksen.

Jotta sovellus käynnistyy edelleen, sen on myös luettava uusi tiedosto. Joissakin konttikuvissa tähän käy _FILE-päätteinen asetus, kuten PostgreSQL-kuvan POSTGRES_PASSWORD_FILE; muissa sovelluksissa tiedoston luku on toteutettava itse. Pidä salasanan arvo siirrossa samana kuin toimivassa tietokantayhteydessä ja poista vanha ympäristömuuttuja vasta, kun yhteys toimii uuden asetuksen kautta.

.env välittää asetuksia, secret rajaa salasanan saajat

Projektin .env-tiedosto antaa arvoja Compose-tiedoston muuttujakorvaukseen. Se ei yksin siirrä jokaista arvoaan konttiin. Jos compose.yaml sisältää esimerkiksi POSTGRES_PASSWORD: "${DB_PASSWORD}", Compose sijoittaa korvatun salasanan db-palvelun ympäristömuuttujaan. env_file puolestaan lisää tiedoston muuttujat suoraan palvelun ympäristöön. Dockerin ympäristömuuttujaohje neuvoo käyttämään arkaluonteisille arvoille secrets-mekanismia.

Pidä .env-tiedostossa tavalliset asetukset, kuten palvelun toimintatila tai tietokannan nimi, jos käytät niitä muuttujakorvaukseen. Salasanan tai API-avaimen kohdalla ero on käytännöllinen: ympäristömuuttuja sisältää itse arvon, kun taas _FILE-asetus sisältää vain konttiin liitetyn tiedoston polun. Tiedosto on silti suojattava siinä koneessa, jolla Compose käyttää sitä; secret-määritys ei salaa lähdetiedostoa eikä korvaa sen käyttöoikeuksia.

Ennen ja jälkeen: sama salasana eri jakelutavalla

Seuraava on ehdollinen esimerkki PostgreSQL-palvelusta. compose.yaml-rivit ovat YAMLin yhden rivin esitystapaa, jotta ennen- ja jälkeen-tilanteen ero näkyy suoraan. postgres:18 on esimerkin kuvaviite: jos käytössäsi on toinen versio, säilytä nykyinen kuvaviite molemmissa vaiheissa. Säilytä myös nykyiset levyliitokset, verkot ja muut palveluasetukset; esimerkki näyttää vain salasanan jakeluun liittyvät kentät.

Ennen, .env: DB_PASSWORD=esimerkki-vaihda-tama

Ennen, compose.yaml: {services: {db: {image: postgres:18, environment: {POSTGRES_USER: example_admin, POSTGRES_PASSWORD: "${DB_PASSWORD}", POSTGRES_DB: appdb}}}}

Tässä db-palvelu saa varsinaisen salasanan POSTGRES_PASSWORD-ympäristömuuttujassa. Luo seuraavaksi secrets-hakemistoon tiedosto db_password ja kirjoita siihen nykyinen toimiva salasana. Esimerkkisalasanaa ei pidä käyttää oikeassa järjestelmässä. Jos sovellus käyttää samaa tunnusta, myös sen on saatava täsmälleen sama arvo uudesta tiedostosta.

Jälkeen, compose.yaml: {services: {db: {image: postgres:18, environment: {POSTGRES_USER: example_admin, POSTGRES_PASSWORD_FILE: /run/secrets/db_password, POSTGRES_DB: appdb}, secrets: [db_password]}}, secrets: {db_password: {file: ./secrets/db_password}}}

Ylätason secrets-määritys nimeää lähdetiedoston. db-palvelun secrets-luettelo myöntää kyseiselle palvelulle pääsyn; ylätason määritys yksin ei tee tiedostoa kaikkien konttien käyttöön. POSTGRES_PASSWORD_FILE sisältää polun, josta PostgreSQL-kuva lukee arvon, eikä itse salasanaa. POSTGRES_USER ja POSTGRES_DB jäävät tässä ennalleen, joten esimerkissä muuttuu vain salasanan toimitustapa.

Sovellus tarvitsee oman pääsyn ja lukutavan

Jos erillinen sovelluspalvelu kirjautuu tietokantaan tällä tunnuksella, lisää db_password myös sen omaan secrets-luetteloon. Silloin sama tiedosto liitetään myös sovelluskonttiin polkuun /run/secrets/db_password. Palvelu, jonka secrets-luettelosta db_password puuttuu, ei saa tätä liitosta. Älä anna tietokannan salasanaa esimerkiksi välityspalvelulle, joka ei käytä tietokantayhteyttä.

Tarkista sovelluksen konttikuvan ohjeista, tunteeko se _FILE-päätteisen muuttujan ja mikä sen tarkka nimi on. Compose ei tulkitse päätettä sovelluksen puolesta: jos kuva odottaa vain DB_PASSWORD-muuttujaa, pelkkä DB_PASSWORD_FILE-määritys ei muuta sen toimintaa. Itse ylläpidetyssä sovelluksessa asetusten lukukoodi voidaan muuttaa avaamaan /run/secrets/db_password. Jos koodi poistaa lukemastaan tiedostosta lopun rivinvaihdon, varmista, ettei käsittely muuta salasanan muita merkkejä.

Tietokantapalvelu ja sovelluspalvelu voivat tarvita samaa arvoa eri nimisissä asetuksissa. PostgreSQL-kuvalle esimerkin POSTGRES_PASSWORD_FILE on tuettu, mutta sovelluksen DB_PASSWORD_FILE on vain mahdollinen nimi, ei yleinen Compose-ominaisuus. Tee muutos molempiin palveluihin ennen kuin poistat vanhan DB_PASSWORD-arvon .env-tiedostosta. Näin tiedoston olemassaolo, pääsy siihen ja sovelluksen lukutapa voidaan varmistaa yhdessä.

Tiedosto-oikeudet ja Linux-rajaus

Secret liitetään konttiin vain luettavana tiedostona, mutta alkuperäinen secrets/db_password säilyy isäntäkoneella. Rajaa sen ja hakemiston käyttöoikeudet niin, että vain tarvittava käyttäjä voi lukea arvon, ja jätä tiedosto pois versionhallinnasta. Varmista samalla, että kontissa ajava prosessi pystyy lukemaan liitetyn tiedoston; liian tiukat oikeudet voivat estää käynnistymisen.

Älä yritä korjata tiedostolähteen oikeuksia lisäämällä Compose-määritykseen uid-, gid- tai mode-kenttiä. Compose-palvelumäärityksen secrets-kohta kertoo, että nämä asetukset ohitetaan tiedostolähteessä, koska liitos tehdään bind mountina. Sama dokumentaatio kuvaa tiedoston palvelukohtaisen, vain lukuun tarkoitetun liitoksen. Docker Composen tämä secrets-tapa koskee Linux-kontteja, joten ohjetta ei voi siirtää sellaisenaan Windows-konttiin.

Vaihda asetus ilman salasanojen vaihtumista

1. Kirjoita nykyinen toimiva salasana tiedostoon secrets/db_password. Varmista tiedoston sijainti, käyttöoikeudet ja se, ettei sisältöön tule tahatonta ylimääräistä merkkiä.
2. Lisää ylätason secret-määritys ja myönnä pääsy db-palvelulle. Vaihda POSTGRES_PASSWORD-asetuksen tilalle POSTGRES_PASSWORD_FILE, mutta pidä käytössä sama konttikuva ja nykyiset tietokannan levyliitokset.
3. Jos sovellus kirjautuu samalla salasanalla, myönnä sillekin secret ja määritä sen tukema tiedostonlukutapa. Tarkista kummankin palvelun asetukset ennen käynnistystä.
4. Tarkista Compose-rakenne komennolla docker compose config. Älä jaa tulostetta, jos kokoonpanossa on vielä muita salaisia ympäristömuuttujia. Käynnistä palvelut ja varmista, että sovelluksen tietokantayhteys muodostuu.

Jo alustetun tietokannan tunnuksen salasana on säilytettävä samana tässä siirrossa. PostgreSQL-kuvan käynnistysasetus ei vaihda valmiin tietokannan käyttäjän salasanaa: jos tiedostoon kirjoitetaan uusi arvo samalla kun tietokannassa on vanha, kirjautuminen epäonnistuu. Kun yhteys toimii tiedoston kautta, poista vanha arvo .env-tiedostosta ja muista palvelulle salasanan syöttävistä määrityksistä.

Lue myös:

• Google Docs avasi Markdown-tiedostot – muunnosvaihe jäi pois
• Nasdaq sijoitti One Tradingiin – 24/7-osakefutuurien summa jäi salaiseksi
• Docker vai Podman? Käynnistysnopeus ei ratkaise, käyttöoikeudet ratkaisevat