Comments 14
Плюсанул. Тоже недавно это реализовал, сначала думал сделать не просто json файл конфигурации, а через user secrets (https://learn.microsoft.com/ru-ru/aspnet/core/security/app-secrets?view=aspnetcore-7.0&tabs=linux#secret-manager), но это рекомендуется только для локальной разработки, да и в дефолтном докер-образе нет вроде тулы по умолчанию.
Так что в целом как-то так и получилось, только не храню в vault весь appsettings.json, а только то, что относится к секретам.
Конечно можно сделать более секурно, но это уже детали.
В Vault хранятся только секреты, сам конфиг, в данном случае appsettings.json
генерируется на основе шаблона, который храниться в configmap.
Никогда не понимал любителей генерировать конфиги из шаблонов, а уж при использовании ASP.NET Core — тем более. У вас есть key-value хранилище номер 1 (vault), вы из него делаете json, который будет считан и преобразован в key-value формат номер 2 (конфигурация asp.net core). Почему бы просто не пропустить шаг json?
А уж генерация неизменяемой секции Logging вместо помещения её куда-нибудь в appsettings.Production.json и вовсе выглядит как глупость
Шаблон хранится в configmap, это стандартный способ хранения конфигурации для приложений в k8s. В него подставляются только секреты из vault, по тому же принципу, как работает helm, то есть это скорее не генератор, как таковой, а шаблонизатор.
Не очень понятно, как в данном случае можно пропустить эту фазу, было бы очень интересно посмотреть на вашу реализацию в связке с Vault.
Сразу в ENV (но я не знаток Vault-а, просто предполагаю):
# Environment variable export template
vault.hashicorp.com/agent-inject-template-config: |
{{ with secret "secret/data/web" -}}
export api_key="{{ .Data.data.payments_api_key }}"
{{- end }}
Я не работал ни с k8s, ни с vault, так что идеального решения предложить не могу. Не исключаю и варианта, при котором авторы этих инструментов настолько привыкли к монструозных конфигам, нуждающимся в шаблонизации, что просто не предусмотрели сокращённого пути для нормальных программ.
Однако, как минимум, стоит либо убрать секцию Logging из вашего configmap, либо убрать подключение файла /vault/secrets/appsettings.json и писать всё в обычный appsettings.json. Потому что эти два механизма (статическая секция в шаблоне и статический appsettings.json) дублируют друг друга. В процессе доработок ваши настройки неизбежно разрастутся между этими двумя местами, и концов вы там не найдёте.
Тут нет, дублирования файлов конфигурации, файл конфигурации хранится в единственном экземпляре в configmap.
У нас как это работает, в локальной разработке используется отдельный appsettings.Development.json, а в CI/СD используется конфигурация из helm (configmap.yaml), которая лежит в том же проекте. Разработчик после проведения тестирования локально, обновляет configmap и все это выливается в k8s.
Тут есть дублирование файлов конфигурации. Напоминаю код:
builder.Configuration
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.{builder.Environment.EnvironmentName}.json", optional: true, reloadOnChange: true)
.AddJsonFile("/vault/secrets/appsettings.json", optional: true, reloadOnChange: true);
Если бы основной appsettings.json
генерировался из configmap — вам бы не понадобилось добавлять отдельный /vault/secrets/appsettings.json
, да и вообще играться с конфигурацией. Следовательно, у вас активны как минимум два файла конфигурации — appsettings.json
и /vault/secrets/appsettings.json
. Причём наверняка в обоих есть секция Logging (просто потому что в первом она есть по умолчанию, и я не видел у вас инструкции её вырезать).
s/HasiCorp/HashiCorp/g
Подключаем sidecar Vault агента
А в чем преимущество sidecar агента перед CSI провайдером ?
Есть хорошая статья, где есть сравнение https://www.hashicorp.com/blog/kubernetes-vault-integration-via-sidecar-agent-injector-vs-csi-provider.
В целом sidecar поддерживает больше фич, не требует инсталляции как demonset.
.NET и HashiCorp Vault: Использование секретов в настройках .NET Core приложения