Docker: секрети без витоків — припиніть зберігати паролі в .env

October 5, 2025 • February 3, 2026 • Читання: 4 хв • Views: 6

Було корисно?

Репорти про інциденти завжди починаються однаково: «Можливо, облікові дані були скомпрометовані.» Спочатку рідко пишуть «були».
Ми блукаємо в невизначеності, намагаючись купити впевненість часом. Потім хтось знаходить курячу печатку: файл .env,
вбудований у шар образу, надрукований через debug-вивід або прикріплений до запиту в підтримку, бо «так було простіше».

Контейнери не створили проблему розкиданих секретів — вони просто прискорили її. Якщо ви все ще використовуєте змінні оточення (або гірше,
.env) як основний механізм розповсюдження секретів, ви не «тримаєте все просто». Ви наперед пишете собі постмортем.

Що йде не так з .env і змінними оточення

Будьмо конкретними. Змінні оточення не «природно небезпечні». Вони природно проміскуїтні.
Вони поширюються. Їх копіюють, логують і показують у місцях, де ви не планували їх показувати. Різниця важлива.

1) Рuntime контейнера трактує env як метадані, а метадані люблять подорожувати

Оточення контейнера опиняється в багатьох місцях: у визначенні оркестратора, у виводі інспекції, у переліку процесів,
у дампах аварій та на «дружніх» сторінках для налагодження. Деякі з цих місць мають власні контролі доступу. Багато — ні.

2) Змінні env легко вивести, якщо у вас є будь-який плацдарм

Якщо зловмисник отримує виконання коду всередині контейнера, читання файлів під виділеним маунтом секретів може вимагати зусиль,
але читати env тривіально: воно вже там, успадковане процесом, зазвичай читабельне цим процесом і часто випадково виводиться стандартними інструментами.

3) Файли .env — це пастка для робочого процесу

Файл .env робить локальну розробку приємною. Він також робить «просто закоміть це для демо» на відстані одного повідомлення в Slack.
Навіть якщо ваш репозиторій приватний, секрети не лишаються приватними. Їх форкають, зеркалять, кешують і клонують на ноутбуки,
що подорожують через аеропорти й кав’ярні.

Один із найпоширеніших режимів відмови — це не атака. Це перевантажений інженер, який додає printenv для налагодження,
а потім забуває видалити. Так «приватний» пароль бази даних опиняється в централізованих логах, доступних усім з правом читання.

Жарт короткий #1: Якщо ваш секрет у .env, то це не секрет — це настрій.

4) Шари образу та кеші збірки вас видадуть

Якщо ви передаєте секрети як аргументи збірки або копіюєте .env у контекст збірки, ви можете опинитися з обліковими даними всередині
шарів образу. Навіть якщо ви потім їх видаляєте, історія шарів може їх містити. Ви не «rm -f» шляхом із реєстру на основі контенту.

5) Змінні env стирають межу між конфігурацією та секретами

Номер порту — це конфігурація. Пароль бази даних — секрет. Обробляйте їх по-різному. Операційна проблема в тому, що
ENV= виглядає однаково для обох, тож команди в кінці кінців дають секретам той самий життєвий цикл, що й конфігу: закомічено в репо,
шаблонізація в CI, копіювання між середовищами. Так девізначення стають продакшн-секретами, а продакшн-секрети — дев-ноутбуками.

Факти та історичний контекст (те, чого ми постійно перевчаемо)

Ось конкретні факти й контекстні пункти, що важливі, коли ви вирішуєте, як керувати секретами, і чому «всі ж використовують env vars»
— несерйозний аргумент.

«12-factor app» популяризував env vars для конфігурації, щоб збірки були незмінними й розгортання — портативним. Воно не
писалося як загальна підтримка довготривалих продакшн-секретів.
Docker Swarm додав вбудовані секрети (як файлові маунти), щоб вирішити реальну проблему витоку env через
docker inspect і логи.
Kubernetes Secrets історично були просто base64-кодованими об’єктами за замовчуванням; шифрування в стані вимагало явної конфігурації.
Індустрія знову навчилась, що «закодовано» ≠ «зашифровано».
Системи збірки стали кращими, бо мусили: BuildKit додав секретні маунти спеціально тому, що передача секретів як
аргументів збірки їх витікала в шари образу.
Реєстри — назавжди: коли секрет потрапив у шар реєстру або кеш, видалення тега не гарантує видалення даних з усіх дзеркал і кешів.
Процесні середовища — спостережувані на багатьох системах. На Linux середовище процесу можна прочитати через
/proc/<pid>/environ користувачам з достатніми привілеями. Вам не потрібно бути «root» в абстракції; потрібна комбінація можливостей і доступу до неймспейсу.
Системи логування змінили радіус ураження: один витік пароля в логах контейнера тепер стає пошуковим артефактом,
який реплікується по кластерах і рівнях збереження.
Ротація секретів — це функція надійності, а не лише безпековий фарс. Команди, що ніколи не ротають, дізнаються про це під час інциденту,
у найгіршому часовому тиску.

