Open u3556490 opened 4 months ago
Sorry for bumping this issue but I wonder whether anyone else has encountered similar issues? If this is an issue with the Azure RM SDK or Azure REST API I could go ask them instead. Thanks
Update: using an account with identical access levels (same role assigned), it is possible to manually update application settings of a VNET-integrated Function App in the Azure Portal. Just that using Terraform would not work. To rule out the possibility of an upstream problem (prob w/ MS Azure REST API) I will probably go open a ticket with them
Hi, I've the same issue. I've a function app with a vnet subnet assigned. I'm trying to change only docker image_name and image_tag in application stack block (inside site_config block), but I get an error which says that I need the permission "Microsoft.Network/virtualNetworks/subnets/join/action" on the linked subnet which is the one assigned to the function app. I did some tests and found that the error is related to the parameter "_virtual_network_subnetid", and I'm sure about that because if I remove the function app subnet assignment, and try to perform the same docker image name and tag change, I can perform the action through the same terraform code. So, why do I need particular role assignments to virtual network to only change the docker image parameters? Is there any ongoing process to solve this bug?
Update: I created a ticket to Microsoft support and mentioned Terraform sends a PUT request to an Azure REST API endpoint (as shown in the original post), upon which it apparently fails. They explained it is because API indeed tries to validate the whole request body, i.e. they treat it as the whole configuration and as one object. Their original words:
Yes, setting the
virtualNetworkSubnetId
site property is the same as configuring VNet integration and requires the same permissions. Then the question is why touching other unrelated config would need permissions of VNet integration.Thanks a lot for your analysis and sharing the detailed traces. We can see that Terraform uses this API Web Apps - Create Or Update Configuration - REST API (Azure App Service) | Microsoft Learn to update the site configuration (same thing would happen for ARM template, Azure CLI, etc.). The request body contains all of the configuration. This design is to treat site properties as a single object.
Therefore the following 3 permissions would be required for your Terraform credentials when it manages VNet integrated apps.
Action Description Microsoft.Network/virtualNetworks/read Read the virtual network definition Microsoft.Network/virtualNetworks/subnets/read Read a virtual network subnet definition Microsoft.Network/virtualNetworks/subnets/join/action Joins a virtual network
I wonder if there is an alternative implementation for Terraform AzureRM provider that only sends the required changes to Azure REST API - that would be nice.
Is there an existing issue for this?
Community Note
Terraform Version
1.6.6
AzureRM Provider Version
3.93.0
Affected Resource(s)/Data Source(s)
azurerm_linux_function_app
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Actual Behaviour
The planned change fails to be deployed.
Full
terraform apply
output (note some sensitive information is redacted):Steps to Reproduce
The scenario, in general, is as follows:
terraform plan
correctly shows the changes as it is in the codeterraform apply
still shows the right changes, but fails when applying themRe-creating the resources from scratch (except the network) does not help.
Using debug output, it was found that the interfering attribute is
virtual_network_subnet_id
, which has been ignored in the Terraform code. The tfstate keeps this attribute empty; when Terraform tries to connect to the AzureRM API endpoint to create/update the FuncApp, the request body correctly contains the actual non-empty subnet ID (which it obtained from prior calls to check the actual infrastructure state). This is where it fails inexplicably - AzureRM assumes a network change is being made where in reality there is none.Important Factoids
The identity with which the terraform commands are run does not have permissions to mutate network resources, this should not distract one from the nature of the issue.
References
No response