Хранение данных конфигурационных файлов и генерация конфигов

инфраструктура
, , , ,
Теги: #<Tag:0x00007f73871ad478> #<Tag:0x00007f73871ad388> #<Tag:0x00007f73871ad298> #<Tag:0x00007f73871ad1a8> #<Tag:0x00007f73871ad0e0>
#1

Доброго, коллеги.

Назрел вопрос о хранении информации (хосты, данные для доступа и проч.) для конфигурационных файлов и использование этих данных в конфигах тестов.

Ситуация на данный момент такова, что имеется сколько-то репозиториев с тестами под разные сервисы. Сервисы +/- используют, иногда одинаковые данные для доступов (к БД, очередям проч.), иногда разные т.е. в каждой репо сейчас лежит свой конфиг с данными для доступов. И мне это не очень нравится т.к. в случае изменений нужно исправлять конфиги в нескольких репо.

На проекте сейчас используется Gitlab CI, и человек знающий сразу же напомнит мне о Credentials, однако в community версии нет возможности использовать Vault by HashiCorp вообще (только в версии EE). Остается только использование защищенных переменных (“variables protected”). Однако, вариант вбивать 30-50 переменных в CI, затем их же в .gitlab-ci.yml мне не очень нравится (хотя, так делают, видел).

Единственный вариант, который сейчас смог придумать - отдельный сервис для хранения этих данных. Может какое-либо защищенное хранилище? Хотелось бы услышать ваши мысли на этот счет.

Вторая мысль, как продолжение первой - генерация конфига на основе данных полученных их хранилища. Может кто-нибудь видел/знает подобные реализации на чем угодно? (на край, сам напишу, определиться бы какое хранилище использовать).

В целом, любопытно было бы услышать мнение коллег по этому поводу (не исключаю, что я сильно загнался).

Спасибо за внимание.

#2

а кто мешает в vault кодом ходить, а не гитлабом?

#3

Никто не мешает. Об этом и разговор.
Но, сомневаюсь, что случай сильно оригинальный, хотелось бы от коллег услышать кто и как решал.

#4

ну тут главное прицениться к тому, что удобнее будет поддерживать

в принципе, я думаю хранить в protected variables гитлаба токен доступа к секретам в vault уже достаточно будет, а в коде реализовать метод получения условно пароля по логину с помощью указанного выше токена (он же будет доступен раннеру в процессе выполнения джобы через переменные окружения)

#5

Да, совершенно верно. Есть мысли что удобнее использовать в качестве хранилища? Vault, конечно, хорошо. Но беглый осмотр API вообще не воодушевил. Может что-то проще существует?

#6

а что не так с волтом? я помню только, что там в урле надо передавать путь до секретов, а в остальном просто сделайте отдельную коллекцию текстовых секретов, отдельный токен на чтение до этой коллекции и всё

собираете урл по ключу, получаете json со значением и мета данными

#7

С Vault то все нормально, просто у него очень богатый функционал - придется потратить время на разбиралово (чтение доков, эксперименты) т.к. никогда с ним не сталкивался. Но видимо, придется использовать его.

Немного вчера покурил. Похоже, нужен бекенд KV Secrets Engine - Version 1 (KV - Secrets Engines | Vault by HashiCorp)

KV Secrets Engine

The kv secrets engine is a generic Key-Value store used to store arbitrary secrets within the configured physical storage for Vault. This backend can be run in one of two modes; either it can be configured to store a single value for a key or, versioning can be enabled and a configurable number of versions for each key will be stored.

#8

вы админите сервис волта? если нет, то зачем вам это?

#9

Нет. Не админю. И как написано выше - даже не касался ни разу. И почему озадачился - тоже написано выше, в первом посте темы.

#10

просто если вы не админите, то ваша задача состоит в том, чтоб попросить у админов выдать вам токен до вашей коллекции, который вы будете указывать в хэдере запроса, а дальше просто делать запрос до нужного секрета

image
image760×309 9.56 KB

то есть запрос будет примерно такой:

path-to-vault/secret/test-collection/user1

ну и в ответе будет что-то вроде

{
"login" : "user1",
"password" : "password1"
}

ну или какой у вас там формат данных будет; просто десериализуете json и через точку вытаскиваете пассворд

#11

А, вот Вы про что. Нет, в организации нет поднятого Vault. Сам буду ставить, соответственно админить тоже.

Да, я уже посмотрел какой бек использовать и примерно как это делать. Спасибо.

#12

да не за что

пара приколов по памяти:

  • если vault перезапускать, то надо открывать хранилище каждый раз, иначе он не будет пускать
  • токены выдаются с истечением времени, дефолтные короткие вроде, надо аккуратно настраивать и помнить, когда они истекают
1 симпатия
#13

Понял, спасибо.
Про первое - читал уже. Да, надо “распечатывать” хранилище после перезапусков.
Вот все эти настройки чрезмерные для моей задачи они смущают (не понятно где споткнешься).

Давайте отойдем от Vaulta. Может можно использовать просто noSQL БД? Существует в какой-нибудь noSQL БД возможность шифрования, например?

Вроде пишут “Версия MongoDB 4.2 получила поддержку шифрования данных на уровне полей (field-level encryption, FLE)”

UPDATE: Доступно только в MongoDB Enterprise. (at-rest)