Webapp:Cannot update config of app service which has setting access restriction by subnet.

[ghost]

This is autogenerated. Please review and update as needed.

Describe the bug

Command Name
az webapp config set

Errors:

LinkedAuthorizationFailed - The client '063476f6-5454-4070-82ca-8e43e92789dc' with object id '063476f6-5454-4070-82ca-8e43e92789dc' has permission to perform action 'Microsoft.Web/sites/config/write' on scope '/<RESOURCE_ID_OF_APPSERVICE>/config/web'; however, it does not have permission to perform action 'joinViaServiceEndpoint/action' on the linked scope(s) '/<RESOURCE_ID_OF_VNET>/subnets/<SUBNET_NAME>' or the linked scope(s) are invalid.

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• Create an App Service and a VNET which has one subnet at least.
• Set Access Restriction by the subnet to the App Service
• Execute az login using a service principal which has a contributor role of the App Service and doesn't have any role the VNET.
• Execute az webapp config set --resource-group {} --name {} --always-on {}

Expected Behavior

The final command would be succeeded.

Environment Summary

Linux-4.15.0-1092-azure-x86_64-with-debian-stretch-sid (Cloud Shell)
Python 3.6.10
Installer: DEB

azure-cli 2.9.1 *

Additional Context

It is confirmed that this issue happens when executing not only az webapp config set but also az webapp config * set

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @AzureAppServiceCLI, @antcp.

[yonzhan]

webapp

[ghost]

Is there any update on this?

[ThejaChoudary]

Assigning to myself to do repro

[ghost]

hello @ThejaChoudary
can you reproduce this?

please let me know if you need further information to do it.

[panchagnula]

@hihorika can you run the command with --debug & share the logs please? it could be that that the API requires specific permissions on the VNET - which the Contributor role doesn't have. the logs will help us narrow down if this is API or CLI

[ghost]

The debug log which show 403 error is following.

I wonder why the cli command returns 403 and a user who has same role can do same operation successfully on Azure portal.

