Развертывание службы приложений Azure возвращает (403) Запрещено с ограничением IP
В Azure я включил ограничения IP для:
- Веб-приложение (Сеть> Ограничения доступа)
- Сервер SQL (Брандмауэры и виртуальные сети> Добавить IP-адрес клиента)
- База данных SQL (настройка параметров сервера)
Решение по-прежнему строится локально и в DevOps (он же Team Foundation Server).
Однако развертывание службы приложений Azure завершается ошибкой:
##[error]Failed to deploy App Service.
##[error]Error Code: ERROR_COULD_NOT_CONNECT_TO_REMOTESVC
More Information: Could not connect to the remote computer
("MYSITENAME.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer.
Error: The remote server returned an error: (403) Forbidden.
Error count: 1.
Как я могу развернуть через брандмауэр?
Нужна ли мне виртуальная сеть, чтобы скрыть ресурсы Azure за моим белым IP-адресом?
7 ответов
REST сайт scm.azurewebsites.net должен иметь Allow Allт.е. без ограничений. Также, Same restrictions as handyquip.azurewebsites.net должно быть unchecked,
Это не требует дополнительных ограничений, потому что для доступа к URL-адресу уже требуются учетные данные Microsoft. Если будут добавлены ограничения, развертывание приведет к сбою брандмауэра, отсюда и многие сложности, с которыми я столкнулся.
Я думаю, что ответ неверен, так как вы можете столкнуться с эксфильтрацией данных, и именно по этой причине Microsoft предоставляет функцию блокировки портала SCM (консоль Kudu). На портале Kudu также есть проблема безопасности, поскольку он может отображать секрет вашего хранилища ключей ( если вы используете keyvault), и вы не хотите, чтобы кто-то в вашей организации, например, получил доступ к порталу Kudu.
Вы должны перейти по этой ссылке https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops
Он предоставит вам диапазон IP-адресов Azure DevOPS, который необходимо разрешить при ограничении доступа SCM.
Обновление: чтобы он работал должным образом и для использования ограничения доступа к службе приложений (то же самое для функции Azure), вам необходимо использовать теги службы «AzureCloud», а не диапазон IP-адресов Azure DevOPS, поскольку этого недостаточно. в журналах Azure Pipeline вы можете увидеть заблокированный IP-адрес, чтобы вы могли видеть, что он находится в ServiceTags «AzureCloud» в JSON-файле сервисных тегов. В документе MS не совсем ясно, но причина в том, что они изо всех сил пытались определить правильный IP-адрес. диапазон для Azure DevOPS Pipeline, поэтому они используют IP-адреса из тега службы AzureCloud. https://www.microsoft.com/en-us/download/details.aspx?id=56519
Попробуйте добавить параметр приложения WEBSITE_WEBDEPLOY_USE_SCM со значением false в свою службу приложений Azure. Это помогло решить мои проблемы с развертыванием на частной конечной точке.
В моем случае это произошло потому, что дневная квота была превышена.
Таким образом, решение в этом случае - либо ждать, либо платить больше (масштабировать) службу приложения.
http s:https://stackru.com/images/45992f70633a293e5d73ca38d9cf808447c4497b.png
В моем случае я развертывал с использованием DevOps Azure и получил ошибку. Оказалось, что служба приложений, в которой развертывался мой API, поставила флажок "Те же ограничения, что и для xxxx.azurewebsites.net", в соответствии с ограничениями доступа или ограничениями IP. вам нужно разрешить scm.azurewebsites.net.
Я использовал https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-app-service-settings-v1?view=azure-pipelines , чтобы включить publicNetworkAccess перед этапом развертывания службы приложений. (ZipDeploy, запуск из пакета). Затем я снова использую задачу после развертывания, чтобы отключить publicNetworkAccess. Это в «общих настройках» части задачи. Обратной стороной является то, что в случае сбоя развертывания publicNetworkAccess останется включенным.
Я удивлен, как мало документации существует по этому сценарию (развертывание службы приложений с отключенным доступом к общедоступной сети).
Я думаю, что это может потребовать немного меньше усилий, чем решение с тегом службы и самостоятельный агент ADO.
В моем случае это произошло из-за того, что использовался неправильный агент (хостинг Windows), когда я должен был использовать собственный внутренний агент... поэтому мне нужно было изменить его в следующем месте.
