@DanijelMalik , Спасибо за отзыв. Мы изучаем этот запрос и сообщим вам как можно скорее.

@DanijelMalik , пожалуйста, предоставьте нам вывод
Примечание. Не забудьте замаскировать конфиденциальные области, такие как идентификатор подписки или секреты.
{
"status": "Не удалось",
"ошибка": {
"code": "ApplicationGatewayKeyVaultSecretException",
"message": "Проблема возникла при доступе и проверке секретов KeyVault, связанных с /subscriptions/XXXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2 шлюза приложений", см. ниже: '.
"Детали": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "В доступе отказано для KeyVault Secret 'XXXXXXXXXXXXXXXXX' for Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGateway" Убедитесь, что Application Gateway назначен для шлюза приложения. связано с секретом ".
}
]
}
}

@DanijelMalik , Просто проверяю, есть ли у вас время просмотреть предыдущий ответ.

@DanijelMalik , Поскольку мы не получили от вас

Здесь та же проблема.

Для меня это было решено включением мягкого удаления в хранилище ключей.

Существует проблема, связанная с тем, что это требование не задокументировано: # 34382

Привет, у меня такая же проблема. Проблема, по-видимому, заключается в том, что хотя keyvault разрешает доступ из подсети appGw (через колонку настроек брандмауэров и виртуальных сетей в конфигурации keyvault); и подсеть appGw вводится в New-AzApplicationGateway через аргумент -GatewayIpConfigurations, appGw, похоже, не может получить доступ к хранилищу ключей (идентификатор также имеет права доступа в политиках доступа к хранилищу ключей).

Когда я разрешаю доступ к хранилищу ключей из «всех сетей», кажется, что все работает нормально.

Возможно, в процессе создания appGw доступ к хранилищу ключей осуществляется до того, как appGw настроен с подсетью, и хранилище ключей затем видит этот доступ откуда-то еще, кроме подсети?

Я запускаю сценарий PowerShell локально, но мой IP-адрес также имеет доступ к хранилищу ключей, так что это не должно быть проблемой.

Я вижу ту же проблему

@ SubhashVasarapu-MSFT

У меня такая же проблема. Я использую Azure CLI 2.0.76. Мой шлюз приложений и хранилище ключей находятся в разных группах ресурсов в одной подписке. В хранилище ключей включено мягкое удаление, к нему можно получить доступ из всех сетей, и в нем есть политика доступа для назначенного пользователем шлюза приложений идентификатора с разрешением на получение секретов.

az network application-gateway ssl-cert create -g XXX --gateway-name XXX --name XXX --key-vault-secret-id https://XXX.vault.azure.net/secrets/XXX --debug

приводит к (сокращенно)

msrest.http_logger : {
  "status": "Failed",
  "error": {
    "code": "ApplicationGatewayKeyVaultSecretException",
    "message": "Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:",
    "details": [
      {
        "code": "ApplicationGatewayKeyVaultSecretAccessDenied",
        "message": "Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret."
      }
    ]
  }
}
msrest.exceptions : Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:
cli.azure.cli.core.util : Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.
Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.

Если я отредактирую HTTP-прослушиватель шлюза приложений на портале Azure и попытаюсь получить там сертификат SSL из хранилища ключей, я получу следующую ошибку:

Не удалось сохранить изменения конфигурации на шлюзе приложений "XXX". Ошибка: недопустимое значение для удостоверений «XXX / провайдеры / Microsoft.ManagedIdentity / userAssignedIdentities / XXX». Ключи свойств UserAssignedIdentities должны быть только пустыми объектами json, null или свойством существующего ресурса.

Привет, у меня такая же проблема. Проблема, по-видимому, заключается в том, что хотя keyvault разрешает доступ из подсети appGw (через колонку настроек брандмауэров и виртуальных сетей в конфигурации keyvault); и подсеть appGw вводится в New-AzApplicationGateway через аргумент -GatewayIpConfigurations, appGw, похоже, не может получить доступ к хранилищу ключей (идентификатор также имеет права доступа в политиках доступа к хранилищу ключей).

Когда я разрешаю доступ к хранилищу ключей из «всех сетей», кажется, что все работает нормально.

Возможно, в процессе создания appGw доступ к хранилищу ключей осуществляется до того, как appGw настроен с подсетью, и хранилище ключей затем видит этот доступ откуда-то еще, кроме подсети?

Я запускаю сценарий PowerShell локально, но мой IP-адрес также имеет доступ к хранилищу ключей, так что это не должно быть проблемой.

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

Если я отредактирую HTTP-прослушиватель шлюза приложений на портале Azure и попытаюсь получить там сертификат SSL из хранилища ключей, я получу следующую ошибку:

