Pull to refresh

Comments 16

Все хорошо, но теперь нужна инфраструктура для хранения и деплоя ключей для секретов.

В случае helm secrets и sops все хранится в репе и ничего дополнительно не нужно. И потом можно разворачивать инфраструктурные решения и перезжать туда.

вас тут немного обманули, дело в том, что sops поддерживает и KMS(AWS,GCP)-ключи, Vault.

По коммитам vault завезли "16 Jul 2020" я честно говоря пропустил этот момент, т.к. инструмент начал использовать гораздо раньше. KMS опять же не целевая архитектура для корпоратов: я долгое время работал в банке и внешние системы не рассматриваю. Спасибо, что указали на неточность, я в документации по sops вычитал интересную вещь: он может запушить секреты из файла в vault: sops publish $file

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

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 интересно, в копилку

Даже в кубе кто-то эти CRD должен развернуть и настроить, если нет девопса на проекте то приётся кого-то просить с уважением и ждать. Пробежался по решению внешне выглядит как оператор vault и по мне лучше его и внедрить т.к. он более популярен. Но за решение спасибо, почитаю еще раз внимательнее

Sign up to leave a comment.