msrest.http_logger : Request URL: 'https://management.azure.com/<RESOURCE_ID_OF_APPSERVICE>/config/web?api-version=2019-08-01'
msrest.http_logger : Request method: 'PATCH'
msrest.http_logger : Request headers:
msrest.http_logger :     'Accept': 'application/json'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'accept-language': 'en-US'
msrest.http_logger :     'Content-Length': '1795'
msrest.http_logger :     'User-Agent': 'python/3.6.10 (Linux-4.15.0-1092-azure-x86_64-with-debian-stretch-sid) msrest/0.6.18 cloud-shell/1.0 msrest_azure/0.6.3 azure-mgmt-web/0.47.0 Azure-SDK-For-Python AZURECLI/2.11.0 (DEB)'
msrest.http_logger : Request body:
msrest.http_logger : {"properties": {"numberOfWorkers": 1, "defaultDocuments": ["Default.htm", "Default.html", "Default.asp", "index.htm", "index.html", "iisstart.htm", "default.aspx", "index.php", "hostingstart.html"], "netFrameworkVersion": "v4.0", "phpVersion": "", "pythonVersion": "", "nodeVersion": "", "powerShellVersion": "", "linuxFxVersion": "DOCKER|hihorika.azurecr.io/webapplication6:latest", "requestTracingEnabled": false, "remoteDebuggingEnabled": false, "remoteDebuggingVersion": "VS2019","httpLoggingEnabled": false, "logsDirectorySizeLimit": 35, "detailedErrorLoggingEnabled": false, "publishingUsername": "$switchcontainerbycli01", "scmType": "None", "use32BitWorkerProcess": true, "webSocketsEnabled": false, "alwaysOn": true, "appCommandLine": "", "managedPipelineMode": "Integrated", "virtualApplications": [{"virtualPath": "/", "physicalPath": "site\\wwwroot", "preloadEnabled": true}], "loadBalancing": "LeastRequests", "experiments": {"rampUpRules": []}, "autoHealEnabled": false, "vnetName": "384f59ad-6691-4f72-8a22-f8ab1fa4f721_appservice", "localMySqlEnabled": false, "ipSecurityRestrictions": [{"vnetSubnetResourceId": "<RESOURCE_ID_OF_VNET>/subnets/<SUBNETNAME>", "action": "Allow", "tag": "Default", "priority": 100, "name": "allow"}, {"ipAddress": "Any", "action": "Deny", "priority": 2147483647, "name": "Deny all", "description": "Deny all access"}], "scmIpSecurityRestrictions": [{"ipAddress": "Any", "action": "Allow", "priority": 1, "name": "Allow all", "description": "Allow all access"}], "scmIpSecurityRestrictionsUseMain": false, "http20Enabled": false, "minTlsVersion": "1.2", "ftpsState": "AllAllowed", "preWarmedInstanceCount": 0}}
msrest.universal_http : Configuring redirects: allow=True, max=30
msrest.universal_http : Configuring request: timeout=100, verify=True, cert=None
msrest.universal_http : Configuring proxies: ''
msrest.universal_http : Evaluate proxies against ENV settings: True
urllib3.connectionpool : Starting new HTTPS connection (1): management.azure.com:443
urllib3.connectionpool : https://management.azure.com:443 "PATCH /<RESOURCE_ID_OF_APPSERVICE>/config/web?api-version=2019-08-01 HTTP/1.1" 403 740
msrest.http_logger : Response status: 403
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-failure-cause': 'gateway'
msrest.http_logger :     'x-ms-request-id': 'cc72f829-3f12-43bb-9180-320d76fe3cf3'
msrest.http_logger :     'x-ms-correlation-request-id': 'cc72f829-3f12-43bb-9180-320d76fe3cf3'
msrest.http_logger :     'x-ms-routing-request-id': 'WESTUS:20200826T202248Z:cc72f829-3f12-43bb-9180-320d76fe3cf3'
msrest.http_logger :     'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
msrest.http_logger :     'X-Content-Type-Options': 'nosniff'
msrest.http_logger :     'Date': 'Wed, 26 Aug 2020 20:22:48 GMT'
msrest.http_logger :     'Connection': 'close'
msrest.http_logger :     'Content-Length': '740'
msrest.http_logger : Response content:
msrest.http_logger : {"error":{"code":"LinkedAuthorizationFailed","message":"The client '063476f6-5454-4070-82ca-8e43e92789dc' with object id '063476f6-5454-4070-82ca-8e43e92789dc' has permission to perform action 'Microsoft.Web/sites/config/write' on scope '/<RESOURCE_ID_OF_APPSERVICE>/config/web'; however, it does not have permission to perform action 'joinViaServiceEndpoint/action' on the linked scope(s) '/<RESOURCE_ID_OF_VNET>/subnets/<SUBNET_NAME>' or the linked scope(s) are invalid."}}
msrest.exceptions : (LinkedAuthorizationFailed) The client '063476f6-5454-4070-82ca-8e43e92789dc' with object id '063476f6-5454-4070-82ca-8e43e92789dc' has permission to perform action 'Microsoft.Web/sites/config/write' on scope '<RESOURCE_ID_OF_APPSERVICE>/config/web'; however, it does not have permission to perform action 'joinViaServiceEndpoint/action' on the linked scope(s) '/<RESOURCE_ID_OF_VNET>/subnets/<SUBNET_NAME>' or the linked scope(s) are invalid.
cli.azure.cli.core.util : LinkedAuthorizationFailed - The client '063476f6-5454-4070-82ca-8e43e92789dc' with object id '063476f6-5454-4070-82ca-8e43e92789dc' has permission to perform action 'Microsoft.Web/sites/config/write' on scope '/<RESOURCE_ID_OF_APPSERVICE>/config/web'; however, it does not have permission to perform action 'joinViaServiceEndpoint/action' on the linked scope(s) '/<RESOURCE_ID_OF_VNET>/subnets/<SUBNET>' or the linked scope(s) are invalid.
LinkedAuthorizationFailed - The client '063476f6-5454-4070-82ca-8e43e92789dc' with object id '063476f6-5454-4070-82ca-8e43e92789dc' has permission to perform action 'Microsoft.Web/sites/config/write' on scope '<RESOURCE_ID_OF_APPSERVICE>/config/web'; however, it does not have permission to perform action 'joinViaServiceEndpoint/action' on the linked scope(s) '<RESOURCE_ID_OF_VNET>/subnets/<SUBNET_NAME>' or the linked scope(s) are invalid.

[ghost]

There is a difference between REST APIs used by the cli and portal.

• The cli uses PATCH method for /config/web with api-version 2019-08-01
  and its payload contains ipSecurityRestrictions property.
  
• Azure portal uses PUT method for /config/web with api-version 2018-11-01

It seems that this causes the difference result.

[ghost]

Hello @panchagnula , @ThejaChoudary

I suppose that this issue is caused by both of followings:

• The cli's payload has ipSecurityRestriction property
• The property includes subnet id which the service principal does not access right for for

I checked both of the payloads with/without ipSecurityRestriction property using az rest
Then operation using the payload without this property was successfully done.

Could you please take a look this behavior and let me know why the payload of the cli includes ipSecurityRestriction property?

This property is already configured, so I think the payload in the cli doesn't need to contain the property.
Actually REST API from Azure portal use a payload without this property to do similar operation.

And our customer doesn't want to add any role for VNET/subnet

I would appreciate your help.

[panchagnula]

@hihorika in CLI we get the full SitePayload as per the API https://docs.microsoft.com/en-us/rest/api/appservice/webapps/get
portal doesn't use SDK API hence the difference. This would be a breaking change for CLI & PS and hence not something we will be able to handle anytime soon. Portal would be the best alternate for now.

[ghost]

Thanks @panchagnula

I will send followins as workaround:

• User Azure portal
• Assign a role, which contains an action joinViaServiceEndpoint/action, to the service principal

But it doesn't seem reasonable that the SP needs to has the action for the VNET/subnet even though the user doesn't change the network configuration.

Do we have a plan to change this behavior in the future, not soon?

[btardif]

@panchagnula I talked to @madsd and he was going to help take a first pass with all the access restrictions related items.