Практична модель загроз: як секрети витікають у контейнеризованих системах

Моделювання загроз не потребує білборда й триденного воркшопу. Потрібно перерахувати шляхи, якими секрети витікають, і вирішити, які з них
ви можете запобігти, які — виявити, а які — лише зменшити.

Шлях витоку A: контроль версій і розповсюдження артефактів

Де це відбувається: закомічений .env, зразок env з реальними значеннями, «тимчасова» гілка, вставка в внутрішнє wiki.
Чому відбувається: зручність, плутанина між конфігом і секретом, відсутність скануючих ворот.
Тип виправлення: запобігання (gitignore + сканування + політика) і виявлення (сканери секретів, моніторинг репо).

Шлях витоку B: логи CI та метадані збірки

Де це відбувається: крок пайплайна виводить env, тести друкують рядки підключення, аргументи збірки зберігаються в логах.
Чому відбувається: «налагодження», неправильна гучність виводу, наївні скрипти.
Тип виправлення: запобігання (маскування, без echo, файлові маунти) і виявлення (очищення логів і алерти).

Шлях витоку C: інспекція контейнера та API оркестратора

Де це відбувається: docker inspect, конфіги Compose, специфікації сервісів Swarm, pod specs Kubernetes.
Чому відбувається: доступ до метаданих ширший, ніж має бути доступ до секретів.
Тип виправлення: запобігання (використовуйте об’єкти секретів) і зменшення (затягніть RBAC для inspect/describe).

Шлях витоку D: компрометація під час виконання та латеральний рух

Де це відбувається: RCE в додатку, SSRF до метаданих, відкриті debug-ендпоінти.
Чому відбувається: додатки — це додатки; вони ламаються.
Тип виправлення: зменшення (найменші привілеї, короткоживучі креденшіали, окрема ідентичність для сервісу) і виявлення (анормалій).

Шлях витоку E: бекапи та снапшоти

Де це відбувається: томи з вбудованими секретами, дампи баз даних з обліковими даними, снапшоти файлової системи.
Чому відбувається: секрети збережені як звичайні файли без контролю життєвого циклу.
Тип виправлення: запобігання (не зберігайте секрети в шляхах даних додатка), зменшення (шифруйте бекапи), виявлення (аудит).

Операційна правда така: ви захищаєте секрети не лише від атак. Ви захищаєте їх від схильності ваших систем копіювати, кешувати та індексувати все підряд.

Одна цитата, бо вона стосується секретів так само, як і інцидентів: «Надія — це не стратегія.» — Vince Lombardi

Що робити замість цього: файлові секрети, Docker secrets і розумні налаштування за замовчуванням

Мета не в чистоті. Мета — зменшити ймовірність і радіус ураження витоків. Кращий дефолт на контейнерних платформах:
маунтіть секрети як файли, тримайте їх поза шарами образу, не потрапляйте їх у логи і зробіть ротацію нормальною частиною деплою.

Опція 1: Docker Swarm secrets (корисні навіть якщо ви «не використовуєте Swarm»)

Docker secrets у Swarm — першокласний механізм: зашифровані в стані raпт-логу Swarm, доставляються задачам по mutual TLS
і маунтяться в контейнери як in-memory файли (зазвичай під /run/secrets). Вони не видні в
docker inspect так, як змінні оточення.

Велика перевага: секрети — це дані з життєвим циклом, а не рядки, розсипані по YAML.

Опція 2: Docker Compose secrets (з застереженнями)

Compose підтримує секрети в специфікації, але поведінка залежить від бекенда. При роботі з локальним Docker-движком (не-Swarm),
секрети Compose часто мапляться на bind-маунти, що краще за env-варіанти, але все ж означає, що секрет існує десь на диску.
Це може бути прийнятно для розробки і невеликих розгортань, якщо робити це свідомо.