Не удалось сохранить изменения конфигурации на шлюзе приложений "XXX". Ошибка: недопустимое значение для удостоверений «XXX / провайдеры / Microsoft.ManagedIdentity / userAssignedIdentities / XXX». Ключи свойств UserAssignedIdentities должны быть только пустыми объектами json, null или свойством существующего ресурса.

@wolfganggallo Я получаю точно такую ​​же ошибку. Мой лазурный портал теперь тоже застрял в состоянии ошибки и не позволяет мне вносить какие-либо изменения. Тебе удалось это исправить?

Att: @ SubhashVasarapu-MSFT - пожалуйста, откройте снова.

У меня такая же проблема: «_Ключи свойств 'UserAssignedIdentities' должны быть только пустыми объектами json, null или существующим ресурсом property_», а мое - keyvault в другой группе ресурсов и vnet. Я думаю, что в моем случае vnets не отслеживаются, поэтому нет маршрута между экземпляром APIM и хранилищем ключей во время выполнения, но пользовательский интерфейс портала Azure по-прежнему будет указывать хранилище ключей как доступное для использования и разрешать его привязку к прослушивателю. Я собираюсь создать временный пиринг vnet, чтобы увидеть, решит ли он проблему, чтобы я мог удалить прослушиватель. В результате мой Appgw в настоящее время не работает:

ОБНОВЛЕНИЕ Да, вот в чем проблема. Портал Azure покажет вам хранилища ключей, которые фактически недоступны во время выполнения, а сохранение настроек слушателя нарушит работу вашего Appgw. Быстрое решение - перейти в хранилище ключей и временно открыть его для «всех сетей / Интернета», а затем повторно сохранить слушателя. Что делать дальше, зависит от вас: скопируйте сертификат в локальное хранилище ключей, или добавьте пиринг vnet, или добавьте недостающую подсеть. В конечном итоге портал должен проверить доступность сети между appgw и kyvault. Ошибка.

2-е ОБНОВЛЕНИЕ Для ясности: это ПОЛНОСТЬЮ ПЕРЕРЫВАЕТ интерфейс портала. AppGw НЕВОЗМОЖНО исправить через портал. Последующие сохранения терпят неудачу.

Я просто столкнулся с этой ошибкой в ​​интерфейсе портала. Мягкое удаление включено. Разрешение обхода всех сетей сработало.

Пожалуйста, откройте снова, возможность использовать белый список - хорошая безопасность.

@ SubhashVasarapu-MSFT Пожалуйста, откройте снова. Мы справляемся с аналогичной проблемой. Интерфейс портала полностью сломан.

Каждая операция завершается ошибкой со следующим сообщением:
Set-AzApplicationGateway : Either Data or KeyVaultSecretId must be specified for Certificate '/subscriptions/********-****-****-****-************/resourceGroups/**-***-ApplicationGateway-RG/providers/Microsoft.Network/ applicationGateways/**-***-Shared-WAF/sslCertificates/wildcard2022' in Application Gateway.

@PgInsight @oising Вам нужно было только установить «Разрешить все сети», чтобы AppGw снова заработал? У нас есть проблема с теми же симптомами, но у нас KeyVault в той же подсети, возможно, другая основная причина.

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

@PgInsight @oising Вам нужно было только установить «Разрешить все сети», чтобы AppGw снова заработал? У нас есть проблема с теми же симптомами, но у нас KeyVault в той же подсети, возможно, другая основная причина.

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

Установка всех сетей Allow в KeyVault, и нам также нужно было установить флаг Soft Delete в Key Vault с помощью PowerShell cmd.

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "YOUR-VAULT-NAME").ResourceId).Properties | Add-Member -MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true"

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties

Я была такая же проблема. Однако мне удалось решить проблему, удалив сертификат Key Vault с помощью PowerShell, а не проводник ресурсов с помощью проводника, показавший следующую ошибку:
{
"ошибка": {
"code": "MissingIdentityIds",
"message": "Идентификационные идентификаторы не должны быть пустыми или пустыми для типа идентификатора 'UserAssigned'."
}

}

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

удалить слушателя и сертификат из приложения gw

$ AppGw = Get-AzApplicationGateway -Name "app-gw-ssl-key" -ResourceGroupName "lab"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $ AppGw -Name "https"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $ AppGW -Name "victor-cer"

Сохранить изменения

set-azapplicationgateway -ApplicationGateway $ AppGW

