Комментарии 16
Все хорошо, но теперь нужна инфраструктура для хранения и деплоя ключей для секретов.
В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.
вас тут немного обманули, дело в том, что sops поддерживает и KMS(AWS,GCP)-ключи, Vault.
По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault: sops publish $file
sops полностью автономный, и пока что, самый админолюбивый из всего, что я видел для работы с секретами.
Во-первых он в гите, т.е. секреты соответствуют версии приложения.
Во-вторых диффы можно смотреть без содрогания.
В третьих, даже если нет diff view, то даже в зашифрованном виде диффы можно смотреть без содрогания.
Как же хорошо было жить на азуре, где все блин на порядки проще...
Сейчас перешел на проект с AWS и это ужас - хелмы, датадоги (хорошая штука, конечно), аппвееры, куча еще какой-то фрагментированной лабуды.
Признаюсь: о чем статья и зачем все это нужно, если есть Azure KeyValult - не понял.
Также стоит включить на уровне настроек репозитория или push хуков проверку на то, что в репозиторий не залили секрет в открытом виде. Например, с помощью https://github.com/Yelp/detect-secrets
Вроде всегда получается не хранить ничего в репозитории, просто везде использую переменные окружения
А зачем вообще хранить секретные данные в репозитории? Мы в репе храним только примеры настроечных файлов, ни никогда не храним реальные настройки: у каждого разработчика они могут быть свои, плюс свои у тестовых сред и боевого сервера.
А где вы их храните и как они попадают в нужную среду ?
Один раз в нужную среду рачками загружаем и настраиваем и больше не трагаем
Вижу несколько проблем:
1) Как организовать версионирование секрета и откат/накат
2) Всё-таки где-то должны храниться исходные данные, которые вы помещаете в нужную среду
В случае если мы какие-то сторонние решения используем, то возникает вопрос их высокой доступности и кто их обслуживает. В случае хранения в репе обеспечение доступности сервиса лежит не нас.
Читал статью и сравнивал с Sealed secrets, который использую я. Репа: https://github.com/bitnami-labs/sealed-secrets
В рамках куба не понятно почему вы городите огород)
В мире вне куба sops интересно, в копилку
Прячем секреты в репозитории с помощью helm-secrets, sops, vault и envsubst