Делитесь Compose-файлом для VPN? Уберите секреты из отрендеренной копии

Каждый раз, когда вы делитесь Compose-файлом, существуют два артефакта: тот, который вы написали, и тот, который инструмент рендерит после подстановки переменных. Второй часто чувствительнее первого, и именно его люди вставляют в отчёт о проблеме, не читая. Если вы просматриваете только исходный файл, вы просматриваете не тот документ.

Прежде чем решать, что удалять, сравните, что может содержать каждая копия.

Отрендеренная модель — другой документ

Compose разрешает переменные окружения, объединяет файлы переопределения и создаёт действующую конфигурацию, которую читатель уже не отличит от значений, написанных вручную. Ссылка, например имя переменной в источнике, в выводе становится самим токеном учётной записи. Структура, которая делает файл полезным для диагностики, переживает это преобразование; переживает и всё то, чего в нём никогда не должно было быть.

Отрендерьте файл сами, прежде чем прикреплять его, и относитесь к этому выводу как к проверяемому артефакту. Если вы не можете его отрендерить, вы не можете знать, что собираетесь публиковать.

Секреты находятся не только в поле ключа

Начните с очевидного: закрытые ключи, предварительно общие ключи, токены, пароли и URL-адреса подключения со встроенными учётными данными. Затем посмотрите на всё, на что ссылается файл, потому что ссылка — это не удаление. Файл окружения, смонтированный в сервис, файл конфигурации, привязанный с хоста, метка с токеном и аргумент команды с паролем — всё это путешествует вместе с развёртыванием, даже когда YAML выглядит чистым. Ключ, вставленный в переменную с успокаивающим именем, остаётся ключом.

Пути хоста и имена сервисов выдают второй вид информации. Имя домашнего каталога, внутреннее имя хоста или диапазон сети могут идентифицировать человека или организацию, не содержа ни единой учётной записи, и этот контекст стоит удалять по той же причине.

Объявление секрета — это не сам секрет

Объекты секретов Compose отделяют объявление от материала: сервис получает путь или цель, а содержимое живёт в другом месте. Сохранить объявление, заменив материал, обычно правильный обмен, потому что проверяющему нужно видеть, что секрет существует и как он смонтирован. Выжить не должно само содержимое.

Метки и комментарии заслуживают такого же обращения. Комментарий, указывающий, какой путь в хранилище держит производственный ключ, говорит атакующему, куда смотреть, даже если не содержит ключа.

Сохраните форму, чтобы файл по-прежнему помогал диагностике

Удаление, которое убирает сетевой режим, версию образа или настройки возможностей, даёт файл, с которым никто не сможет отлаживать. Замените чувствительные значения и сохраните связи: какой сервис что монтирует, к какой сети подключается, какое устройство ему нужно. Именно эту часть читатель использует, чтобы объяснить пропавший маршрут или недоступное устройство. Это и та версия, которую коллега может сравнить со своим работающим развёртыванием.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

Не развёртывайте отредактированную копию так, будто это работающий оригинал. Это описание, а описание, отредактированное для вида безопасности, откажет так, как выглядят ошибки конфигурации.

Если материал был раскрыт, замените его

Удаление вложения не удаляет копии, которые другие уже сделали, а зеркала и кеши держат свои. Используйте процесс отзыва и замены у издателя для всего, что утекло, затем обновите развёртывание. Порядок важен, потому что замена сначала и отзыв потом оставляют окно с двумя действующими учётными данными.

В темах поддержки начинайте с точной ошибки, версии образа, сетевого режима и одной несекретной настройки, которая важна. Эта комбинация объясняет пропавшее устройство или сломанный маршрут гораздо чаще, чем ключ.