You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
In the current version of the AzureRM provider (3.34.0), running terraform apply with a plan that includes new azurerm_app_configuration resources will check for soft deleted App Configuration stores, which requires the subscription-level permission Microsoft.AppConfiguration/locations/deletedConfigurationStores/read. Without that permission, apply errors out from the API response's 403 status code.
azurerm_app_configuration.default: Creating...
│ Error: checking for presence of deleted Deleted Configuration Store (Subscription: "redacted"
│ Location: "westus"
│ Config Store Name: "redacted"): deletedconfigurationstores.DeletedConfigurationStoresClient#ConfigurationStoresGetDeleted: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'redacted' with object id 'redacted' does not have authorization to perform action 'Microsoft.AppConfiguration/locations/deletedConfigurationStores/read' over scope '/subscriptions/redacted/providers/Microsoft.AppConfiguration/locations/westus/deletedConfigurationStores/redacted' or the scope is invalid. If access was recently granted, please refresh your credentials."
We are unable to create custom Azure roles in our tenant (so we can't add the App Configuration purge permissions to our service principals), and we do not want to give our environment-specific service principals the Owner or Contributor roles on the whole subscription. It would be helpful if there was a way to disable the check for soft-deleted App Configuration resources when applying a plan that includes a new one.
New or Affected Resource(s)/Data Source(s)
azurerm_app_configuration
Potential Terraform Configuration
# Ideally, this already-possible configuration would skip the check for soft deleted App Configuration resources.terraform {
required_providers {
azurerm={
source ="hashicorp/azurerm"
version ="3.34.0"
}
}
}
provider"azurerm" {
features {
app_configuration {
recover_soft_deleted=false
}
}
}
resource"azurerm_app_configuration""default" {
name="my-app-config"location="westus"resource_group_name="my-rg"sku="standard"purge_protection_enabled=false
}
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Is there an existing issue for this?
Community Note
Description
In the current version of the AzureRM provider (3.34.0), running
terraform apply
with a plan that includes new azurerm_app_configuration resources will check for soft deleted App Configuration stores, which requires the subscription-level permissionMicrosoft.AppConfiguration/locations/deletedConfigurationStores/read
. Without that permission, apply errors out from the API response's 403 status code.We are unable to create custom Azure roles in our tenant (so we can't add the App Configuration purge permissions to our service principals), and we do not want to give our environment-specific service principals the Owner or Contributor roles on the whole subscription. It would be helpful if there was a way to disable the check for soft-deleted App Configuration resources when applying a plan that includes a new one.
New or Affected Resource(s)/Data Source(s)
azurerm_app_configuration
Potential Terraform Configuration
References
#18827
The text was updated successfully, but these errors were encountered: