Azure KeyVault для DBContext: «Для этого DbContext не настроен поставщик базы данных» - PullRequest
0 голосов
/ 01 ноября 2018

Я создаю веб-API с использованием .NET Core 2.1. Он будет размещен как веб-приложение Azure. Я хочу сохранить строку подключения к моей базе данных в хранилище ключей Azure. Вот код, который я поместил в мой метод Startup.cs ConfigureServices:

services.AddDbContext<dbContext>(async options => 
        {
            var keyVaultUri = new Uri("https://xxxxxxxxx.vault.azure.net/");
            var azureServiceTokenProvider = new AzureServiceTokenProvider();
            var keyVaultClient = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
            SecretBundle connectionStringSecret = await keyVaultClient.GetSecretAsync(keyVaultUri + "secrets/DBConnectionString");
            options.UseSqlServer(connectionStringSecret.Value);
        });

Когда я пытаюсь получить HTTP Get к моему контроллеру, в который вставлен dbContext, я получаю следующую ошибку:

InvalidOperationException: No database provider has been configured 
for this DbContext. A provider can be configured by overriding the
DbContext.OnConfiguring method or by using AddDbContext on the 
application service provider. If AddDbContext is used, then also 
ensure that your DbContext type accepts a DbContextOptions<TContext> 
object in its constructor and passes it to the base constructor for 
DbContext.

Я предполагаю, что это из-за того, что я использовал асинхронную лямбду для получения строки соединения из хранилища ключей, однако я не уверен, что с этим делать. Это правильный способ получить строку подключения из Azure KeyVault для использования в Startup.cs? Должен ли я сделать это по-другому? Любая помощь будет оценена. Спасибо.

1 Ответ

0 голосов
/ 01 ноября 2018

Причиной сбоя вашей конфигурации является то, что обратный вызов теперь async void. Это не очевидно из взгляда на лямбду, но это эффективно огонь и забыть. Когда вы ожидаете клиента хранилища ключей, он возвращается из обратного вызова без настройки поставщика.

Что касается решения, я думаю, что лучше добавить секретные хранилища ключей в систему конфигурации, чтобы вы могли использовать их оттуда, как если бы они пришли из файла JSON или из любого другого источника.

Я недавно написал статью об этом: https://joonasw.net/view/aspnet-core-azure-keyvault-msi. Я использовал управляемую идентификацию для аутентификации в своей статье, но я вижу, что вы тоже используете ее:)

Вот пример того, как вы можете настроить Key Vault в качестве источника конфигурации в ASP.NET Core 2.x:

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureAppConfiguration((ctx, builder) =>
        {
            //Build the config from sources we have
            var config = builder.Build();
            //Add Key Vault to configuration pipeline
            builder.AddAzureKeyVault(config["KeyVault:BaseUrl"]);
        })
        .Build();

Пример, который я привел в этой статье, на самом деле немного слишком многословен, так как он будет использовать AzureServiceTokenProvider внутри для получения токенов.

Вам потребуется Microsoft.Extensions.Configuration.AzureKeyVault , чтобы получить поставщик конфигурации для хранилища ключей.

Секретное наименование в Key Vault будет иметь значение. Например, мы переопределим следующую строку подключения:

{
  "ConnectionStrings": {
    "DefaultConnection": "..."
  }
}

Вам потребуется создать секрет с именем ConnectionStrings - DefaultConnection со строкой подключения в качестве значения.

Тогда при настройке вы просто используете Configuration["ConnectionStrings:DefaultConnection"], чтобы получить строку подключения. Он будет получен из хранилища ключей, если будет добавлена ​​конфигурация хранилища ключей и найден секрет с правильным именем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...