Docker Compose secrets нису само .env — приступ се даје по сервису

За лозинку или API кључ који је сервису потребан током рада, Docker Compose secret омогућава да се вредност испоручи као датотека, уместо као environment променљива. Приступ се додељује сваком сервису посебно: Docker упутство за Compose secrets описује монтирање датотеке у /run/secrets/ и изричиту доделу преко атрибута secrets.

Датотека .env служи Compose-у као извор вредности за замену у конфигурацији; само њено постојање не претвара вредности у тајне. Ако compose.yaml проследи API_KEY из .env кроз environment, кључ завршава у environment променљивој контејнера. Docker упутство о интерполацији показује и да команда docker compose config може да испише разрешене вредности. Прелазак на secret зато захтева промену конфигурације и начина на који апликација чита кључ.

Миграција лозинке или API кључа

Следећи пример је условни: сервис api користи API_KEY, а сервису worker тај кључ није потребан. Полазна поставка има ред API_KEY=вредност у .env и унос API_KEY: ${API_KEY} под services.api.environment у compose.yaml. Циљ је да api чита садржај датотеке /run/secrets/api_key, док worker ту датотеку не добија.

1. Припремите изворну датотеку. Упишите само вредност кључа у ./secrets/api_key, без префикса API_KEY= и без навода који служе синтакси .env датотеке. Ограничите ко на хосту може да чита ту датотеку и изоставите је из контроле верзија. Проверите и да ли је директоријум са тајнама обухваћен поступком изградње слике или резервним копијама: вредност не треба случајно пренети на још једно место.
2. Дефинишите secret. На највишем нивоу compose.yaml додајте secrets, у њему назив api_key и извор file: ./secrets/api_key. Тако Compose зна коју датотеку треба да користи. Декларација на највишем нивоу сама не даје приступ сервисима.
3. Доделите приступ сервису api. Под services.api додајте атрибут secrets са ставком api_key. Под services.worker не додајте ту ставку. Из services.api.environment уклоните API_KEY: ${API_KEY}, да стари начин испоруке не остане активан упоредо са новим.
4. Промените читање у апликацији. Подесите api да отвори /run/secrets/api_key и прочита вредност из датотеке, па примените измењену Compose конфигурацију поновним подизањем сервиса. Ако апликација или слика изричито подржава променљиву API_KEY_FILE, у њу може да се упише путања до датотеке. Суфикс _FILE је договор који подржавају неке слике, а не аутоматска могућност сваке апликације.

После промене, у разрешеној конфигурацији сервиса api не би требало да остане environment унос који садржи вредност кључа. Вредност немојте исписивати у терминал или лог ради провере. Довољно је утврдити да апликација може да прочита датотеку и обави радњу за коју јој је кључ потребан.

Шта значи приступ по сервису

У условном примеру api добија монтирану датотеку јер је api_key наведен у његовом списку secrets; worker нема ту доделу. То је битно када више сервиса дели исти Compose пројекат: заједничка конфигурација не подразумева да сваки контејнер добија сваки акредитив. Додељивање треба да прати стварну потребу сервиса за тајном.

Та граница важи између сервиса, али не решава сва права приступа унутар контејнера. Процес који може да чита монтирану датотеку може да добије кључ, па су важна и права приступа датотеци и начин рада апликације. Ако је сама апликација компромитована, нападач може доћи до вредности коју она користи. Описани начин испоруке преко појединачно монтиране датотеке намењен је Linux контејнерима.

Где тајна може остати после преласка

OWASP смернице за управљање тајнама наводе да environment променљиве могу бити доступне процесима и завршити у логовима или системским dump датотекама. Монтирање датотеке уклања вредност из environment путање у приказаном примеру, али не брише претходне копије нити спречава апликацију да је поново открије. Ризици се разликују зависно од места на којем вредност остаје:

• Изворни код: вредност више не мора да стоји у .env поред кода, али изворна датотека за secret и даље може случајно ући у репозиторијум. Ако је кључ раније био унет у историју измена, брисање из текуће верзије не повлачи већ откривену вредност; кључ треба опозвати или заменити код његовог издаваоца.
• Слика контејнера: secret који се испоручује при покретању не захтева уписивање вредности у Dockerfile. Ипак, копирање изворне датотеке током изградње или прослеђивање кључа кроз ARG и ENV представља засебан пут изложености. Ако је кључ потребан само током изградње, за ту фазу постоје build secrets.
• Процеси: уклањање API_KEY из environment поставки затвара тај начин читања вредности. Апликација ипак мора да учита кључ из датотеке у меморију, а други процес са одговарајућим правима приступа датотеци може да је прочита.
• Логови: вредност више неће бити исписана само зато што је исписан environment унос из полазног примера. Ако апликација бележи садржај датотеке, захтев који садржи кључ или поруку о грешци са осетљивим подацима, исти кључ може завршити у логу.
• Системске dump датотеке: после читања датотеке вредност може остати у меморији процеса. Снимак те меморије при паду апликације може садржати тајну, чак и када је више нема у environment променљивој.

Остаје и изворна копија на хосту: у овом примеру Compose монтира датотеку наведену под file. Њена права приступа, место чувања и резервне копије морају се уредити одвојено. Сам назив secret у конфигурацији не значи да је хост датотека аутоматски шифрована.

Када је потребан шири систем управљања

Compose secret решава испоруку постојеће вредности сервису који је користи. За издавање краткотрајних акредитива, ротацију, опозив и евиденцију приступа изворној тајни потребни су додатни поступци или наменски систем за управљање тајнама. Избор зависи од тога колико често се кључ мења, ко сме да га изда и колико брзо изложени кључ мора да се укине.

Ако је стара вредност већ доспела у репозиторијум, лог или dump датотеку, премештање исте вредности у /run/secrets/ не уклања претходну изложеност. Тада је део миграције и замена самог кључа, уз уклањање старог environment уноса и задржавање доделе secret-а само сервису коме је потребан.

Прочитајте и:

• Промена Google лозинке не избацује OAuth апликацију — приступ се укида посебно
• Docker Remote API без TLS-а даје практично root приступ — овако се затвара
• Workday купује C1.ai — приступ AI агената постаје део кадровског система