Меня зовут Юрий Шуткин, я инфраструктурный инженер в Тинькофф. В этой статье расскажу, как мы запустили сервис по хранению важной информации и избавились от небезопасной передачи секретов.
Секретами мы называем важную информацию, которую нельзя хранить в открытом виде: пароли, токены, сертификаты.
Простого указания недостаточно, чтобы люди стали безопасно хранить и передавать секреты. Коллеги загружены, и вопросы безопасности слишком часто оставляются на потом, которое на практике редко наступает. Поэтому мы хотели сделать простой и удобный сервис, чтобы им было приятно пользоваться и вопросы безопасности не страдали.
Почему HashiCorp Vault
Мы выбрали HashiCorp Vault, потому что у него есть встроенный ACL, аудит логов, хранилище Key Value, интеграция с Active Directory, можно не дублировать пользователей, PKI — и все это работает из коробки. У Vault отличный задокументированный API, которым удобно пользоваться даже из командной строки.
Начиная с версии 1.0.0 в OSS версии Vault появился веб-интерфейс. До этого он был только в платной Enterprise-версии. Мы используем OSS — нам достаточно бесплатной функциональности.
Когда заходишь внутрь секрета в HashiCorp Vault, сама секретная информация скрыта. Чтобы ее посмотреть, нужно нажать кнопку «Копировать» или иконку «глаз». В варианте с версионированием можно копировать секрет или создать новую версию.
Как мы используем HashiCorp Vault
У нас несколько типов пользователей, которые используют Vault по-разному:
Сотрудники, которым нужно лишь хранилище секретов, доступное через веб-интерфейс, — это тестировщики, которые не деплоят, а просто забирают логин и пароль, авторизуются и проверяют данные в сервисе.
HR, финтех-преподаватели, которым нужно хранить общие секреты — логины и пароли.
Коллеги, которые создают сервисные учетные записи и передают заказчикам реквизиты. Передавать их в открытом виде небезопасно, поэтому создатель учетной записи заносит реквизиты в формате JSON, нажимает кнопку Wrap, получает токен и отправляет его пользователю. Тот проверяет, что токен валиден, и дальше его расшифровывает. Если кто-то до него расшифровал этот токен или время жизни токена истекло, программа выдаст ошибку. Так мы узнаем, что секрет ушел не туда, и можем вовремя его заменить. Описан ручной вариант, но создать обертку можно с помощью API-запроса в Vault и развернуть ее через API.
Роботы и автоматизация — это различные API-запросы к Vault: приложения заходят в него, забирают секреты и живут с ними.
Одно из требований к системе — отказоустойчивость. Покажу примерную схему, как мы ее обеспечивали:
Чтобы понимать, как все работает, добавили Prometheus — ПО для мониторинга приложений. Мы собирали статистику с Nginx, Vault и Consul, чтобы видеть, насколько все хорошо или плохо. Но этого тоже не хватало, и мы добавили бота, который ходит в Vault и симулирует жизнь пользователей. Он авторизуется под различными аутентификационными бэкендами, например LDAP, Userpass, Approle. Бот пишет, читает реквизиты и пытается отозвать токен. Так мы проверяем, что сервис — действительно сервис, а не 200 OK, белая страница и ничего не работает на самом деле.
Несколько раз при обновлении версии Vault этот бот помог обнаружить проблемы с авторизацией. По метрикам бота можно строить графики. На рисунке — гистограмма по времени авторизации:
Основная фича Vault — Barrier, его задача — зашифровать данные, которые уходят в Storage и расшифровать те, что приходят обратно. Storage всегда зашифрован, и это третья инсталляция Vault:
Шифрование использует определенный алгоритм ключей, и без них RAW-данные из хранилища сложно расшифровать. Однажды я потерял ключи от первых двух инсталляций и не смог получить доступ.
Vault использует мастер-ключ для расшифровки своего хранилища. Мастер-ключ никому не известен, он даже в Vault не хранится и существует лишь в памяти процесса. Когда в первый раз запускаешь Vault, появляется окно с просьбой ввести максимальное количество ключей и информацией, сколько нужно ключей, чтобы собрать мастер-ключ.
У нас семь инженеров, владельцев ключей. Как в фильме «Властелин колец»: все семь колец правят миром, а три из них могут объединить свои ключи, чтобы получить мастер-ключ, расшифровать Vault и выпустить рутокен.
Если проинициализировать Vault и перезапустить его, появляется окно с просьбой ввести части ключей. Мы настроили хитрые локейшены, чтобы в любой момент отправить запрос на распечатывание определенной ноды Vault: /unseal/node1/unseal/node2...
Мы зашифровали ключи индивидуальными GPG-ключами и сохранили в Git. Это нужно для того, чтобы их можно было легко найти в одном месте. После каждой операции ротации ключей Rekey генерируется новый мастер-ключ. Старые ключи прекращают работать, но с их помощью можно распечатать старые бэкапы, что пару раз было очень кстати.
Однажды мне позвонили в два часа ночи, потому что две трети кластера не работали и появлялась картинка «Vault запечатан». Пользователи пришли на работающую ноду, которая автоматически перебросила их на зашифрованную. И вроде авторизовался, но Vault не работает.
Это произошло, потому что сама веб-страница через равные интервалы времени отправляет запрос в Vault /sys/seal-status. Ответ на такой запрос у любой запущенной ноды — «200», но в теле ответа от запечатанной ноды написано, что Vault запечатан и не работает. У нас был простой конфиг для Nginx с перечислением апстримов до нод Vault без проверки на запечатанность. API-запросы с ответом 5хх или по таймауту автоматически отправляются в другой бэкенд, пока не переберут все имеющиеся. Если хотя бы одна нода Vault доступна, API работает.
Сначала мы вывели запечатанные ноды из ротации, чтобы работа веб-интерфейса восстановилась. Vault должен быть доступен 24/7, на него полагается большая часть автоматизации. Приложения не смогут проинициализироваться при старте, если Vault недоступен и не отдает секреты.
Я ввел часть ключа и активировал его для расшифровки Vault, но нужно было еще два. Мы стали искать тех, с кем можно распечатать Vault. Один инженер был в отпуске, до второго не удалось дозвониться. Третий пытался подключиться к своей машине по RDP, но что-то пошло не так, и машина зависла. Четвертый оказался доступен и помог. Утром мы перезагрузили машину третьего инженера, и он помог нам распечатать ноды Vault.
Последняя пара инженеров так часто пользовалась PGP-ключом, что один не вспомнил пароль, а второй забыл перенести PGP-ключ на новое оборудование. Тогда в проекте участвовали только два инженера, остальные просто хранили ключи и не были готовы к звонку.
История с ночными звонками показала, как нужно строить отказоустойчивость. Vault уже давно разрешил использовать облачные системы Key Management, но наша служба безопасности не рекомендовала их.
Мы хотели поднять приложение, например на Flask, загрузить в его память ключи, чтобы приложение регулярно пыталось ходить на каждую ноду Vault и распечатывать ее. К счастью, HashiCorp релизнул функцию печати кластера с помощью другого кластера.
Мы подняли еще один кластер, настроили его, и теперь он распечатывает основной кластер Vault. Это позволяет работать на Unseal-кластере с полной его недоступностью в течение суток, прежде чем пойдут проблемы в проде. С новым кластером проблем почти не бывает, он не нагружен, там никого нет, кроме иногда приходящих инженеров и робота. Теперь схема усложнилась:
Нам все еще нужно хранить Unseal-ключи для распечатывания второго кластера, но в прод-окружении у нас нет ключей. За счет того, что в основном кластере настроено автораспечатывание, мы немного больше защитили инсталляцию: нет группы инженеров, которые могут создать Root-токен продового окружения.
Как мы конфигурируем Vault
Нам нужно было конфигурировать объекты внутри Vault, чтобы управлять аутентификационными бэкендами и учетными записями в них. Рассматривали Terraform — опенсорс от компании HashiCorp, но обнаружили, что он мог удалить бэкенд при изменении времени жизни токена или при изменении описания бэкенда. Это риски, с которыми не хотелось сталкиваться.
Terraform не подошел, но с Vault можно работать через REST API. В Ansible есть модуль, который умеет работать через REST API, и экспертность — рассмотрели его как инструмент для управления объектами внутри Vault. Мы хотели добиться единообразия и простоты в описании объектов.
В итоге у нас 150+ каталогов c проектами в прод-окружении, в каждом каталоге есть свой набор файлов, в которых описан проект, группы AD, сервисные УЗ, политики проекта, кому и куда можно.
Как применяли конфигурации
Я был первым инженером в проекте и мог все катить сам. Быстро появился поток обращений «Юра, когда применится?» и «Юра, давай применим вот это». За пару месяцев получилось больше 70 проектов, и число растет до сих пор.
Чтобы решить проблему с потоком, мы настроили интеграцию с AWX — это «запускатель» Ansible. Однажды из-за бага AWX не подгрузилась одна переменная и мы вайпнули целое окружение — к счастью, тестовое, на котором проверяем новые версии и конфиги Vault.
Мы сохраняли не только регулярные бэкапы, но и бэкапы, запускаемые перед применением изменений. После вливания Merge Request в мастер-ветку смогли восстановить окружение. Бонусом настроили уведомления о применении конфигов в канал корпоративного мессенджера, чтобы не отвечать на вопросы «применилось ли».
Как создаем бэкапы
Первые бэкапы запускались в Cron. Но вручную проверять, как все запустилось, — трата времени, поэтому сделали скрипт, который отдавал метрики в систему мониторинга.
Чтобы снимать бэкапы по требованию, запустили Webhook-сервис. Webhook — это приложение, написанное на Go. С его помощью можно зайти на специальный локейшен по порту 9000 (дефолтный), c нужным секретом запустить бэкап либо запустить восстановление бэкапа при обращении к другому локейшену.
Регулярные бэкапы по Cron тоже запускаются через Webhook. Мы получим уведомление, если с момента последнего бэкапа прошло слишком много времени, а также с помощью Blackbox-экспортера можем проверить, что Webhook доступен.
Однажды Vault стал тормозить. Беглый осмотр метрик показал, что бэкап разросся с 70 Мб до 2 Гб и продолжал расти каждый час. Проверили логи: никаких ошибок, стандартные операции чтения и записи. Построили выборки по аудит-логу, нашли приложение, которое регулярно логинится в Vault. Время жизни токена было 32 дня, а использовался он несколько минут.
Мы уменьшили время жизни токенов после этого случая и добавили в процесс бэкапирования анализатор бэкапа. Это утилита, которая считает объекты в бэкапе и отдает метрики. Так мы можем понимать, как утилизируется хранилище Vault, кто сколько потребляет.
Как Vault помогает нам
Убрали логины и пароли из публичных мест.
Создали дружелюбный сервис для пользователей, чтобы они не терялись, куда нажать, как заводить секреты.
Обеспечили возможность передавать секретные данные через публичный канал. Это враппинг: мы зашифровали наше сообщение, оно живет в течение заданного интервала времени, все можно сделать через API и автоматизировать.
Сделали полностью динамические окружения, которые завязаны на Vault. Машины генерируют все логины и пароли, сразу складывают это в Vault, и пользователи приходят туда, смотрят реквизиты, могут авторизоваться, проверить, что все работает. Мы защитились от захардкоженного значения, одного маленького и единственного, которое 1000 лет никто не проверял, либо оно всегда вроде работало, и всегда этот пароль был точно такой же в Вики.
Обновить реквизиты стало проще. Мы получили единый источник правды, и нам достаточно поменять секреты в одном месте, а не идти в несколько систем и обновлять значения в них. Если приложение умеет само подгружать все изменения, оно сходит, обновит у себя значение и будет пользоваться новым паролем. Если приложение этого не умеет, можем запустить деплой. У нас все передеплоилось, и нет вопросов, все ли мы поменяли секреты, должны ли словить ошибку о том, что где-то что-то не работает.
Vault — интересный ресурс, с его помощью можно много всего автоматизировать, и его API довольно прост. Нам помогает в жизни автоматизация и шаблонизация. Наши проекты стандартизированы, за счет этого проще добавлять новые.
Комментарии (30)
Sergey_Kovalenko
01.07.2022 17:47+17Все конечно классно и IT отдел Тинь-Банка конечно молодец, но как автор статьи прокомментирует "недоразумения" с переводами за границу. Почему в принципе возможен перевод с комиссией равной всей сумме перевода? Почему пользователи не были должным образом предупреждены? Я бы обвинил банк в мошенничестве и воровстве, но прежде считаю должным выслушать какие-то объяснения. Если они покажутся читателям Хабра недостаточными, думаю его аудитория имеет моральное право изгнать отсюда этот блог как минимум "до лучших времен".
chernish2
01.07.2022 18:37+6Поставил минусы именно по этим причинам.
Antra
01.07.2022 21:02+7Минусы за качественную техническую статью??
Я могу понять недовольство банком (у самого исходящий SWIFT давно висит). Даже задать вопрос "какого фига творится" еще куда ни шло. Хотя и очевидно, что он не по адресу (причем не только не к автору, но даже и не к банку).
Но изгнать полезный блог напрочь... Да чего уж там, вообще тогда блоги всех банков, ибо всех лихорадит... Ну ведь перебор же. Не пофиг ли, в чьем блоге статья, если полезная и интересная.
Я понимаю нервозность вокруг. Многие даже на ключи от машины ругаются, когда торопятся, а "они потерялись". Но давайте все-таки постраемся продышаться. немного успокоиться и сохранить технические материалы. Они нам еще пригодятся.
Sergey_Kovalenko
01.07.2022 21:24+19Этот пост - реклама в сми и пока представители банка не дали в этом сми ответ - банк не без основания можно считать мошеннической структурой. Хорошая статья, с помощью которой мошенники привлекают к своей структуре будущих жертв, должна быть удалена вместе с блогом, но если ее автор пожелает, мы с удовольствием прочитаем ее от его частного и честного имени.
Мы обсуждаем действия компании в блоге этой компании, даже в такой формулировке я не вижу нарушения правил хабра.
Ответа на довольно серьезные обвинения представители банка не могут дать вот уже несколько часов, хотя главный капитал банка - это доверие к нему его клиентов. Каким должно быть у человека помутнение разума, чтобы он продолжал быть или решил стать после этого клиентом Тинькофф банка?Antra
01.07.2022 21:51Мы обсуждаем действия компании в блоге этой компании, даже в такой формулировке я не вижу нарушения правил хабра.
Я ни в коем случае не говорю о нарушении вами правил хабра. Более того, я как раз упомянул `Даже задать вопрос "какого фига творится" еще куда ни шло `. Я счел минусы статье перебором.
Ероме того, вот я присматриваю новый банк. Да неужто для выбора я буду корпоративные блоги банков на Хабре читать?
"Вау, как здорово они хранят секреты для приложений! А открою-ка у них счет!" - в голове не укладывается. Возможно индивидуальные особенности и привычки. Я и рекламу-то фильтрую и не отвлекаюсь на нее, никакой adblock не нужен. И серьезный выбор (банка, автомобиля...) я обычно делаю с чеклистом и табличкой в Excel. Конечно, общее впечатление имеет некоторый вес, но существенно менее значительный, чем реальные факторы. Впрочем, проехали, это к делу не относится.
pOmelchenko
01.07.2022 22:11+5Точно реклама, то-то мне после статьи захотелось не vaul поковырять, а кредитку оформить
Manyak872
02.07.2022 14:07+3Собственно, есть такой Mere-exposure effect. Я согласен с постом выше
если ее автор пожелает, мы с удовольствием прочитаем ее от его частного и честного имени.
pOmelchenko
02.07.2022 14:13Ну, хорошо, но можно сыграть и в ворота хабровчан, которые оскорбились статьей. Можно игнорировать банк, можно игнорировать статьи банка на площадке, можно игнорировать площадку, где банк размещает статьи.
zlat_zlat
01.07.2022 21:10+7Не только перевод, но и возврат перевода, который не прошёл. Две комиссии за одну услугу, которая не была оказана - новое слово в клиентоориентированности!
Sergey_Kovalenko
01.07.2022 21:27+1Еще бы знать, кто новые хозяева, которым идут эти "относительно честно" заработанные деньги. Хотя по почерку я могу догадаться, кто они и на домик у какого соленого моря пытаются перед побегом накопить.
zlat_zlat
02.07.2022 09:50+3По-моему, новый хозяин всем известен - Потанин.
Sergey_Kovalenko
02.07.2022 10:17+1Хоть какая-то определенность, но после всех разлитых по Сибири бочек с мазутом и труб с нефтью утешительного в новом управленце мало: Греби больше, кидай дальше!
gdt
02.07.2022 14:57+4Мне кажется Тинькофф это своеобразный «банк экспериментов». Вот например сделали они ВК несколько дней, мой коллега не потерпел и сразу в марте ушел от них, не получив ни единого перевода. Я терпел до мая, затем тоже ушел в еще один неподсанкционный банк — где вк длится часа 2. Кто-то лукавит в этой ситуации, и это не я :) И это не считая недавних приколов с обменом валюты, и отрицательных процентов на депозиты в валюте. Кому вообще нужен такой стремный банк?
Loyreni Автор
03.07.2022 10:28+2Доброго дня,
Никак не прокомментирую. Эта статья расшифровка моего выступления в 2019-м году https://www.youtube.com/watch?v=pP8909tFllM с поправкой на изменения за последние 3 года.
Я, также, не могу выложить статью в свой личный блог, т.к. и доклад и статья это труд многих людей работающих, или работавших, в Тинькофф:
* Команды которые создавали потребности в инструменте и автоматизации вокруг него
* Коллеги, которые ревьюили и помогали менять текст выступления
* Коллеги, которые ревьюили и правили текст этой статьи
Готов ответить на вопросы по волту, хранению секретов, по автоматизации вокруг инсталляции.Sergey_Kovalenko
03.07.2022 12:02Я не знаю, как кто и как где, но с моей и еще с точки зрения огромного числа людей и правовых норм свободных государств взимание с человека платы коммерческой структурой без предоставления взамен какой-либо ценности - есть либо мошенничество, либо воровство. Тут идет речь конечно о моральной оценке: в стране без закона, законной оценки вам никто не даст, кроме жандармов и полицаев. Когда вы выпускаете статью, рекламирующую бренд и направленную на увеличение доверия к такой коммерческой структуре, вы, Юрий Шуткин, разделяете ответственность за ее преступления, не как соучастник, но все же в какой-то мере.
Loyreni Автор
03.07.2022 16:04В посте намеренно нет тезисов "какие мы молодцы", потому что это никому не интересно. Пост про опыт построения сервиса для хранения и использования секретов. О том с какими сложностями столкнулись и как исправляли.
История с 7 избыточными ключами из которых необходимо всего лишь 3, да и то не сразу смогли собрать:
Показывает что без постоянных проверок и готовности ввести свою часть ключа мы не получили высокую доступность, т.к. ключи могут быть потеряны, забыты, или ещё какой фактор может сработать.
История про бэкапы:
Не было видно по графиками что что-то совсем пошло не так. Час от часу бэкап рос на 4Мб, ну мало ли, команды сохраняют секреты, пользуются сервисом, хорошо ведь. И только когда случился сбой: сервис стал очень сильно тормозить, мы начали копать чтобы понять что пошло не так.
Также если у вас инфра в виртуалках, и надо запускать задачи по крону, затрагивается вопрос мониторинга таких задач. В кубе проще, там есть cronJob и видно статус. В виртуалках для запуска бжкапа из CI и по рассписанию, запустили сервис webhook.
+ мониторинг: SLA, SLO, SLI
+ стандарты по именованию и автоматизация рутины, чтобы не превратить инсталляцию в ад поддержки. У некоторых команд более 15 волтовых групп АД с разными доступами, с разными списками участников, с разными требованиями от ИБ по мониторингу таких групп. Можно было передать управление такими группами на первую линию, но это человеческий фактор и увеличение нагрузки на людей тем что можно автоматизировать.
Я надеюсь что смог раскрыть эти темы, и поделиться опытом, который, возможно, даже окажется полезным другим инженерам при построении их систем.Sergey_Kovalenko
03.07.2022 16:55Ваши цели при совершении действия "не равны" последствиям этих действий. Тинькофф банк - коммерческая структура, ее цель - обогащение собственников банка, Тинькофф банк не будет платить Хабру деньги за право вести корпоративный блог только с той целью, чтобы его технические специалисты могли поделиться своим ценным опытом с комьюнити.
Цель блога - реклама: прямая (привлечение клиентов в нишевой аудитории) или косвенная (создание положительного эмоционального образа бренда). Последствия вашей статьи - больше потенциальных жертв по всей видимости нечистоплотного банка.
Если мне приходится объяснять столь очевидные вещи, какие выводы я должен сделать относительно вашей персоналии? Я вижу две альтернативы: или человек умственно отсталый, или у него у самого "рыльце в пушку". Подскажите мне третью, если я ошибаюсь.
#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Orazio_Gentileschi_-_Dana%C3%AB_and_the_Shower_of_Gold_-_2016.6_-_J._Paul_Getty_Museum.jpg){kind=link}
Ign0r
03.07.2022 00:16+2Можно вопрос по существу статьи, а не по принадлежности автора к конкретной организации?
Я правильно понимаю что у вас "модуль в Ansible" получает токен с правами генерации любых объектов - будь то хранилище секретов, политикf доступа или субъект авторизации? Как в этом случае валидируются "пересекающиеся" имена и как контролируется путь для применения плитик (например к другому хранилищу или к применяемому методу аутентификации)?
Loyreni Автор
03.07.2022 10:21+1Доброго дня,
Про права:
Ansible получает минимально необходимые для его работы права:
* Управление политиками (единственная уз с такими правами на весь кластер)
* Управление Auth Backend и учётками внутри
* Управление Secrets Engine
* Управление некоторыми системными вызовами, например управление аудит устройствами
Про имена объектов:
У каждого проекта свой префикс, добавляемый каждому объекту, что исключает пересечение по именам. Например:
* project1__kv <= SE
* project1__kv-rw <= Policy
* project1__kv-ro <= Policy
* project2__kv <= SE
* project2__transit <= SE
Ansible может запросить список объектов, например примонтированных SE, далее по префиксу понять какие объекты относятся к проекту конфиги которого сейчас применяются. Далее идёт сортировка в 3 списка:
* Удалить, если более не описано в конфигурации
* Обновить, если описано и существует
* Создать, если описано и не существует
Про доступ из одного проекта в другой:
Глобально запрещено обращаться к объектам чужого проекта. Коллеги написали валидатор на Open Policy Agent, который проверяет пути в политиках. Если встречается обращение за рамки своего проекта, кроме некоторых путей, пайплайн не пройдёт.
Prividen
04.07.2022 08:29С бакапами ваулта своеобразно.
Не знаю как с консул-хранилищем, а со встроенным рафтом, когда второй кластер, используемый для распечатывания, вдруг неработоспособен, или вдруг у первого кластера проэкспирился токен ко второму (на leader-ноде), то этот самый первый кластер начинает по API отдавать битые снапшоты.
Никаких ошибок, но: "gzip: raft_snapshot-1655683554067570701.snap: unexpected end of file"
А если попробовать снять снапшот через
vault operator raft snapshot save, то:
Error taking the snapshot: incomplete snapshot, unable to read SHA256SUMS.sealed file
amarao
А я посмотрел-посмотрел на эту monstrosity и начал использовать sops. Который, кстати, секреты хранит как раз в гите. Зашированными gpg-ключами (и другими kms).
past
Sops - годная штука для небольших инсталляций. Когда вокруг кровавый энтерпрайз, тысячи виртуалок и кубернетесы - vault единственный вариант
dyadyaSerezha
Не совсем согласен. Раньше этот кровавый энтерпрайз прекрасно жил годами с паролями в куче мест исходного кода, в переменных окружения тех самых тысяч серверов, в текстовых файлах на нмх же - и было норм. И вдруг такой вот двухкластерный монстр, от архитектуры которого уши заворачиваются. Что-то тут не так...
Antra
А на заре мой молодости было достаточно межсетевого жэкрана на внешнем периметре (Интернет). Все внтури было едва ли не плоской сетью, и никто особо не парился. А теперь какой-то Zero Trust подавай...
С жиру бесятся? Или все-таки мир меняется?
dyadyaSerezha
Речь не про молодость и сейчас, а про то, какие изменения были сделаны в одночасье, скорее всего просто по требованию безопасников.
Antra
Т.е. вы действительно считаете, что это и сейчас норм, и ИТ стало переходить на централизованное хранение секретов супротив души, просто из-за дурацких требований безопасников?
dyadyaSerezha
Я совершенно так не считаю.
Loyreni Автор
Каждый инструмент под свою задачу. Мы решали наши проблемы под которые волт больше подходит. Итоговая инфраструктура появилась не сразу. Первоначально она выглядела так:
* Балансер для возможности проводить работы на одной и более нод волта
* Волт в кол-ве 3 инстанса для отказоустойчивости и доступности 24х7
* Консул как хранилище для хранения БД волта. Но он уже был запущен на всю компанию, т.к. использовался в Service Discovery.
И по чуть-чуть для улучшения доступности сервиса, для закрытия выясненных проблем инфраструктура менялась, порой усложнялась, порой упрощалась. На сколько знаю, сейчас переводят волт на Raft хранилище, что даёт свои плюсы и минусы.