Рано или поздно компания приходит к тому, что нужно как-то централизованно хранить и защищать чувствительные данные: пароли, ключи, токены и прочее.
При этом нужно учитывать тот факт, что в определенный момент, кроме централизованного хранения, встает вопрос управления этими данными: управление доступами, выделение ответственных лиц, ведение аудитных логов, версионирование. При этом важно не забыть про удобство управления, изменения и распространения.
Компании все разные. Где-то всего одна-две продуктовые команды, которые, в принципе, не знают, зачем им вообще как-то централизованно хранить секреты и тем более не задумываются об их версионировании и управлении доступами, т.к. все имеют доступ везде. Другие компании уже прошли все этапы принятия неизбежного и дошли до уровня, когда столкнулись со всеми особенностями управления секретами.
Мы с вами вместе пройдемся по этапам роста компании, которая уже приняла Kubernetes как неизбежное и столкнулась с проблематикой Secrets Management, рассмотрим различные подходы и инструменты, которые помогут в решении этой проблемы, выделим плюсы и минусы этих подходов, а также варианты их комбинаций.
В частности:
* посмотрим, почему не стоит хранить секреты в открытом виде в Git;
* уберем секреты в переменные CI/CD-инструментов (Gitlab, Github, Jenkins и т.д.);
* захотим все-таки хранить секреты в Git, но зашифруем (SOPS, Sealed Secrets);
- вспомним о проблеме хранения ключей шифрования (Yandex Lockbox, CI/CD, AWS KMS и другие).
* подрастем до Hashicorp Vault;
* рассмотрим интеграцию с CI/CD tools и GitOps Tools;
* использование Vault Injector;
* External Secrets Operator;
* наши разработчики придут до интеграции приложений напрямую с Vault.