Update various files to not set SiteConfig.PublicNetworkAccess.

[pauldotknopf]

Latest Azure API changes throws errors if this setting is present in both locations:

performing CreateOrUpdate: unexpected status 400 (400 Bad Request) with response: {"Code":"BadRequest","Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be modified. Please modify the Site.PublicNetworkAccess property.","Target":null,"Details":[{"Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be modified. Please modify the Site.PublicNetworkAccess property."},{"Code":"BadRequest"},{"ErrorEntity":{"ExtendedCode":"01020","MessageTemplate":"There was a conflict. {0}","Parameters":["SiteConfig.PublicNetworkAccess cannot be modified. Please modify the Site.PublicNetworkAccess property."],"Code":"BadRequest","Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be modified. Please modify the Site.PublicNetworkAccess property."}}],"Innererror":null}

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave "+1" or "me too" comments, they generate extra noise for PR followers and do not help prioritize for review

Description

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevent documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_resource - support for the thing1 property [GH-00000]

This is a (please select all that apply):

• Bug Fix

[Mechanolatry]

@pauldotknopf - I am seeing this same issue on the azurerm_logic_app_standard resource. Will this PR address that or should I raise an new issue (This PR was the only thing I could find when looking for the error)

[pauldotknopf]

@Mechanolatry The squeaky wheel get's the grease. I'd suggest creating a new PR for it, maybe the maintainers will consolidate them.

[Apokalypt]

This fix is present in many of resources due to previous Azure API behaviour.
I think that the problem occurs in function_app_*, web_app_*, logic_app, ...

[pauldotknopf]

@Apokalypt @Mechanolatry I've updated the various locations.

I'm unsure about how to change logic_app_standard_resource.go, so I'll leave that to someone smarter than me.

[sec0ndhand]

Really needing this. Is there a timeline on when this will be merged?

[santhoshdesikachari]

We are looking to have this PR merged. Thanks @pauldotknopf for making the change!

[PG-RichT]

We're experiencing a similar issue with the other property they've removed vnetRouteAllEnabled. Any chance you could address that in here too while there's still time?

[ghost]

This change needs to be made for Logic Apps too, I believe it to be the same cause for Logic App which configure site_config, please see #25891

[madsd]

We started rolling out this change to ensure Azure policy compliance with specific network related settings (Improving App Service networking configuration control). We found that Terraform is primarily using the SiteConfig versions of the properties (vnetRouteAllEnabled and publicNetworkAccess) and in some cases do not have support for setting the Site properties.
This change will affect both Logic Apps, Function Apps and Web Apps. Please let me/us know if there is anything we can do to help add support.
We are pausing the roll out until TF can add support for the Site properties.

[hoopdad]

We started rolling out this change to ensure Azure policy compliance with specific network related settings (Improving App Service networking configuration control). We found that Terraform is primarily using the SiteConfig versions of the properties (vnetRouteAllEnabled and publicNetworkAccess) and in some cases do not have support for setting the Site properties. This change will affect both Logic Apps, Function Apps and Web Apps. Please let me/us know if there is anything we can do to help add support. We are pausing the roll out until TF can add support for the Site properties.

Are you able to share the Azure regions where this change has not been made yet? thank you!

[madsd]

We started rolling out this change to ensure Azure policy compliance with specific network related settings (Improving App Service networking configuration control). We found that Terraform is primarily using the SiteConfig versions of the properties (vnetRouteAllEnabled and publicNetworkAccess) and in some cases do not have support for setting the Site properties. This change will affect both Logic Apps, Function Apps and Web Apps. Please let me/us know if there is anything we can do to help add support. We are pausing the roll out until TF can add support for the Site properties.

Are you able to share the Azure regions where this change has not been made yet? thank you!

We have disabled the change in all regions for now to ensure TF users will not be impacted. We are working with the team to find a way forward without impacting TF users. Let me know if you still see issues (region/site name).

[dkuzmenok]

@madsd Is the rollback complete?

I just ran Logic App creation and still get same error (that is a custom tenant):

Error: creating Logic App Standard: (Site Name "***" / Resource Group "***"): web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property." Details=[{"Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."},{"Code":"BadRequest"},{"ErrorEntity":{"Code":"BadRequest","ExtendedCode":"01020","Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property.","MessageTemplate":"There was a conflict. {0}","Parameters":["SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."]}}]

[madsd]

@madsd Is the rollback complete?

I just ran Logic App creation and still get same error (that is a custom tenant):

Error: creating Logic App Standard: (Site Name "***" / Resource Group "***"): web.AppsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property." Details=[{"Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."},{"Code":"BadRequest"},{"ErrorEntity":{"Code":"BadRequest","ExtendedCode":"01020","Message":"There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property.","MessageTemplate":"There was a conflict. {0}","Parameters":["SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property."]}}]

Should be - would you mind sending me the site name in an email and I'll have engineering look at the cause: madsd[at]microsoft.com

[suneerpm]

We started rolling out this change to ensure Azure policy compliance with specific network related settings (Improving App Service networking configuration control). We found that Terraform is primarily using the SiteConfig versions of the properties (vnetRouteAllEnabled and publicNetworkAccess) and in some cases do not have support for setting the Site properties. This change will affect both Logic Apps, Function Apps and Web Apps. Please let me/us know if there is anything we can do to help add support. We are pausing the roll out until TF can add support for the Site properties.

Are you able to share the Azure regions where this change has not been made yet? thank you!

We have disabled the change in all regions for now to ensure TF users will not be impacted. We are working with the team to find a way forward without impacting TF users. Let me know if you still see issues (region/site name).

We are still facing this issue. In my case, the Logic App is running in the ASE v3 - East US region. Is rollback paused for Logic App APIs too?

[cnnranderson]

RE Standard Logic Apps: Initial deploy with any configurations on app_settings and identity work, but any changes after the fact does not work. For example, if you disable a workflow, app_settings will be considered modified against terraform state (Workflow state set as a 'disabled' app_setting flag) so we have to lifecycle ignore those attributes for now.

[snehacloudops]

We started rolling out this change to ensure Azure policy compliance with specific network related settings (Improving App Service networking configuration control). We found that Terraform is primarily using the SiteConfig versions of the properties (vnetRouteAllEnabled and publicNetworkAccess) and in some cases do not have support for setting the Site properties. This change will affect both Logic Apps, Function Apps and Web Apps. Please let me/us know if there is anything we can do to help add support. We are pausing the roll out until TF can add support for the Site properties.

Hi, I tried to create std logic app today using the latest azurerm TF provider version (3.105.0) and it is still failing with the same error - "There was a conflict. SiteConfig.PublicNetworkAccess cannot be set by itself. Please use the Site.PublicNetworkAccess property"

[stephybun]

Thanks for this PR @pauldotknopf.

I've been looking into this for the logic app standard resource over in #27913. Based on the behaviour and the ramifications this has for Azure Policy compliance, we think the cleanest way to handle this is to deprecate the existing public_network_access_enabled property in the site_config block and to supersede it with a public_network_access property on the top level of the resource. This property will be responsible for toggling the behaviour both on the site properties level as well as in the site config and ensures that the resource can satisfy any Azure Policy requirements.

Could you let us know if this is something you would be willing to apply here? If so I can point you to some helpful guides that explain how deprecations and breaking changes can be done in the provider. It isn't an insignificant amount of work though so if you're not able to get to it we would close this PR and get someone in the team to take a look at doing this.

[pauldotknopf]

@stephybun my team found a workaround. I'm fine with closing this PR in favor of someone else's

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.