когда шлюз приложений находился вне состояния сбоя, я проверил политику доступа хранилища ключей и увидел, что идентификатор приложения gw находится в другой категории, отличной от «ПРИЛОЖЕНИЕ». Я предполагаю, что это было причиной проблемы.
Снова добавлен идентификатор в политику доступа из параметров хранилища ключей, и он может отображаться как «ПРИЛОЖЕНИЕ». Это решило проблему для меня, и я смог без проблем добавить слушателя с сертификатом из хранилища ключей.

@ SubhashVasarapu-MSFT Это необходимо снова открыть. Шлюз приложений никогда не должен попадать в такое отключенное / сломанное состояние - я снова столкнулся с той же проблемой. Как это можно обострить? Это не проблема документации. Это проблема качества продукции.

Подвести итоги:

При настройке прослушивателя для использования сертификата SSL в удаленном хранилище ключей пользовательский интерфейс портала позволит вам настроить прослушиватель с хранилищем ключей, которое недоступно во время выполнения для appgw из-за сетевых ограничений (не открыто для Интернета, только для выбранных подсетей). После того, как вы это сделаете, интерфейс портала App Gateway будет СЛОМАН для всех слушателей.

Я передам это соответствующей команде.

Какой у этого статус?

Мы нашли одну из причин этой ошибки с PG. Если у вас был установлен период хранения в KeyVault, отличный от 90 дней по умолчанию, AppGW выдавал это сообщение об ошибке, даже если вы включили мягкое удаление и общесетевые настройки доступа. В настоящее время идет обновление для исправления этой ошибки.

Когда это будет разворачиваться? Я тоже столкнулся с этой проблемой, и это действительно большая проблема, когда невозможно настроить или внести какие-либо изменения из Portal после того, как вы столкнетесь с ним.

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

У меня точно такая же проблема, даже если срок хранения по умолчанию составляет 90 дней .
Wether, использующий Azure CLI, Powershell, TerraForm или Portal, всегда получаю одну и ту же ошибку: «Возникла проблема при доступе и проверке секретов KeyVault, связанных со шлюзом приложений ...».

Triple проверил политики идентификации и доступа, все ресурсы в одной группе ресурсов в местоположении «Западная Европа».

@ CMS-seglo, значит, вы говорите, что у вас есть:

• [x] мягкое удаление включено
• [x] срок хранения по умолчанию 90 дней
• [x] сеть настроена на все сети
• [x] и идентификатор appgw настроены правильно

и вы все еще получаете эту ошибку?

@ mark-szabo Я поставил все эти флажки. И шаблон ARM выдает мне ошибку:

"Invalid value for the identities '/subscriptions/<sub-id>/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property."

Свойство устанавливается так:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
           "[parameters('gatewayIdentityId')]": {
                 "principalId": "[parameters('identityObjectId')]",
                 "clientId": "[parameters('identityClientId')]"
            }
     }
}

Параметры:

New-AzResourceGroupDeployment -Name "Gateway" `
        -ResourceGroupName "wb-devtest-core" `
        -TemplateFile './arm_templates/appgateway.azrm.json' `
        -TemplateParameterObject @{ `
            certificateSecretUrl    = "https://my-key-vault.vault.azure.net/secrets/some-name/some-id"; `
            certificateName         = "certNamel"; `
            gatewayIdentityId       = "/subscriptions/sub-id/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity"; `
            identityClientId        = "id-here"; `
            identityObjectId        = "objIdHere";

РЕДАКТИРОВАТЬ:

Даже когда я изменил ARM на собственный ssl-сертификат с необработанными данными. Свойство Identity по-прежнему вызывает ту же ошибку.

Любое решение для этого?

@ mark-szabo, спасибо за ваш ответ, я снова смог просмотреть всю настройку свежим взглядом и нашел одну точку, в которой моя конфигурация отличалась: брандмауэр KeyVault был настроен на «Частная конечная точка и выбранные сети», но с "Разрешить доверенным службам Microsoft обходить этот брандмауэр?" установлен на включенный.
Когда я разрешил «Все сети», я смог успешно создать прослушиватель https на портале с сертификатом SSL от KeyVault. Похоже, что проблема с сетевыми ограничениями все еще существует.

@ CMS-seglo Ага, это известная проблема, отслеживаемая здесь: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski Что вы установили для «certificateSecretUrl»? «some-id» в вашем URL-адресе должен быть «версией» объекта сертификата в KeyVault. К сожалению, это не возвращается ни 'az keyvault certificate list --vault-name ...', ни 'Get-AzKeyVaultSecret' или 'Get-AzKeyVaultCertificate' в Powershell, но отображается на портале, когда вы смотрите на сертификат в KeyVault .

У меня была та же вводящая в заблуждение ошибка, о которой вы упоминали выше, потому что был создан «сломанный» сертификат. Как только я выяснил правильный идентификатор, все заработало.

