Skrivnosti v Dockerju: ENV ostane v sliki, secret mount pa ne

Gesel, žetonov in ključev ne vpisujte v ENV v Dockerfile. Dockerjeva navodila za gradnjo opozarjajo, da sta ENV in ARG neprimerna za poverilnice, ker lahko njihove vrednosti ostanejo v končni sliki; secret mount pa je na voljo le med ukazom gradnje. Poverilnico, ki jo aplikacija potrebuje med delovanjem, ji posredujte posebej ob zagonu, po možnosti kot datoteko z omejenim dostopom.

Odločilno je, kdaj je skrivnost potrebna. Žeton za prenos zasebnega paketa potrebuje graditelj, geslo za podatkovno zbirko pa delujoča aplikacija. Začasni priklop med gradnjo ne dostavi gesla aplikaciji po zagonu; skrivnost, posredovana ob zagonu, tudi ne odstrani vrednosti, ki je bila že zapisana v sliko.

Dockerfile in okolje delujočega vsebnika

ENV določi okoljsko spremenljivko v konfiguraciji slike. Če Dockerfile vsebuje dejansko geslo, se njegova vrednost prenese z artefaktom in jo lahko vidi oseba z ustreznim dostopom do slike. ARG ni varna zamenjava: čeprav praviloma ne postane privzeta okoljska spremenljivka delujočega vsebnika, se njegova vrednost lahko pojavi v zgodovini slike, metapodatkih ali rezultatih ukazov gradnje.

Vrednost, podana šele ob zagonu vsebnika, ni bila vgrajena v Dockerfile. Še vedno pa živi v okolju procesa in konfiguraciji delujočega vsebnika. Smernice OWASP opozarjajo, da so okoljske spremenljivke lahko dostopne procesom ter vključene v dnevnike ali izpise pomnilnika, zato za skrivnosti dajejo prednost drugim načinom posredovanja, kadar so na voljo.

Razlika je pomembna tudi pri odpravljanju napak. Če program izpiše svoje nastavitve, lahko razkrije vrednost, prejeto ob zagonu, čeprav je sama slika čista. Datotečni priklop zmanjša potrebo po okoljski spremenljivki z geslom, ne prepreči pa razkritja, če aplikacija vsebino datoteke sama zapiše v dnevnik.

BuildKit: skrivnost samo za korak gradnje

Pri dostopu do zasebnega registra paketov posredujte poverilnico graditelju z možnostjo docker build --secret id=repo_token,src=./secrets/repo_token . V Dockerfile jo potreben ukaz prebere z RUN --mount=type=secret,id=repo_token,required=true. Privzeta pot med izvajanjem tega ukaza je /run/secrets/repo_token; required=true prekine korak, če skrivnost manjka.

To je pogojni primer, v katerem je repo_token lokalna datoteka, ne dejanska poverilnica v ukazu ali Dockerfile. Upravljalnik paketov naj datoteko prebere neposredno med ustreznim korakom RUN. Priklop po koncu koraka izgine, zato žeton ne postane del slike zgolj zato, ker ga je graditelj potreboval.

Začasnost priklopa ima jasno mejo: ukaz lahko žeton še vedno kopira v konfiguracijsko datoteko, predpomnilnik ali dnevnik. Preverite, kam orodje, ki prenaša paket, zapisuje poverilnice, in odstranite njegove občutljive izhode še v istem koraku. Če poznejši korak kopira celoten imenik z nastalo konfiguracijo v končno sliko, secret mount tega prenosa ne ustavi.

Compose: datoteka za izbrano storitev

Za lokalni razvoj lahko v Compose določite skrivnost z virom file: ./secrets/db_password in jo dodelite le storitvi, ki jo potrebuje. Dockerjev opis Compose secrets določa, da storitev dodeljeno skrivnost prejme kot priklopljeno datoteko pod /run/secrets/db_password. Dostop je vezan na izrecno navedbo skrivnosti pri storitvi, zato je ne dodajajte storitvam, ki gesla ne uporabljajo.

Aplikacija mora znati prebrati vsebino te datoteke oziroma sprejeti pot do nje. Pripona _FILE v imenu nastavitve je dogovor, ki ga podpirajo le nekatere slike in aplikacije; sama po sebi ne spremeni vrednosti okoljske spremenljivke v datotečni priklop. Pred uporabo zato preverite dokumentacijo konkretne aplikacije.

Compose secret ne šifrira izvorne datoteke. Datoteka ./secrets/db_password ostane na gostitelju, kjer jo morate zaščititi z ustreznim lastništvom in dovoljenji. Ne vključite je v repozitorij, za gradnjo pa jo izključite tudi iz običajnega konteksta z .dockerignore. Izključitev iz repozitorija in izključitev iz gradbenega konteksta sta ločeni nastavitvi; preveriti je treba obe.

CI in produkcija: ločite gradnjo od zagona

V CI naj žeton za zasebne pakete prihaja iz shrambe skrivnosti izvajalnega okolja in v gradnjo vstopi prek --secret. V Dockerfile naj bo le identifikator priklopa. Dostop do poverilnice omejite na nalogo, ki jo potrebuje, in pazite na ukaze, ki izpisujejo vhodne vrednosti ali celotno okolje.

Produkcijsko geslo aplikaciji dodelite ob zagonu prek mehanizma uporabljene platforme ali namenske shrambe skrivnosti. Kadar aplikacija podpira branje iz datoteke, lahko vrednost ostane zunaj njenega začetnega procesnega okolja. Omejite dostop na ustrezno storitev in račun; datoteka je še vedno berljiva vsakomur, ki ima zanjo dovoljenje v tem okolju.

Gradbeni žeton in produkcijsko geslo naj imata različna namena in pravice. Zamenjava vrednosti v shrambi tudi ne zagotavlja, da jo delujoči proces že uporablja: aplikacija jo lahko prebere samo ob zagonu ali pa podpira ponovno branje. Način osvežitve preverite za konkretno aplikacijo, preden prekličete staro poverilnico.

Pregled slike in ravnanje ob razkritju

Po gradnji preglejte docker history --no-trunc ime_slike in docker image inspect ime_slike. V konfiguracijskem polju Config.Env iščite dejanske poverilnice, v zgodovini pa ukaze ali vrednosti, ki jih razkrijejo. Preverite tudi datoteke v končni sliki: prazen Config.Env še ne pomeni, da namestitveno orodje ni shranilo žetona drugam.

Pregled dopolnite pri viru. Preverite, kdo lahko bere lokalno datoteko, ali je izključena iz repozitorija in gradbenega konteksta, kateri storitvi je dodeljena ter ali se vrednost pojavlja v dnevnikih CI ali aplikacije. Če najdete poverilnico v že razdeljeni sliki ali objavljenem izpisu, jo zamenjajte in omejite dostop do prizadetih artefaktov. Popravek Dockerfile zaščiti naslednje gradnje, že izdane poverilnice pa ne prekliče.

Preberite tudi:

• Docker Compose ali Kubernetes: visoka razpoložljivost ima strošek upravljanja
• Docker brez roota: varnejši daemon lahko upočasni omrežje