Пароли в чате? Как хранить секреты команды в git под замком

Где пароли лежат сейчас

Студия из пяти человек. Файл .env с ключами от базы и платёжки закреплён в рабочем чате. У двоих он лежит в «Загрузках». Подрядчик, с которым работали два года назад, до сих пор сидит в той же группе. Кто-то однажды закоммитил .env в репозиторий, потом удалил, но в истории он остался.

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

Репозиторий есть у всех. git-secret кладёт в него и секреты, только в зашифрованном виде.

Как работает git-secret

Это bash-утилита Никиты Соболева. Она шифрует файлы открытыми ключами допущенных людей, а расшифровывают их владельцы через свои секретные ключи GnuPG. Секретный ключ остаётся у человека и в репозиторий не попадает.

Порядок такой. git secret init создаёт папку .gitsecret. git secret tell почта добавляет первого человека. git secret add .env ставит файл на учёт и вносит его в .gitignore, чтобы открытая копия не улетела в коммит. git secret hide создаёт зашифрованный .env.secret, его уже можно коммитить. Читают командой git secret reveal. Hide советуют повесить на pre-commit хук, чтобы не забывать.

Ставится через brew install git-secret, есть пакеты для apt и yum, либо сборка из исходников командой make. Нужны bash, gawk, git, gpg и sha256sum. Лицензия по файлу LICENSE.md: MIT, Nikita Sobolev, 2016.

Кто имеет доступ

Список людей показывает git secret whoknows. Чтобы добавить человека, он экспортирует публичный ключ (gpg --armor --export), вы его импортируете и выполняете tell.

Сразу после tell новый человек файлы не прочитает. Они зашифрованы без его ключа. Кто-то из уже допущенных делает git secret reveal, затем git secret hide -d и коммитит результат. Документация отдельно предупреждает: публичный ключ нужно получать по надёжному каналу, иначе можно по ошибке дать доступ не тому.

Когда сотрудник уходит

Выполняете git secret removeperson почта, затем reveal, hide и коммит. Новые версии файлов этот человек уже не расшифрует. Старое название команды killperson: в версии 0.5.0 её переименовали в removeperson.

Репозиторий хранит историю. Прежние зашифрованные версии лежат в нём и в клоне бывшего сотрудника, а его секретный ключ остался при нём. README проекта говорит прямо: если человек мог скопировать секреты или ключи, меняйте и сами секреты. На деле это значит, что пароль базы, токены и API-ключи, которые он видел, нужно перевыпустить. Что человек видел, то он мог запомнить, с любым хранилищем. Остальные доступы разобраны в статье про увольнение сотрудника и доступы.

Передача проекта клиенту

У клиента или его технического специалиста есть пара ключей GnuPG. Он присылает публичный ключ, вы делаете tell, перешифровываете файлы и отдаёте репозиторий. После этого убираете себя и своих людей через removeperson. Секреты, которые видела студия, клиент потом перевыпускает.

Если клиент с GnuPG не работает, схема не взлетит. Тогда значения проще отправить одноразовыми ссылками и положить в его менеджер паролей, например Bitwarden.

Что есть кроме git-secret

sops тоже хранит зашифрованные файлы рядом с кодом. Лицензия MPL-2.0, проект из CNCF Sandbox, свежий релиз 3.13.3 от июля 2026. Понимает YAML, JSON, ENV, INI, шифрует ключами AWS KMS, GCP KMS, Azure Key Vault, age и PGP. Если у вас облачный KMS или удобнее age, чем GnuPG, sops подойдёт лучше.

Vault хранит секреты на сервере, ведёт журнал аудита и умеет выдавать временные доступы к базам и облакам. В LICENSE репозитория для версий от 1.15.0 стоит Business Source License: применять в работе можно, но нельзя продавать на его основе конкурирующий платный продукт. Нужен отдельный сервер и тот, кто им занимается.

Infisical даёт панель управления с облачной или собственной установкой. Код вне папок ee/ под MIT. Bitwarden Secrets Manager входит в семейство Bitwarden и отдаёт секреты приложениям по токену и SDK.

Для команды из трёх-десяти человек с парой репозиториев хватает файлов в git, и тогда выбирают между git-secret и sops. Когда нужен журнал «кто и когда прочитал», права на каждый секрет и автоматическая ротация, нужен сервер.

Что важно учесть

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

Журнала чтений нет: утилита работает на машине пользователя, сервера у неё нет. Git покажет, кто коммитил, но не кто расшифровывал.

GnuPG нужен каждому, и версии на машинах лучше держать одинаковыми: в документации описаны ошибки с keyring между разными версиями gpg. На Windows утилита работает через WSL, Cygwin или MSYS.

Состояние проекта на 8 октября 2026. Около 4 тысяч звёзд на GitHub. Последний релиз v0.5.0 вышел 5 июня 2022, в ветке master версия 0.5.1-alpha1. Свежие коммиты есть, но это обновления зависимостей и замена ссылок: по сообщению коммита от 28 сентября 2026, домен git-secret.io перешёл к постороннему сайту, актуальная документация живёт на sobolevn.me/git-secret.

Что можно сделать уже сейчас

Первое. Выпишите секреты одного проекта: что лежит в .env, у кого есть копия, кто видел значения.

Второе. Проверьте историю репозитория на случайно закоммиченные ключи и перевыпустите найденные. Удаление файла из последнего коммита ничего не меняет.

Третье. Заведите пилот на одном репозитории: tell для всех участников, hide в pre-commit, список whoknows в README.

Четвёртое. Впишите в регламент ухода сотрудника три пункта: removeperson, перешифровка, смена секретов. Если нужна помощь с регламентом и защитой, это моя работа по кибербезопасности.

Частые вопросы

Что делать, если сотрудник потерял секретный ключ?

Тот, у кого доступ есть, убирает старый ключ через removeperson, добавляет новый через tell, затем делает reveal, hide и коммит. Если ноутбук мог попасть в чужие руки, сами секреты тоже меняют.

Можно ли расшифровывать секреты в CI?

Да. Документация предлагает завести отдельный ключ GnuPG для CI, положить закрытую часть в переменную окружения сервера и вызвать reveal с паролем ключа. Версии gpg на сервере и у разработчиков должны совпадать.

Чем git-secret хуже обычного менеджера паролей?

Для людей он неудобнее: нет интерфейса и поиска. Зато секреты лежат рядом с кодом. Менеджер паролей лучше для общих логинов команды, git-secret для файлов, которые нужны приложению.

Коротко о главном

git-secret даёт простой порядок: секреты в репозитории зашифрованы, список допущенных видно командой, уход человека оформляется тремя шагами. Ограничения известны: общий доступ ко всем файлам, нет журнала, история остаётся. Если нужны права на каждый секрет и аудит, смотрите на серверные хранилища.

Хотите разобраться, где у вас лежат пароли и как передавать проекты без утечек? Напишите мне в Telegram слово «СЕКРЕТЫ». Посмотрим на ваши репозитории и соберём схему под вашу команду.