Как безопасно хранить и использовать секреты

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

Так, например разработчики не должны видеть пароли от баз данных, в том числе и от стейдж и от продовых. Они, как правило, работают локально и этого им достаточно. Бывают, конечно, исключения.

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

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

Если мы говорим про инфраструктурные секреты, то там есть разные подходы:

1. Можно использовать интеграцию с тем же vault для тех инструментов, которые используются для деплоя: helm, helmfile, terraform. Тут непосредственно секреты хранятся в виде пути: pass: ref+vault://databases/postgres/gitlab#DB_PASSWORD

2. Еще одним решением может быть sops (https://github.com/getsops/sops), то есть хранение в зашифрованном виде.

Не столь важно какой подход вы выберите, важно запомнить, что ни при каких обстоятельствах секреты не должны попадать в код, и уж тем более на публичные git репозитории.

У нас был кейс, когда данные SMTP (AWS SES) попали в открытый доступ на github. Среагировали мы быстро, не более получаса прошло, но было уже поздно, суточная квота писем (а это 500К) была успешно использована спамерами.