Опція 3: Зовнішні менеджери секретів (найкраще для серйозного продакшну)

Якщо у вас більше ніж один кластер, більше ніж одна команда або вимоги комплаєнсу, вам потрібен спеціальний менеджер секретів
(сховище провайдера хмари, Vault-подібна система або сервіс на HSM). Рантайм тоді отримує короткоживучі креденшіали,
використовуючи ідентичність, а не спільний статичний пароль.

Ця стаття сфокусована на Docker, але принцип універсальний: доступ на основі ідентичності краще за спільні статичні секрети.

Опція 4: Якщо мусите використовувати env vars — обмежуйте шкоду

Використовуйте env vars тільки для незахищеної конфігурації.
Якщо доводиться передавати секрет через env (успадковані додатки трапляються), робіть його короткоживучим і ротуйте агресивно.
Ніколи не друкуйте середовище в логах.
Обмежте, хто може інспектувати контейнери й читати логи. «Тільки для читання» часто не безпечний режим.

Жарт короткий #2: Покладання паролів у .env — як підписати ключ від будинку «HOUSE KEY» і сховати його під килимком.

Як файлові секрети змінюють дизайн вашого додатку (на краще)

Читання секрету з файлу змушує зіткнутися з життєвим циклом. Ви можете замінити файл. Ви можете ротаціювати його. Ви можете контролювати права доступу.
І ваш додаток може перезавантажувати конфіг без повної збірки.

Практичний патерн:

Маунтьте секрет як /run/secrets/db_password
Додаток читає його при старті, опційно перечитує при SIGHUP або через інтервал
Ротація секретів стає: оновити об’єкт секрету → перезапустити задачі або тригернути reload

Практичні кроки: команди, виводи та рішення (12+)

Це та частина, яку люди пропускають. Не робіть так. Різниця між «ми використовуємо секрети» і «ми фактично не їх витікаємо» — у верифікації.
Кожне завдання нижче містить команду, приклад виводу, що означає цей вивід і рішення, яке ви приймаєте.

Завдання 1: Знайти `.env` файли, яких не має бути

cr0x@server:~$ find . -maxdepth 4 -type f -name ".env" -o -name "*.env"
./.env
./services/api/.env

Значення: У вас є файли середовища в дереві; принаймні один на корені репо, а саме там відбуваються випадковості.

Рішення: Залишайте лише не-секретні приклади файлів (.env.example) у репо; видаліть реальні з контролю версій
і ротуйте все, що колись там жило.

Завдання 2: Перевірити, чи секрети фіксувалися в історії git

cr0x@server:~$ git log --name-only --pretty=format: | grep -E '(^|/)\.env$' | head
.env
services/api/.env

Значення: Ці файли були закомічені раніше. Навіть якщо зараз видалені, вони можуть лишатися в історії й клонованих репо.

Рішення: Вважайте всі облікові дані, що колись там були, скомпрометованими; ротуйте їх. Потім чистіть історію лише якщо розумієте
операційний радіус перезапису git-історії.

Завдання 3: Пошукати в репо типові патерни секретів

cr0x@server:~$ grep -RIn --exclude-dir=.git -E "(PASSWORD=|API_KEY=|SECRET=|TOKEN=|BEGIN PRIVATE KEY)" .
./services/api/.env:3:DB_PASSWORD=summer2023

Значення: У вас щонайменше один літеральний секрет у відкритому тексті. Якщо він у робочому дереві, швидше за все він є і в інших місцях.

Рішення: Видаліть, ротируйте, додайте шлюзи сканування і припиніть вважати grep вашою програмою безпеки.

Завдання 4: Інспектувати запущений контейнер на витік секретів через env

cr0x@server:~$ docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"
NAMES          IMAGE                STATUS
api-1          myorg/api:1.8.2      Up 3 hours
db-1           postgres:16          Up 3 hours

cr0x@server:~$ docker inspect api-1 --format '{{json .Config.Env}}'
["NODE_ENV=production","DB_USER=app","DB_PASSWORD=summer2023","DB_HOST=db"]

Значення: Пароль видимий будь-кому з правом інспектувати контейнери. Це право часто ширше, ніж ви думаєте.

Рішення: Видаліть секретні env var; замініть на файлові маунти секретів; затягніть доступ до Docker API.

Завдання 5: Перевірити, чи секрет присутній всередині контейнера як файл (кращий патерн)

