azurerm_static_webapp - Mark app_settings sensitive in schema

[arnoldrw]

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 comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

This pr updates app_settings in static_webapp_resource to be a sensitive field.

Official Microsoft setup documentation related to setting up authentication for a static webapp indicate that setting an EntraID app registration client secret as an app setting is an expected configuration. Currently with app_settings not marked as a sensitive field, this results in the actual secret value being displayed.

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.

• static_webapp_resource - Make app_settings sensitive

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

[bubbletroubles]

Isn't the fix here to store the secret in a keyvault, then reference the keyvault from the app settings? See https://learn.microsoft.com/en-us/azure/static-web-apps/key-vault-secrets

[arnoldrw]

Isn't the fix here to store the secret in a keyvault, then reference the keyvault from the app settings? See https://learn.microsoft.com/en-us/azure/static-web-apps/key-vault-secrets

Keyvault integration is certainly one answer but I do not believe it can/should be the only answer for a few reasons eg:

• https://learn.microsoft.com/en-us/azure/static-web-apps/key-vault-secrets mentions that Keyvault Integration is not available for static webapps using managed functions.
• Other official documentation from Microsoft give storing secrets for authentication configuration as an example of the use of application settings.
• Key vault integration requires usage of system assigned identities and the use of those may be restricted by different organizations.

In the current state of the provider, the only option to hide these secrets is to use a key vault integration. This forces developers down a single path, when there are multiple available. The provider should be unopinionated on something that comes down to a choice by the developer. In the current state, if a developer wants to treat app_settings as sensitive they have no ability to do so as their resource cannot override the provider output. On the flip side if this change is made and a developer wants to see the values of app_settings when it is marked as sensitive they have that option available to them.

[jackofallops]

Thanks @arnoldrw - LGTM 👍

[feichler-or]

@arnoldrw you mentioned

On the flip side if this change is made and a developer wants to see the values of app_settings when it is marked as sensitive they have that option available to them.

How would I exactly do that? When I just set app_settings = nonsensitive(...) the terraform plan output still shows

~ app_settings = (sensitive value)

instead of previously (up to version 4.25)

 ~ app_settings = {
          + "Some:Connection"                                = (sensitive value)
          + "Some:Name"                                      = "name"
          + "Some:Value"                                     = "200"
            # (21 unchanged elements hidden)
        }

[dantape]

@jackofallops I think you need to seriously consider reverting this PR and @arnoldrw I think you made the changes on the wrong resource.

The title of the PR indicates that these changes were meant for the azurerm_static_webapp resource. However, upon further investigation, the changes appear to have been made to the azurerm_windows_function_app resource.

What was actually intended here? I believe this change is hiding all of our app_settings on windows function apps. With all the options available with Key Vault and App Config Service there is no reason to ever store sensitive values in the app_settings for a windows function app.

[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.