@kszymanski Что вы установили для «certificateSecretUrl»? «some-id» в вашем URL-адресе должен быть «версией» объекта сертификата в KeyVault. К сожалению, это не возвращается ни 'az keyvault certificate list --vault-name ...', ни 'Get-AzKeyVaultSecret' или 'Get-AzKeyVaultCertificate' в Powershell, но отображается на портале, когда вы смотрите на сертификат в KeyVault .

У меня была та же вводящая в заблуждение ошибка, о которой вы упоминали выше, потому что был создан «сломанный» сертификат. Как только я выяснил правильный идентификатор, все заработало.

Здесь это запутано. Я устанавливаю идентификатор с портала, я пробовал как идентификатор сертификата, так и секретный идентификатор, но в обоих случаях не повезло. Также, как уже упоминалось, даже установка сертификата с необработанными данными и паролем (полностью удаленные ссылки на Key Vault) ничего не меняют, все равно ошибка. Поэтому я думаю, что это может быть проблема с назначением личности, а не с URL-адресом сертификата хранилища ключей.

В конце концов мне пришлось вручную загрузить сертификат и пароль вместо использования KeyVault, потому что я не мог заставить KeyVault работать. Однако, если вы делаете это с портала после получения этой ошибки, вам необходимо создать новый шлюз приложений, как упоминал кто-то другой. По какой-то причине вы не сможете настроить свой шлюз с ошибками.

Как видите, я постоянно создаю его из шаблона ARM. И внесение изменений вручную после его создания btw. то на портале я могу без проблем назначить этот идентификатор и сертификат.

@kylehayes , это не совсем правильно. Да, в настоящее время вы не можете вывести его из состояния сбоя с портала, но вы можете сделать это с помощью PowerShell или интерфейса командной строки.

Например. удалите отказавший прослушиватель, правило и сертификат и обновите GW.

$AppGw = Get-AzApplicationGateway -Name "<name>" -ResourceGroupName "<rg_name>"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $AppGw -Name "<listener_name>"
Remove-AzApplicationGatewayRequestRoutingRule -ApplicationGateway $AppGW -Name "<rule_name>"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $AppGW -Name "<cert_name>"
Set-AzApplicationGateway -ApplicationGateway $AppGW

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

1. По-прежнему существует проблема с периодом мягкого удаления (хранения), отличным от 90 дней. В этом случае возникает ошибка: «Ключи свойств 'UserAssignedIdentities' должны быть только пустыми объектами json, null или свойством существующего ресурса. _ » (Кстати, в этом сообщении об ошибке есть опечатка.) https://resources.azure.com/ .

2. Уровень управления App GW использует несколько случайных IP-адресов в Azure DC для доступа к KV. См. Https://github.com/MicrosoftDocs/azure-docs/issues/48866. В качестве обходного пути вы можете найти IP-адрес в журналах аудита KV (OMS или учетная запись хранилища) и добавить его в список разрешенных вместо разрешения всех сетей. К сожалению, нет гарантии, что IP останется прежним. Кроме того, вы должны постоянно держать этот IP-адрес в списке, потому что любое изменение в конфигурации App GW приводит к перестраиванию всего объекта конфигурации.

Итак, чтобы исправить "неработающее" приложение GW с портала, вам необходимо:

1. Убедитесь, что период мягкого удаления KV составляет 90 дней.
2. KV firewall отключен
3. выполнить любое действие управления на портале, которое вызовет обновление объекта конфигурации App GW.

К сожалению, вам все равно придется использовать PS для очистки объекта конфигурации от ссылок на сертификаты в KV, поскольку объекты сертификатов не отображаются в пользовательском интерфейсе портала.

Всю эту историю интеграции KV / AppGW нужно было лучше протестировать перед выпуском.

Мы столкнулись с тем же симптомом («Ключи свойств 'UserAssignedIdentities' должны быть только пустыми объектами json, null или свойством существующего ресурса.»), Наш период мягкого удаления составляет 90 дней и брандмауэр открыт. У нас есть KV в «постоянной» группе ресурсов, а стек приложений - в временной группе. Неделю назад разорвал стек DEV и попытался восстановить его (через ARM), и процесс на шлюзе приложений завершился ошибкой, то есть мы не можем заниматься разработкой, пока это снова не заработает.

Я также столкнулся с той же проблемой при развертывании из шаблона ARM, я сохранял мягкое удаление в течение 90 дней и брандмауэр открыт для всех сетей, но все еще сталкиваюсь с той же проблемой. Он работает с портала, но не из шаблона ARM.
. Ключи свойств UserAssignedIdentities должны быть только пустыми объектами json, null или свойством существующего ресурса.