cr0x@server:~$ docker exec api-1 ls -l /run/secrets
total 4
-r--r----- 1 root root 16 Jan  3 10:12 db_password

Значення: У вас змонтований файл секрету з обмеженими правами. Хороший початок.

Рішення: Переконайтесь, що ваш додаток працює під користувачем, який може його читати (членство в групі), а не під root «бо так працює».

Завдання 6: Перевірити, що додаток не логгує змінні оточення

cr0x@server:~$ docker logs --tail 200 api-1 | grep -E "(DB_PASSWORD|API_KEY|SECRET|TOKEN)" || echo "no obvious secrets in tail"
no obvious secrets in tail

Значення: У останніх 200 рядках немає очевидних секретних рядків. Це не доказ, але базова перевірка здорового глузду.

Рішення: Продовжуйте: перевірте структуровані логи, шляхи помилок і стартові банери. Потім додайте автоматичні перевірки в CI.

Завдання 7: Виявити витік секретів при рендерінгу конфігу Compose

cr0x@server:~$ docker compose config | sed -n '1,120p'
services:
  api:
    environment:
      DB_HOST: db
      DB_PASSWORD: ${DB_PASSWORD}

Значення: Compose все ще прокладає секрети через environment. Навіть якщо вони взяті з вашого шеллу, вони опиняються в конфігу.

Рішення: Перенесіть секрети з environment у secrets: з файловими маунтами.

Завдання 8: Створити і використати секрет у Swarm (реальний життєвий цикл)

cr0x@server:~$ docker swarm init
Swarm initialized: current node (r8k3t2...) is now a manager.

cr0x@server:~$ printf "correct-horse-battery-staple\n" | docker secret create db_password -
z1p8kq3m9gq9u5a0l0xw2v3p1

Значення: Тепер секрет існує в контрольній площині Swarm. Ви не записали його на диск.

Рішення: Використовуйте це для продакшн-розподілу, якщо Swarm підходить вашому операційному моделі; інакше — зовнішній менеджер секретів.

Завдання 9: Підтвердити, що секрети маунчені там, де очікується (і не в env)

cr0x@server:~$ docker service create --name api --secret db_password --env DB_USER=app alpine:3.20 sh -c "env | grep -E 'DB_PASSWORD' || echo 'no DB_PASSWORD in env'; ls -l /run/secrets"
no DB_PASSWORD in env
total 4
-r--r----- 1 root root 29 Jan  3 10:20 db_password

Значення: Секрет доступний як файл, а не як змінна оточення. Це те, що вам потрібно.

Рішення: Оновіть додаток, щоб читати файл і перестаньте очікувати env var.

Завдання 10: Ротація секрету у Swarm (правильна, але болюча частина)

cr0x@server:~$ docker secret ls
ID                          NAME          CREATED          UPDATED
z1p8kq3m9gq9u5a0l0xw2v3p1    db_password   5 minutes ago    5 minutes ago

cr0x@server:~$ printf "new-password-value\n" | docker secret create db_password_v2 -
m2c1v0b8n7x6a5s4d3f2g1h0j9

cr0x@server:~$ docker service update --secret-rm db_password --secret-add source=db_password_v2,target=db_password api
api
overall progress: 1 out of 1 tasks
1/1: running   [==================================================>]
verify: Service converged

Значення: Ви створили новий секрет і оновили сервіс для його використання. Секрети Swarm незмінні; ротація — це заміна й перевпровадження.

Рішення: Включіть ротацію в runbook для деплою. Якщо ваша система не терпить перезапусків задач, виправте це спочатку.

Завдання 11: Перевірити, чи випадково секрет не потрапив у шар образу

cr0x@server:~$ docker history --no-trunc myorg/api:1.8.2 | head -n 8
IMAGE                                                                     CREATED        CREATED BY                                      SIZE      COMMENT
sha256:3b1c...                                                             2 days ago     /bin/sh -c #(nop)  COPY . /app               14.2MB
sha256:a9f0...                                                             2 days ago     /bin/sh -c #(nop)  RUN npm ci                 48.1MB

Значення: Якщо ваш .env у контексті збірки і був скопійований у образ, він може бути в шару COPY.

Рішення: Переконайтесь, що .dockerignore виключає файли-секрети з контексту збірки; перебудуйте і перевпровадьте; ротуйте все, що могло бути скопійоване.

