Comments 11
А как вы работаете с обновлением значений секретов если они обновились в Vault?
И если вы не используете обновление секретов, то почему не взяли готовое решение в виде External Secrets Operator?
И если вы не используете обновление секретов, то почему не взяли готовое решение в виде External Secrets Operator?
Мы не рассматривали данный функционал. Я почитал о нем. Он бы нам не подошел по следующим причинам:
у нас есть приложения которые не работают в Kubernetes
у нас и без того большое кол-во приложений. Мы хотим минимизировать администрирование в наших системах. А эта затея приведет к её увеличению. а эффект от этого будет не большой
API этого инструмета хоть и простой, но явно сложенее чем то к чему мы пришли
А как вы работаете с обновлением значений секретов если они обновились в Vault?
Этот момент пока что в планах. Сейчас мы с этим не работаем. Пока что по старинке перезагружаем приложение, но хочется от этого уходить
Спасибо за статью. А где и как вы храните секреты для доступа к самому vault?
А не думали просто в Vault прописывать ключи так, чтобы они однозначно мапились в конфиг приложения AS IS? Например:
{
"Endpoints__ClientConfig__Credentials__SomeUserName": "some password"
}
Разделять можно родным способом (двоеточие), так и двойным подчёркиванием. Второй способ удобен тем, что в ряде случаев, все ключи Vault можно впихнуть прям в переменные окружения, и они спокойно подтянутся в приложение.
Таким образом, ключ содержит в себе полный путь к кофигурации приложений. И отражается напрямую 1 в 1. Т.е. через Vault можно задать абсолютно любое значение конфигурации приложения. И ничего не надо заранее нигде прописывать, никаких приседаний.
Над таким вариантом мы не думали, но вряд ли мы бы его выбрали, так как у него есть один из недостатков, от которого мы уходили
При администрировании секретов в HashiCorp Vault необходимо учитывать структуру заданную секциями в свойстве VaultSecretsPath
По сути у предлагаемого вами варианта таже проблема, только выражается она в другой форме. В этом решении вам все еще нужно соблюдать структуру заданную конфигурацией приложения в Vault (в данном случае наименования секретов).
Также, я не представляю, как предложанный вариант сможет красиво справиться с случаями когда в разных приложениях в одном и том же месте требуются разные секреты
Еще один существенный недостаток заключается в стоимости перехода на предложенное решение. Для того чтобы на него перейти нужно потратить время как на переписывание секретов в Vault, так на и на переписывание конфигурации в приложениях так как она может не соответсвовать тому к чему мы придем делая конфигурацию в Vault
Также при таком подходе во многие приложения будут попадать секерты, которые попросту ему не нужны. А если делать в Vault пространства для каждого приложения со своим набором секертов, то это просто приведет в свое вермя к большому количеству таких пространств, что в свою очередь будет не удобно использовать и поддерживать
В целом могу сказать, что предложенный мною подход отлично работает, при условии, что его начали применять сразу. Проблем с чужими секретами нет, так как другие секреты находятся в других секциях, а свалки секретов, где всякий берёт то, что ему нужно, этого избегаем.
Если подключение Vault произошло гораздо позже, чем в нём появились секреты, ничего не попишешь, понятно, что всё переделывать никто не будет.
В предложенном вами решении, на мой взгляд, есть довольно существенный недостаток. Это явная и очевидная привязка к Vault, прямо на уровне определения ключей конфигурации. В то время, как одна из основных и коронных преимущества системы конфигурации .NET состоит в том, что вы можете определить сколько угодно источников конфигурации, как угодно совмещать и гибко управлять ими. Например, локальная разработка, нагрузочные и различные одноразовые стенды с динамической настройкой -- нигде нет никакой привязки к Vault, так как Vault это всего лишь один из источников конфигураций.
Учитывая это, нужен отдельный mapping: ключ Vault => ключ приложения. Программисту не интересно, откуда в приложении возьмётся секрет, он определяет параметр конфигурации, который нужно заполнить.
Вот как-то так вижу. Нисколько не умаляю проделанной вами работы, и плюсы. Но всё равно не покидает ощущение, как будто к микроскопу приделали ручку от молотка, для удобства забивания гвоздей :)
В целом могу сказать, что предложенный мною подход отлично работает, при условии, что его начали применять сразу
Ваш подход удобен с точки зрения конфигурирования. Но не удобен с точки зрения чтения и настройки остальных систем. А нам это важно так как системы уже существую, уже не настроены чисто под конфигурацию систем и уже у множества их пользователей появились паттерны поведения с этими системами. Если кто-то далекий от конфигурации приложения (например, бизнес-аналитик, PO и т.д.) захочет прочитать секерт, то ему малось будет сложно ориентироваться в предложанном варианте. Дублировать секреты, не хочется. Можно конечно как-то это регламинтировать и написать инструкции, но как паказывает практика "делай удобно", а не "пиши инструкции" вызывает в итоге меньше проблем
Проблем с чужими секретами нет, так как другие секреты находятся в других секциях, а свалки секретов, где всякий берёт то, что ему нужно, этого избегаем
Тогда мы возвращаемся к проблеме, где конфигурация приложения диктует вам как хранить секреты в Vault. Вы вот уже должны избегать таких моментов + вы должны соблюдать нейминг. Может еще что всплывет. Такие действия просты сами по себе, но если таких простых вещей собрать в кучу в целом по разработке систем, то уже становится не очень
В предложенном вами решении, на мой взгляд, есть довольно существенный недостаток. Это явная и очевидная привязка к Vault, прямо на уровне определения ключей конфигурации. В то время, как одна из основных и коронных преимущества системы конфигурации .NET состоит в том, что вы можете определить сколько угодно источников конфигурации, как угодно совмещать и гибко управлять ими.
Согласен, есть такой недостаток. Но так как свойства в конфигурации являются ссылочными и на них нет никакой завязки в самом приложении, то я не вижу в этом проблемы. Т.е. используя ссылочное свойство Password-VaultSecret, идет ссылка на свойство Password. В коде будет завязка на свойство Password. И вам ничего не мешает использовать другой провайдер определяющий это свойство. Поэтому с этой точки зрения описанный вами минус будет в основном влиять только на наличие ссылочного свойства в конфиге. Можно конечно сделать завязку на ссылочное свойство, но по умолчанию привязка не работает со свойствами в намиеновании которых есть "-", да это как-то странно на такое завязываться
Учитывая это, нужен отдельный mapping: ключ Vault => ключ приложения. Программисту не интересно, откуда в приложении возьмётся секрет, он определяет параметр конфигурации, который нужно заполнить.
Тут соглашусь, это прям хороший плюсь
Вот как-то так вижу. Нисколько не умаляю проделанной вами работы, и плюсы. Но всё равно не покидает ощущение, как будто к микроскопу приделали ручку от молотка, для удобства забивания гвоздей :)
Может быть, кто как видит. Поэтому статья и является лишь рассказом, а не рекомендацией. Спасибо за обратную связь :)
Привет!
Поделюсь нашим опытом :)
У нас весь конфиг хранится в vault и перезаписывается при CI/CD.
Для системы заданы два окружения в vault: test и prod.
В зависимости от того, куда идëт деплой - берëтся весь конфиг и перезаписывается на тачке.
Кода на уровне системы или библиотеки в итоге вообще не требуется.
Привет!) Прям весь конфиг? Или именно секции с секретами?
В зависимости от того, куда идëт деплой - берëтся весь конфиг и перезаписывается на тачке.
И еще вопрос. Разве это не означает, что в итоге на конечной тачке секреты хранятся на уровне файлов? А то этого как раз лучше избегать в целях ИБ
У нас весь конфиг хранится в vault и перезаписывается при CI/CD
Еще вопрос вспыл. Значит ли это, что при смене секрета нужно перезапустить CI/CD, а не просто приложение? Крайне редко при перезапуске CI/CD что-то идет не так и поэтому это сложно назвать проблемой, но все же интересно
Опыт интеграции .NET Core+ приложений с HashiCorp Vault