Это уже третий раз, когда такой же appgateway уходит в ла-ла-ленд. Не могу остановиться и / или обновить:
{
"ошибка": {
"code": "MissingIdentityIds",
"message": "Идентификационные идентификаторы не должны быть пустыми или пустыми для типа идентификатора 'UserAssigned'."
}
}

Если честно. Я отказался от него, так как он нестабильный.

В чт, 23 апреля 2020 г. в 15:46 pererap01 [email protected] написал:

Это уже третий раз, когда такой же appgateway уходит в ла-ла-ленд. Не могу остановиться и
или обновить:
{
"ошибка": {
"code": "MissingIdentityIds",
"message": "Идентификационные идентификаторы не должны быть пустыми или пустыми для 'UserAssigned'
Тип идентификации."
}
}

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

нам пришлось поставить еще один и использовать его, потому что оригинал шелушится! У меня есть запрос в MS по этой проблеме ... посмотрим, будет ли она решена на этот раз?

@ SubhashVasarapu-MSFT есть ли способ перечислить потенциальных блокировщиков, почему происходит такое непоследовательное? Может быть основной причиной / ограничением.

Было бы еще лучше, если бы мы узнали, каков текущий статус исправления.

Как и у других в этой теме, у меня тоже возникла ошибка:

Failed to save configuration changes to application gateway <REDACTED>. Error: Either Data or KeyVaultSecretId must be specified for Certificate <REDACTED>...

В политике доступа к хранилищу ключей я включил все разрешения для ключей, секретов и сертификатов для управляемого удостоверения, используемого шлюзом Azure. Я уверен, что это перебор, но, попробовав несколько других разрешений, я разочаровался и просто включил все. Впоследствии ошибка исчезла.

PS e2e TLS при использовании сертификата, подготовленного для облака, - это очень распространенный сценарий. Как новичок в Azure, я очень разочарован тем, что это еще не отполированный опыт.

Я пытаюсь получить секреты и сертификаты из KeyVault в свой кластер через шлюз приложений, что приводит к сбою моего приложения, поскольку оно не может пройти аутентификацию в KV, что приводит к ошибке Bad Gateway.

Идентификатор соединения «0HM0BI3H5TUJP», идентификатор запроса «0HM0BI3H5 TUJP: 00000001 »: приложение
Идентификатор соединения «0HM0BI3H5TUNQ», идентификатор запроса «0HM0BI3H5 TUNQ: 00000002 »: приложение

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

В My KeyVault включено мягкое удаление с периодом хранения по умолчанию 90 дней и для всех сетей. Мое удостоверение шлюза приложений также правильно настроено в Vault. Кто-нибудь знает, где я ошибаюсь?

Я работаю с инженером из MS
Это краткое изложение того, что я узнал

1. Удалите все сертификаты, связанные со слушателями Appgateway. В основном удаление всех установленных сертификатов appgateway
   проверить: PS
   az network application-gateway ssl-cert list -g (группа ресурсов) --gateway-name (имя шлюза)
   если появится следующее
   "keyVaultSecretId": ноль,
   сертификат установлен на appgateway и большинство из них не связаны
2. Как только сертификат отсутствует в appgateway, свяжите сертификат из хранилища ключей, и он должен работать.

Я работаю с инженером из MS
Это краткое изложение того, что я узнал

1. Удалите все сертификаты, связанные со слушателями Appgateway. В основном удаление всех установленных сертификатов appgateway
   проверить: PS
   az network application-gateway ssl-cert list -g (группа ресурсов) --gateway-name (имя шлюза)
   если появится следующее
   "keyVaultSecretId": ноль,
   сертификат установлен на appgateway и большинство из них не связаны
2. Как только сертификат отсутствует в appgateway, свяжите сертификат из хранилища ключей, и он должен работать.

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

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

Я пока не касаюсь самого Key Vault, чтобы служба поддержки MS могла видеть его в текущем состоянии.

Откуда возникает сообщение об ошибке? Это версия 2 с включенным WAF?

Да, V2 WAF. Ошибка выходит из ARM. Выполняется из агента Windows, размещенного в ADO, с использованием интерфейса командной строки AZ

az group deployment create --debug --mode Complete

Примечание. Шаблон ARM включает весь стек, виртуальную сеть, виртуальные машины, APG и т. Д. При этом Key Vault и другие элементы сохраняются в отдельной группе ресурсов.

Ах хорошо….