Завдання 12: Перевірити, що `.dockerignore` блокує очевидні файли з секретами

cr0x@server:~$ cat .dockerignore
.env
*.env
**/.env
**/*.env
id_rsa
*.pem

Значення: Ви явно виключаєте типові носії секретів з контексту збірки.

Рішення: Залишайте так. Також перевірте, що ваш CI не ін’єктує секрети в контекст збірки всупереч цьому.

Завдання 13: Перевірити, хто може звертатись до Docker socket (aka «хто може стати root»)

cr0x@server:~$ ls -l /var/run/docker.sock
srw-rw---- 1 root docker 0 Jan  3 08:01 /var/run/docker.sock

cr0x@server:~$ getent group docker
docker:x:998:deploy,ci-runner

Значення: Члени групи docker фактично мають привілеї, еквівалентні root на хості.
Якщо вони можуть інспектувати контейнери, вони можуть читати env, маунтити файлові системи і витягувати секрети.

Рішення: Розглядайте доступ до Docker socket як привілейований; зменшіть членство, аудитуйте його і ізолюйте CI-ранери.

Завдання 14: Підтвердити, що секрет не передається через Compose `--env-file`

cr0x@server:~$ ps aux | grep -E "docker compose.*--env-file" | grep -v grep
deploy    21984  0.2  0.1  23844  9152 ?        Ss   10:02   0:00 docker compose --env-file /srv/app/.env up -d

Значення: Хтось явно ін’єктує env файл під час запуску. Цей файл, ймовірно, живе на диску на хості і може бути в резервних копіях.

Рішення: Замініть на секрети, змонтовані з захищеної локації, і приберіть хост-збережені плейнтекстні env файли з шляхів бекапів.

Завдання 15: Сканувати логи на патерни з високим ризиком без дампу всього

cr0x@server:~$ docker logs api-1 2>&1 | grep -E "password=|Authorization: Bearer|BEGIN PRIVATE KEY" | head
Authorization: Bearer eyJhbGciOi...

Значення: У логах знайшлися bearer-токени. Це життєвий креденшіл у багатьох системах, і тепер він пошуковий артефакт.

Рішення: Розглядайте це як інцидент: ротуйте токени, очищуйте/обмежуйте логи, додавайте фільтри логування і виправляйте шлях коду, який логгує заголовки.

Плейбук швидкої діагностики

Коли ви підозрюєте витік секретів, у вас немає часу на філософію. Вам потрібен тісний цикл: підтвердити, оцінити масштаб, локалізувати, ротувати і запобігти повторенню.
Ось порядок дій, що найчастіше допомагає.

Перший крок: підтвердити шляхи витоку (хвилини)

Перевірте метадані контейнера: docker inspect на предмет секретів у env. Якщо вони є, припускайте, що інформація доступна всім з доступом до Docker API.
Перевірте логи на відкритий текст: пошукайте патерни токенів/паролів. Якщо знайдете — вважайте логи скомпрометованими сховищами даних.
Перевірте вивід CI: останній успішний пайплайн на предмет «дружніх» кроків для налагодження або проблем з маскуванням секретів.

Другий крок: оцінити радіус ураження (десятки хвилин)

Куди ще пішов секрет? шари образів, артефакти збірки, архіви підтримки, сторінки wiki, чати.
Хто має доступ? користувачі сокету Docker, читачі метаданих оркестратора, читачі логів, читачі реєстру.
Чи придатний він для повторного використання? статичні паролі гірші за короткоживучі токени. Але короткоживучі токени в логах теж погано.

Третій крок: локалізувати і ротувати (години)

Ротуйте креденшіали починаючи з найпотужніших (ключі хмари, адмінкреденшіали БД, підписні ключі).
Перевпровадьте, щоб прибрати використання env і переключитись на файлові секрети або зовнішній запит секретів у рантаймі.
Зменшіть поверхні спостереження: затягніть RBAC, зменшіть гучність логів, забороніть патерни printenv через лінтери.

Реальність з вузьким місцем: більшість команд витрачають першу годину на суперечки, чи «це реальний витік». Перестаньте це. Спочатку ротуйте, потім дискутуйте.

Типові помилки: симптом → корінь проблеми → виправлення

Помилка 1: «Ми використовуємо .env, але він не закомічений»

Симптоми: секрет з’являється в diff PR або компрометація ноутбука розробника викликає паніку з ротацією.

Корінь: секрети у відкритому тексті у робочих каталогах копіюються, архівуються, прикріплюються та бекапляться.

Виправлення: Використовуйте .env тільки для локальної не-секретної конфігурації; перенесіть секрети в OS keychain, зовнішній менеджер або Compose/Docker секрети.

Помилка 2: «Гаразд, тільки ops можуть виконувати docker inspect»

Симптоми: аудитори питають, хто має доступ до Docker, і ви не можете швидко відповісти; підрядники читають env контейнерів.

Корінь: доступ до сокету Docker ширший, ніж задумано (CI-ранери, тимчасовий доступ, загальні jumpbox).

Виправлення: Розглядайте Docker API як привілейований; мінімізуйте членство в групі docker; ізолюйте CI; використовуйте секрети, а не env.

Помилка 3: Передача секретів під час збірки

Симптоми: пароль з’являється в docker history або відновлюється з шарів реєстру.

Корінь: використання ARG або копіювання секретних файлів в контекст збірки; видалення пізніше не стирає шари.

Виправлення: Використовуйте BuildKit secret mounts для потреб тільки під час збірки; ніколи не запікайте рантайм-секрети в образи; забезпечуйте .dockerignore.

Помилка 4: «Ми змонтували файл секрету, отже все ок»

Симптоми: секрет все ще потрапляє в логи або додаток падає й видає дамп конфігу з вмістом секретного файлу.

Корінь: додаток читає секрет і друкує його (прямо або опосередковано) під час обробки помилок, або debug-ендпоінти відкривають конфіг.

Виправлення: Редагуйте чутливі поля; вимкніть debug в продакшні; додайте тести, що падають, якщо секрети з’являються в логах.

Помилка 5: Довгоживучі спільні паролі між середовищами

Симптоми: витік в деві викликає ротацію в проді; команди бояться ротації, бо це ламає все.

Корінь: один обліковий запис використовується в dev/stage/prod і між сервісами; відсутні межі ідентичності.

Виправлення: Унікальні креденшіали на середовище і бажано на сервіс; віддавайте перевагу короткоживучим токенам; реалізуйте ротацію як рутинний деплой.

Помилка 6: Збереження секретів у томах, що бекапляться

Симптоми: відновлення з бекапу виявляє старі креденшіали; безпека запитує, чому секрети в снапшотах.

Корінь: секрети записані в директорії даних додатка; система бекапів захоплює все.

Виправлення: Маунтьте секрети у виділені рантайм-шляхи, як /run/secrets; виключайте секретні шляхи з бекапів; все одно шифруйте бекапи.

Три короткі корпоративні історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Середній SaaS мав чистий розподіл відповідальності між «платформою» й «аплікаційною» командами. Платформа володіла Docker-хостами й CI.
Аплікаційна команда володіла кодом сервісу й Compose-файлами. Усі вірили, що їх межа безпечна.

Аплікаційна команда встановила DB_PASSWORD через змінні оточення в Compose, джерело — захищене CI-змінне сховище. Вони вважали:
«CI-сховище безпечне, отже секрет безпечний.» Вони не були недбалими. Вони були буквальними.

Платформна команда додала скрипт для on-call: він запускав docker inspect і архівував вивід під час інцидентів.
Це допомагало діагностувати ліміти пам’яті, цикли рестарту та теги образів. Але воно також архівувало кожну змінну оточення для кожного контейнера,
включно з паролями баз даних і API-токенами. Архів потрапив у внутрішнє об’єктне сховище для артефактів інцидентів.

Через кілька тижнів контрактору дали права на читання артефактів інцидентів, щоб допомогти з перфоманс-дослідженнями. Він нічого не зробив злісного.
Він просто мав доступ до того, що там було. Безпека знайшла секрети в архівах, і компанія отримала проблему розкриття та проект з ротації в термін.

Неправильне припущення було не в «контракти погані». Воно було в «секрети в env видимі тільки під час виконання». На практиці env-секрети стають
метаданими, а метадані стають артефактами. Виправлення було нудне: перейти на файлові секрети, редагувати пакети діагностики й розглядати
«вивід інспекції» як чутливий.

Міні-історія 2: Оптимізація, що обернулася проти

Інша компанія керувала флотом дрібних сервісів. Розгортання були частими, і вони хотіли прискорити rollout. Хтось запропонував «оптимізацію»:
будувати раз і розгортати скрізь, і уникати рестартів, дозволивши додатку динамічно перезавантажувати конфіг з env. Звучало хитро.

Вони додали легкий ендпоінт для підтримки: /debug/config. Він повертав ефективну конфігурацію для діагностики misroutes,
feature flags і upstream endpoints. Він був за гейтом внутрішньої мережі, і «лише SRE» міг до нього дістатися. Ви вже бачите, куди це привело.

Помилка рутингу випадково відкрила цей ендпоінт через спільний внутрішній проксі, яким користувалися багато команд. Не в інтернеті, але в достатньо широкій зоні.
Хтось, що налагоджував свій сервіс, натрапив на ендпоінт, побачив JSON з креденшіалами і повідомив про це.

Оптимізація провалилась, бо env-орієнтована «динамічна конфіг» проштовхнула секрети в той сам канал, що й звичайна конфіг. Ендпоінт debug не мав чіткої сепарації.
Він просто виливав конфіг.

Ремедіація була болючою, але прямою: прибрати секрети з env, змонтувати їх як файли, переробити вивід debug так, щоб явно виключати секрети,
і ввести ідентичності для кожного сервісу, щоб випадкове відкриття не призводило до компрометації всього флоту.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Фінансово-орієнтована компанія (достатньо регульована, щоб дбати, але не з нескінченним штатом) рано прийняла політику:
«Усі секрети — файли, усі файли живуть в одній директорії, і ця директорія ніколи не включається в діагностичні пакети.»
Це була та сама нудна правила, про які люди скаржаться, поки воно не врятує.

Вони використовували Docker Swarm secrets для частини робочих навантажень і зовнішній менеджер секретів для решти. У будь-якому разі рантайм-шлях був консистентним:
/run/secrets/<name>. Додатки були зобов’язані читати з цього шляху. Це не було опційно.

Під час складного аутеджу старший інженер попросив «все»: вивід inspect контейнерів, логи і снапшоти файлової системи проблемного ноду.
Команда швидко зібрала їх. Безпека перед тим переглянула пакет, перш ніж ділитися з вендором. Перегляд не знайшов жодних креденшіалів.
Не тому, що всі були дуже обережні в моменті, а тому що система була спроєктована так, щоб зробити «обережність» режимом за замовчуванням.

Нудна практика зробила дві речі: зменшила кількість місць, де могли з’явитися секрети, і спростила аудит. Коли ви можете сказати:
«секрети живуть тут і тільки тут», ви можете сканувати ту межу, застосовувати права й виключати її з бекапів і діагностичних пакетів.

Ніхто не писав внутрішній блог про цю політику. Вона була занадто нудною. Вона все одно запобігла вторинному інциденту під час основного інциденту,
а це той виграш, що не завжди видно в дашбордах, але зберігає компанії.

Контрольні списки / покроковий план

Покроковий план: міграція з .env на файлові секрети (фокус на Docker)

Проведіть інвентаризацію секретів в env: перелічіть, які контейнери/сервіси мають env-змінні, що схожі на секрети
(паролі, токени, приватні ключі).
Визначте стандартний шлях для маунту секретів: оберіть /run/secrets і дотримуйтеся його.
Оновіть додатки: навчіть додатки читати DB_PASSWORD_FILE=/run/secrets/db_password або прямо читати файл.
Віддавайте перевагу конвенції «_FILE», якщо потрібно зберегти конфіг через env без впровадження значень секретів.
Реалізуйте секрети у вашій платформі:
- Swarm: docker secret create + маунти секретів у сервісах.
- Compose (не-Swarm): використовуйте secrets:, якщо підтримується, інакше bind-маунт зі захищеної директорії хосту з жорсткими правами.
- Зовнішній менеджер: забирайте секрети в рантаймі за ідентичністю; записуйте в tmpfs; маунтіть у контейнер.
Ротируйте під час міграції: не використовуйте старі значення «тільки для перехідного періоду». Припускайте, що старі env-шляхи скомпрометовані.
Затягніть поверхні спостереження: приберіть ендпоінти dump конфігу; редагуйте логи; обмежте, хто може інспектувати контейнери.
Додайте guardrails у CI: проваливайте збірки, якщо .env або патерни секретів виявлені в контексті збірки або репо.
Практикуйте ротацію: проводьте drills з ротації щоквартально. Перший раз не повинен бути під час інциденту.

Чекліст: як виглядає «добре» в продакшні

Секрети не присутні у виводі docker inspect.
Секрети не в образах (перевірено через docker history і контролі контексту збірки).
Секрети не в логах (періодичні перевірки й автоматичне сканування).
Ротація — рутинна операція деплою з runbook і тестованим відкатом.
Доступ до сокету Docker / метаданих оркестратора аудитується і мінімізований.
Секрети унікальні для середовища й, бажано, для ідентичності сервісу.

ЧаПи

1) Чи прийнятні змінні оточення для секретів інколи?

Іноді — для успадкованих додатків, короткоживучих токенів або перехідного періоду. Але вважайте це технічним боргом з дедлайном.
Якщо секрет довготривалий і високопроцедурний (адмін-пароль БД, ключ підпису), не кладіть його в env.

2) Хіба змонтований файл секрету все одно читає додаток, то в чому різниця?

Різниця — у площині експозиції. Env витікає в метадані, вивід інспекції і випадкові логи частіше. Файли можна захистити правами,
виключити з діагностики і ротаціювати шляхом заміни без переписування конфігів.

3) Чи працюють Docker secrets без Swarm?

Не в повному Swarm-сенсі. Compose підтримує концепцію секретів, але в залежності від режиму це може стати bind-маунтом.
Це все одно може бути краще за env vars, але ви маєте розуміти, де плейнтекст зберігається на диску.

4) А що з патернами типу `DB_PASSWORD_FILE` — вони безпечні?

Це прагматичний компроміс: env містить лише шлях до файлу, а не саме значення секрету. Секрет все одно потребує безпечного джерела й маунту.
Цей патерн також зберігає консистентність конфігу додатку між платформами.

5) Як запобігти запіканню секретів в образи?

Виключайте секретні файли за допомогою .dockerignore, уникайте передачі секретів через ARG і використовуйте BuildKit secret mounts
для потреб під час збірки. Потім перевіряйте через docker history --no-trunc і сканування реєстру.

6) Як ротувати секрети з мінімальним даунтаймом?

Використовуйте двофазну ротацію де можливо: додайте новий креденшіал, розгорніть підтримку обох, перемкніть трафік, потім приберіть старий.
Для Swarm секретів це зазвичай означає створення _v2 і оновлення сервісу, а потім виведення _v1.

7) Якщо хтось побачив секрет в логах один раз — чи дійсно потрібно роти?

Так. Логи реплікуються, зберігаються й доступні для перегляду з причин, не пов’язаних із безпекою. Якщо він з’явився хоч раз, ви не можете гарантувати,
що його повністю видалили. Ротуйте і виправляйте шлях логування.

8) Які права мають мати файли секретів усередині контейнерів?

Тільки читання для процесу, що їх потребує, ідеально — через групове читання з виділеною групою. Уникайте доступу для всіх.
Не запускайте весь додаток як root лише для читання файлу.

9) Як переконати команду, що «приватний репо» — не сховище секретів?

Запитайте, хто має доступ сьогодні, хто матиме доступ через квартал і де зберігаються клони. Репо призначені для реплікації.
Сховища секретів створені для контролю доступу і аудиту.

10) Чи вирішують файлові секрети всі проблеми?

Ні. Вони зменшують поширені шляхи витоків. Вам все одно потрібні найменші привілеї, сегментація, короткоживучі креденшіали де можливо і гігієна логування.
Але це сильний дефолт, який запобігає багатьом самокритичним помилкам.

Висновок: наступні кроки, що справді зменшують ризик

Перестаньте ставитися до .env як до нешкідливої зручності. У продакшні це магніт для проблем: він витікає в репо, логи, артефакти
і вивід інспекції. І найгірше — це відчуття норми, поки воно не перестає бути нормою.

Практичні наступні кроки:

Проведіть аудит запущених сервісів на предмет секретних env var за допомогою docker inspect; приберіть їх.
Переключіть секрети на файлові маунти (/run/secrets) через Swarm secrets, Compose secrets або зовнішній менеджер секретів.
Ротируйте все, що колись жило в .env, CI-логах або діагностичних пакетах.
Затягніть, хто має доступ до Docker socket і хто читає логи; аудитуйте обидва шляхи.
Зробіть ротацію рутинною операцією деплою, а не екстреним ритуалом.

Вам не потрібна ідеальна безпека. Вам потрібні системи, що не копіюють ваші коштовності у всі підручні інструменти.
Ось що означає «секрети без витоків» в реальному світі.