Отличный спор, великолепная аргументация, потрясающий выбор цитат. Но реальность такова, что нам работать с Lockbox через Ansible удобнее и проще, используя собственный модуль для работы с api. На этом предлагаю разойтись :)
Спасибо за лестный отзыв. Аспекты безопасности использования кастомных модулей - это отдельная тема, раскрыть которую в рамках одной статьи, мне кажется, будет сложно. Тем более, что текст посвящён конкретной точке приложения такого подхода, а вопрос безопасности собственных модулей для Ansible надо рассматривать шире.
Прекрасно знаю, для чего нужен terraform и как работать с инфраструктурой, но в данном случае мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service. Давайте посмотрим на то, как в провайдере terraform для Lockbox реализована работа с секретами и применим к реальной ситуации. Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли. И вот вы пишете кучу однотипных манифестов с ресурсами по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret.html, складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест, который создаст версию секрета с нужными изменениями по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret_version.html. А секреты изменяются часто.
Итого, имеем обширный инфраструктурный код, который будет неизбежно дрейфовать (человеческий фактор). Поступившись декларативностью и добавив в модуль простую проверку https://github.com/krang404/ycm/blob/26195a909b3dfea87aeb88b545049cb9c97fe5c4/plugins/modules/yc_lockbox.py#L330 , мы можем подавать на вход только данные для секрета и не городить большую кучу инфрового кода. И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор. Сюда входит и невозможность предоставить разделённый доступ к секретам (вы даёте доступ всей команде сразу и никак не можете гранулировано его распределить), и отсутствие контроля за безопасностью хранения секретов на локальных хостах разработчиков, ну и просто безалаберность коллеги (кто-нибудь обязательно коммитнет в репо незашифованный файл). Безусловно, все проблемы можно нивелировать, но вопрос: какой ценой? Проще всего - не хранить секреты в репозитории (даже зашифрованные). Одним махом избавите себя от постоянной головной боли.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует, и напомню, что Ansible тоже прекрасно справляется с этой задачей.
Ну и, напоследок, выскажусь касательно жёсткого декларирования по цветовой дифференциации штанов инструментов. Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?
В том-то и дело, что дело не в сравнении, а в практическом приложении к конкретным сервисам облака, где у провайдера для Terraform от Яндекса нет нужного функционала.
А где кликбейт? Была конкретная ситуация, для которой в провайдере от Яндекса не нашлось инструмента. Решилась задача через создание собственного модуля для Ansible (поскольку нужно было работать с Lockbox через Ansible). Это случай дал материал для статьи.
Отличный спор, великолепная аргументация, потрясающий выбор цитат. Но реальность такова, что нам работать с Lockbox через Ansible удобнее и проще, используя собственный модуль для работы с api. На этом предлагаю разойтись :)
Конечно, вы правы. Инструменты надо подбирать для конкретных задач. Об этом, собственно, и речь в моей статье.
Спасибо за лестный отзыв. Аспекты безопасности использования кастомных модулей - это отдельная тема, раскрыть которую в рамках одной статьи, мне кажется, будет сложно. Тем более, что текст посвящён конкретной точке приложения такого подхода, а вопрос безопасности собственных модулей для Ansible надо рассматривать шире.
Коллега, давайте по пунктам.
Прекрасно знаю, для чего нужен terraform и как работать с инфраструктурой, но в данном случае мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service. Давайте посмотрим на то, как в провайдере terraform для Lockbox реализована работа с секретами и применим к реальной ситуации. Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли. И вот вы пишете кучу однотипных манифестов с ресурсами по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret.html, складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест, который создаст версию секрета с нужными изменениями по документации https://terraform-provider.yandexcloud.net/resources/lockbox_secret_version.html. А секреты изменяются часто.
Итого, имеем обширный инфраструктурный код, который будет неизбежно дрейфовать (человеческий фактор). Поступившись декларативностью и добавив в модуль простую проверку https://github.com/krang404/ycm/blob/26195a909b3dfea87aeb88b545049cb9c97fe5c4/plugins/modules/yc_lockbox.py#L330 , мы можем подавать на вход только данные для секрета и не городить большую кучу инфрового кода. И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор. Сюда входит и невозможность предоставить разделённый доступ к секретам (вы даёте доступ всей команде сразу и никак не можете гранулировано его распределить), и отсутствие контроля за безопасностью хранения секретов на локальных хостах разработчиков, ну и просто безалаберность коллеги (кто-нибудь обязательно коммитнет в репо незашифованный файл). Безусловно, все проблемы можно нивелировать, но вопрос: какой ценой? Проще всего - не хранить секреты в репозитории (даже зашифрованные). Одним махом избавите себя от постоянной головной боли.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует, и напомню, что Ansible тоже прекрасно справляется с этой задачей.
Ну и, напоследок, выскажусь касательно жёсткого декларирования по цветовой дифференциации
штановинструментов. Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?Тут дело в том, что терраформ в принципе не подоходит для решения таких задач. Ansible удобнее, даже с учётом того, что пришлось писать модуль.
В том-то и дело, что дело не в сравнении, а в практическом приложении к конкретным сервисам облака, где у провайдера для Terraform от Яндекса нет нужного функционала.
А где кликбейт? Была конкретная ситуация, для которой в провайдере от Яндекса не нашлось инструмента. Решилась задача через создание собственного модуля для Ansible (поскольку нужно было работать с Lockbox через Ansible). Это случай дал материал для статьи.