От: Платформа автоматизации непрерывной доставки [email protected]
Отправлено: понедельник, 8 июня 2020 г., 13:01
Кому: MicrosoftDocs / azure-docs [email protected]
Копия: Перера, Приянта, Арвато SCS [email protected]
Тема: Re: [MicrosoftDocs / azure-docs] Шлюз приложений: интеграция с Key Vault не работает (# 33157)

Да, V2 WAF. Ошибка выходит из ARM. Выполняется из агента Windows, размещенного в ADO, с использованием интерфейса командной строки AZ

az group deployment create --debug --mode Complete

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F33157%23issuecomment-640855594&data = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826294946 & SData = qdtJwYk5QV8evtt8Bp% 2B1% 2Bn7lkz5ebEG% 2BCMAfdQVmSS4% 3D & зарезервирован = 0 , или отказаться от https://eur02.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-AUTH% 2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A & данные = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826304943 & SData = TgPtoOi5neDLlb% 2B0hk% 2BEULQyZSUFV8fy4deb9RgUsKk% 3D & зарезервирован = 0 .

@ pererap01
вы используете «--mode Complete» - это потенциально удаляет «скрытые» ресурсы, не определенные в шаблоне.
Кроме того, пользователь / субъект службы, выполняющий развертывание, должен иметь возможность читать MSI, который будет использоваться WAF для доступа к KV, если этот MSI не является частью развертывания.

@gaikovoi , думаю, эта ссылка была для меня. Мы используем одну и ту же ARM и выполнение в трех средах, и все они работали нормально. Среда DEV разрушалась каждую пятницу и воссоздалась каждый понедельник, поэтому у команды была свежая среда для работы в течение недели (мы иногда проводили специальное разрушение / восстановление, если один из DEV создавал беспорядок). Однажды он просто не всплыл, хотя другие аспекты развертывания не изменились.

@cdaf сегодня была проблема с ARM
Решено: RCA - диспетчер ресурсов Azure - сбои при создании или удалении ресурсов.

Как бы то ни было, иногда развертывание ARM терпит неудачу без веской причины. Обычно это устраняется перезапуском конвейера AzDO.

@gaikovoi , да, ARM может быть очень вспыльчивым (особенно если вы попытаетесь развернуть APIM через ARM), однако здесь это не тот случай, он был повторен почти 30 раз (разными людьми, пытающимися диагностировать это)

Привет всем. Я создал учетную запись, чтобы ответить на это, потому что это было очень неприятно. Для тех, кто, как я, не может или не хочет устанавливать KeyVault для всех сетей ... Я нашел обходной путь. Если вы перейдете в обозреватель ресурсов и удалите следующее, ваш шлюз приложений снова должен быть счастливым.

1. Удалить объект идентификации
2. Удалите сертификат, вызвавший сбой, в sslCertificates
3. Удалите все вхождения вашего неудачного слушателя
4. ВЫПОЛНИТЕ свои изменения

Это немедленно вызвало обновление моего шлюза приложений и его работоспособное состояние подготовки. По общему признанию, я был слишком выжат / разочарован процессом, чтобы попытаться выполнить интеграцию KeyVault, поэтому я просто загрузил сертификат непосредственно в шлюз приложений, и он работал нормально. Интеграция KeyVault действительно должна быть исправлена ​​Microsoft ...

Anywho, надеюсь, что это кому-то поможет.

Ура.

Просто чтобы повторить все вышеперечисленное. Эта проблема определенно все еще присутствует в Azure и, честно говоря, поражает меня.

После добавления управляемого удостоверения для управления разрешениями для сертификата с подстановочными знаками, ПОКУПНОГО ИЗ AZURE, а затем выполнения всех задокументированных шагов по добавлению этого сертификата в шлюз, по-прежнему возникает ошибка, указывающая на то, что удостоверение не имеет доступа к хранилищу. Проверьте и хранилище, и сертификат, чтобы убедиться, что у него действительно есть доступ, что он и делает. Решите продвигать разрешения с простого доступа только для чтения к владельцу, чтобы увидеть, устраняет ли это проблему, и выдавите ошибку, касающуюся блокировок в сертификате с подстановочными знаками.

Таким образом, я не только не могу добавить сертификат с помощью метода Key Vault, но теперь пытаюсь очистить элементы или изменить разрешения удостоверения после попытки нескольких конфигураций, я даже не могу удалить удостоверение из Azure, не сняв блокировку «Удалить» на подстановочный сертификат, приобретенный клиентом. Честно говоря, самый простой метод, который я нашел здесь, - это экспортировать сертификат, добавить пароль в файл .pfx и, наконец, повторно загрузить его во время создания шлюза. Все это было сделано через графический интерфейс в надежде создать правильный шаблон ARM для использования во время подготовки через Terraform. Все еще сломан.

Это кажется довольно фундаментальной вещью, которую Azure просто игнорирует.

Какой абсолютный кошмар - я не могу поверить, что за год отзывов и проблем это все еще не исправлено. Наше хранилище ключей было открыто для всех сетей, мягкое удаление было включено и установлено на 90 дней, и первая попытка связать эти две сети привела к сбою шлюза.

Это действительно сильно испорченный продукт. 😠

Тоже самое. Как это может быть открытым вопросом более 1 года. Ужасно использовать App Gateway WAF v2.
Когда это будет исправлено?

Все еще вещь! В моем случае это сетевая интеграция keyvault. Портал определенно не проверяет это и дает сбой из-за ошибки случайных ключей свойств (а не запрещенной ошибки, как вы ожидали). Может ли кто-нибудь подтвердить, что включение конечных точек службы VNET для Microsoft.Keyvault в подсети шлюза позволит этой интеграции работать с включенным KeyVault FW?

Попытка «Обновить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с включенным FW + включен IPWhitelist

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(на том же слушателе выше) Попытка «Обновить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с FW DISABLED

• УСПЕХ

_На другом слушателе_
Попытка «Продлить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с ОТКЛЮЧЕННЫМ ПО

• УСПЕХ

Привет всем. Я создал учетную запись, чтобы ответить на это, потому что это было очень неприятно. Для тех, кто, как я, не может или не хочет устанавливать KeyVault для всех сетей ... Я нашел обходной путь. Если вы перейдете в обозреватель ресурсов и удалите следующее, ваш шлюз приложений снова должен быть счастливым.

1. Удалить объект идентификации
2. Удалите сертификат, вызвавший сбой, в sslCertificates
3. Удалите все вхождения вашего неудачного слушателя
4. ВЫПОЛНИТЕ свои изменения

Это немедленно вызвало обновление моего шлюза приложений и его работоспособное состояние подготовки. По общему признанию, я был слишком выжат / разочарован процессом, чтобы попытаться выполнить интеграцию KeyVault, поэтому я просто загрузил сертификат непосредственно в шлюз приложений, и он работал нормально. Интеграция KeyVault действительно должна быть исправлена ​​Microsoft ...

Anywho, надеюсь, что это кому-то поможет.

Ура.

В такой же ситуации !. Я добавлю сертификат напрямую и не буду использовать KeyVault, так как мне также нужно ограничить Key Vault подсетями.
Привет, Руи

Удар! Это все еще проблема с использованием Terraform. Если на KV включен брандмауэр, подготовка AppGW не выполняется.

Уже много чего перепробовал:

• На КВ включили
  
  
  
  • Azure Resource Manager для развертывания шаблона
  
  
  • Разрешить доверенным службам Microsoft обходить этот брандмауэр?
  
  
• Конечная точка службы в подсети AppGW и добавление сети на KV FW
• Добавление публичного IP AppGW в KV FW

... Ни один из них не работает. Единственное решение - отключить брандмауэр в хранилище ключей.

Также есть эта проблема. Пожалуйста, исследуйте!

Все еще вещь! В моем случае это сетевая интеграция keyvault. Портал определенно не проверяет это и дает сбой из-за ошибки случайных ключей свойств (а не запрещенной ошибки, как вы ожидали). Может ли кто-нибудь подтвердить, что включение конечных точек службы VNET для Microsoft.Keyvault в подсети шлюза позволит этой интеграции работать с включенным KeyVault FW?

Попытка «Обновить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с включенным FW + включен IPWhitelist

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(на том же слушателе выше) Попытка «Обновить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с FW DISABLED

* SUCCESS

_На другом слушателе_
Попытка «Продлить или отредактировать» уже существующий сертификат, загруженный в GW + Использовать PAAS KV с ОТКЛЮЧЕННЫМ ПО

* SUCCESS

Мне кажется, это не работает. Я тоже пробовал много комбинаций. Единственным решением было полностью отключить мой брандмауэр KV.

Похоже, это относится и ко мне; только полное отключение брандмауэра keyvault делает эту работу.

Та же проблема и для меня ... как это еще не решить?

Я не понимаю - мы с этим тоже столкнулись. Какая здесь правильная конфигурация ??

Открыв заявку в службу поддержки Azure, я получил официальный ответ:
«Как объяснялось в ходе нашего разговора, шлюз приложений в настоящее время не поддерживает интеграцию с Key Vault, если Key Vault не настроен на разрешение доступа к« общедоступным конечным точкам (все сети) ».
В настоящее время мы работаем внутри компании с необходимыми группами для поддержки всех сетевых конфигураций Key Vault в отношении интеграции со шлюзом приложений.

Официальная документация по этому поводу скоро появится ".

@lonevvolf. Вы можете открыть хранилище ключей для всех сетей, привязать сертификат SSL с управляемым идентификатором к вашим слушателям, а затем брандмауэром хранилища ключей (или заблокировать его для виртуальной сети). Appgw продолжит работу с _cached_ ssl-сертификатом, но затем, когда вы заменяете сертификат в хранилище ключей до истечения срока его действия, appgw не сможет перейти на обновленный сертификат. Так что вы должны быть осторожны с этим. Но да, он сломан.

@Microsoft Можно ли получить

Как объяснялось во время нашего разговора, шлюз приложений в настоящее время не поддерживает интеграцию с Key Vault, если Key Vault не настроен на разрешение доступа к «общедоступным конечным точкам (все сети)».
В настоящее время мы работаем внутри компании с необходимыми группами для поддержки всех сетевых конфигураций Key Vault в отношении интеграции со шлюзом приложений.

Кроме того, это ограничение нужно где-то задокументировать. Можно ли где-нибудь найти это утверждение в документации MSFT?

Например, в этом документе должно быть указано следующее: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising, как вы упомянули "Вы можете открыть хранилище ключей для всех сетей, связать сертификат SSL с управляемым идентификатором для ваших слушателей, а затем брандмауэром хранилища ключей (или заблокировать его для vnet). . "

Поддерживает ли az cli эту функцию? Можем ли мы создать прослушиватель http в шлюзе приложений с сертификатом ssl (извлекая его из сертификатов хранилища ключей) с помощью az cli? Если да, не могли бы вы предоставить команду az cli. заранее спасибо.

@lonevvolf. Вы можете открыть хранилище ключей для всех сетей, привязать сертификат SSL с управляемым идентификатором к вашим слушателям, а затем брандмауэром хранилища ключей (или заблокировать его для виртуальной сети). Appgw продолжит работу с _cached_ ssl-сертификатом, но затем, когда вы заменяете сертификат в хранилище ключей до истечения срока его действия, appgw не сможет перейти на обновленный сертификат. Так что вы должны быть осторожны с этим. Но да, он сломан.

Хм. Что, если вы выключите брандмауэр Key Vault перед установкой обновленного сертификата, а затем снова включите его? Увидит ли AGW изменение и достаточно быстро получит новый сертификат, пока не работает брандмауэр? В настоящее время я работаю над функцией Azure с таймером для обработки обновления сертификата в Key Vault с помощью certbot / Let's Encrypt. Я смогу написать несколько команд az для отключения и повторного включения брандмауэра Key Vault во время обновления сертификата в Key Vault.

Глупо, что это вообще необходимо. : /

Кто-нибудь знает, есть ли план поддержки FW в хранилище ключей -> «Частная конечная точка и выбранные сети»?

Добавление еще одного комментария, чтобы повторить мнение других. Эта проблема очень неприятна, так как открытие всех сетей для Key Vault часто не является решением для многих организаций. Я сталкиваюсь с этим, используя Terraform, и в настоящее время мне приходится работать над этим. Исправление от @microsoft было бы здорово.

То же самое для меня, у нас не может быть открытого для Интернета kv или appgw, и мы не можем использовать эту функцию столько, сколько захотим. : /

Сегодня та же проблема. :(

Еще один жизнеспособный вариант для людей, недовольных борьбой с appgw, - это использовать Azure Frontdoor (это в основном урезанный appgw), но он работает только в общедоступных сетях (без vnets) - он может автоматически генерировать общедоступные сертификаты SSL.

Мы активно работаем над тем, чтобы позволить AppGW работать с KeyVaults, настроенным так, чтобы разрешать только частные конечные точки и выбирать доступ к сети. В соответствии с предложением @jmcshane мы обновили документы, включив в раздел «Как работает интеграция» важное примечание относительно этого ограничения. Мы обновим этот поток, а также документацию, как только AppGW сможет поддерживать все конфигурации KeyVault.

@skinlayers, которые могут работать - не узнает, пока вы не попробуете!

Я смог исправить это, выполнив следующие шаги:

• Удалите существующий профиль ssl-cert с помощью az network application-gateway ssl-cert remove
• Временно отключить брандмауэр и разрешить доступ из всех сетей
• Снова привяжите сертификат из Azure Key Vault (я дважды проверил, все ли разрешения удостоверения службы в порядке).
• Снова отключить доступ из всех сетей

Все работает нормально

ПРИМЕЧАНИЕ. Указанный выше обходной путь не рекомендуется. Microsoft предупредила нас, что, поскольку этот метод был использован и брандмауэр был снова включен, будущие операции автомасштабирования на шлюзе приложений завершатся ошибкой ! Это действительно требует полного исправления от Microsoft.