Open sharebear opened 3 years ago
Hi @sharebear , thanks for opening this issue. We'll set disable
to extended Auditing Policy
when there is no definition of the block extended_auditing_policy
. That's out of design when you try to remove the block extended_auditing_policy
, it need to disable the extended auditing policy
.
We might discuss if the SQL Server Contributor
role problem with the service team.
Is there a workaround for this issue? There does not appear to be a way to disable extended_auditing_policy in the Terraform. And, as soon as the extended_auditing_policy is specified, all values in the block are required, not optional as the documentation says.
Is it known what provider version this bug was introduced in? I can possibly downlevel the provider version.
@yupwei68 any updates on this?
Hi @philspokas, you can disable extended_audting_policy
by removing the corresponding block in mssql_server as long as you have permission to the action Microsoft.Sql/servers/extendedAuditingSettings/*
.
Hi @yupwei68: exactly. Ideally, if one is not touching extended_auditing_policy, one should not need the corresponding action. Agreed, that's the workaround. Thanks!
Community Note
Terraform (and AzureRM Provider) Version
(I'll be upgrading tomorrow ;) )
Affected Resource(s)
azurerm_sql_server
Terraform Configuration Files
Debug Output
Panic Output
Expected Behaviour
When terraform is run as a user with SQL Contributor role (or similar built-in role) database should be created.
Actual Behaviour
Steps to Reproduce
terraform apply
Important Factoids
I'm attempting to run terraform via GitHub action without giving my custom runner Contributor access to the whole subscription. My strategy so far was to try using the " Contributor" roles assigned to the subscription scope (I create the resource groups with terraform so assigning the roles any lower than that creates a chicken-and-egg problem).
My latest problem with this strategy was in creating an SQL Server... my config does not set the
extended_auditing_policy
yet terraform attempts to write to it, which is problematic as theSQL Server Contributor
role hasMicrosoft.Sql/servers/extendedAuditingSettings/*
listed as a NotAction.I guess this could be somewhat philosophical, when a setting is not configured in the hcl should the provider set a built-in default or should it leave the value untouched for the AzureRM APIs to decide the default? If the former is intended then I need to create a custom role, if the latter is intended the behaviour I'm seeing is a bug.
References