Не удается подключиться к хранилищу ключей Azure при использовании идентификатора службы

Question

Я пытаюсь получить секреты из хранилища ключей Azure, используя идентификатор службы в веб-приложении ASPNet 4.6.2.Я использую код, описанный в этой статье .Локально, все работает нормально, хотя это потому, что он использует мою личность.При развертывании приложения в Azure я получаю исключение при вызове keyVaultClient.GetSecretAsync(keyUrl).

Насколько я могу судить, все настроено правильно.Я создал идентификатор, назначенный Пользователем, чтобы его можно было повторно использовать, и убедился, что идентификатор имеет get доступ к секретам и ключам в политике KeyVault.

Исключением является AzureServiceTokenProviderException.Он многословен и обрисовывает в общих чертах, как он попробовал четыре метода аутентификацииМеня беспокоит информация, когда он пытается использовать идентификатор управляемой службы:

Пытался получить токен с использованием идентификатора управляемой службы.Не удалось получить токен доступа.MSI ResponseCode: BadRequest, Response:

Я проверил понимание приложения и увидел, что оно попыталось установить следующее соединение с ошибкой 400 результатов:

http://127.0.0.1:41340/MSI/token/?resource=https://vault.azure.net&api-version=2017-09-01

Есть две интересные вещипо этому поводу:

1. Почему он пытается подключиться к локальному адресу?Это кажется неправильным.
2. Может ли это быть возвращением 400, потому что параметр ресурса не экранирован?
3. В MsiAccessTokenProvider source он использует только эту формуадрес, когда установлены переменные окружения MSI_ENDPOINT и MSI_SECRET.Они не установлены в настройках приложения, но я вижу их в консоли отладки при выводе переменных среды.

На данный момент я не знаю, что делать.Все примеры в сети кажутся волшебными, но если я прав в отношении источника проблемы, то есть некоторые неясные автоматические настройки, которые необходимо исправить.

Для полноты здесь приведен весь мой соответствующий код:

public class ServiceIdentityKeyVaultUtil : IDisposable
{
    private readonly AzureServiceTokenProvider azureServiceTokenProvider;
    private readonly Uri baseSecretsUri;
    private readonly KeyVaultClient keyVaultClient;


    public ServiceIdentityKeyVaultUtil(string baseKeyVaultUrl)
    {
        baseSecretsUri = new Uri(new Uri(baseKeyVaultUrl, UriKind.Absolute), "secrets/");
        azureServiceTokenProvider = new AzureServiceTokenProvider();
        keyVaultClient = new KeyVaultClient(
            new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
    }

    public async Task<string> GetSecretAsync(string key, CancellationToken cancellationToken = new CancellationToken())
    {
        var keyUrl = new Uri(baseSecretsUri, key).ToString();
        try
        {
            var secret = await keyVaultClient.GetSecretAsync(keyUrl, cancellationToken);
            return secret.Value;
        }
        catch (Exception ex)
        {
            /** rethrows error with extra details */
        }
    }

    /** IDisposable support */
}

ОБНОВЛЕНИЕ № 2 (я удалил обновление № 1)

Я создал совершенно новое приложение или новый экземпляр службы и смогвоссоздать ошибку. Однако , во всех случаях я использовал User Assigned Identity .Если я удаляю это и использую System Assigned Identity , тогда он работает просто отлично.

Я не знаю, почему они будут другими.У любого есть понимание, поскольку я предпочел бы назначенный пользователем.

Answer 1

Чтобы использовать назначенную пользователем идентификацию, HTTP-вызов для получения токена должен включать идентификатор идентификации.В противном случае он попытается использовать назначенный системой идентификатор.

Почему он пытается подключиться к адресу локального хоста?Это кажется неправильным.

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

Может ли это быть возвращением 400, поскольку параметр ресурсане сбежал?

Да, но я не думаю, что причина была здесь.

В источнике MsiAccessTokenProvider он использует только эту форму адресакогда переменные окружения MSI_ENDPOINT и MSI_SECRET установлены.Они не установлены в настройках приложения, но я вижу их в консоли отладки при выводе переменных среды.

Они незаметно добавляются службой приложений, но не добавляются в настройки приложения.

Что касается того, как использовать назначенную пользователем идентификацию, я не мог найти способ сделать это с библиотекой AppAuthentication.Вы можете сделать HTTP-вызов вручную в Azure: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http. Тогда вы должны сами позаботиться о кэшировании!Конечные точки управляемых удостоверений не могут обрабатывать много запросов одновременно:)

Answer 2

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

Из документов :

Назначенный системой управляемый идентификатор включен непосредственно в экземпляре службы Azure.Когда удостоверение включено, Azure создает удостоверение для экземпляра в клиенте Azure AD, которому доверяет подписка экземпляра.После создания удостоверения учетные данные предоставляются экземпляру.Жизненный цикл назначенного системой удостоверения напрямую связан с экземпляром службы Azure, на котором он включен.Если экземпляр удаляется, Azure автоматически очищает учетные данные и удостоверение в Azure AD.

A Назначенный пользователем управляемый идентификатор создается как автономный ресурс Azure.В процессе создания Azure создает удостоверение в клиенте Azure AD, которому доверяет используемая подписка.После создания удостоверения его можно назначить одному или нескольким экземплярам службы Azure.Жизненный цикл назначенного пользователем удостоверения управляется отдельно от жизненного цикла экземпляров службы Azure, которым он назначен.

Назначенные пользователем удостоверения все еще находятся в предварительном просмотре для служб приложений.Смотри документацию здесь .Возможно, он все еще находится в режиме предварительного просмотра (т. Е. Microsoft должна явно включить его в вашей подписке), он может быть недоступен в выбранном вами регионе или может быть дефектом.