hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.6k stars 4.64k forks source link

azurerm_sql_server tries to write extendedAuditingPolicy even if not defined. #9875

Open sharebear opened 3 years ago

sharebear commented 3 years ago

Community Note

Terraform (and AzureRM Provider) Version

Terraform v0.14.0
+ provider registry.terraform.io/hashicorp/azurerm v2.38.0

(I'll be upgrading tomorrow ;) )

Affected Resource(s)

Terraform Configuration Files

resource "azurerm_sql_server" "main" {
  name                = "redacted-sql"
  location            = var.location
  resource_group_name = var.resource_group_name

  version = "12.0"

  connection_policy = "Proxy"

  administrator_login          = "redacred"
  administrator_login_password = random_password.db_administrator_password.result

  identity {
    type = "SystemAssigned"
  }

  tags = var.tags
}

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

Error: Error issuing create/update request for SQL Server "<redacted>" Blob Auditing Policies(Resource Group "<redacted>"): sql.ExtendedServerBlobAuditingPoliciesClient#CreateOrUpdate: Failure sending request: StatusCode=403 -- Original Error: Code="AuthorizationFailed" Message="The client '<redacted>' with object id '<redacted>' does not have authorization to perform action 'Microsoft.Sql/servers/extendedAuditingSettings/write' over scope '/subscriptions/<redacted>/resourceGroups/<redacted>/providers/Microsoft.Sql/servers/<redacted>/extendedAuditingSettings/default' or the scope is invalid. If access was recently granted, please refresh your credentials."

Steps to Reproduce

  1. 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 the SQL Server Contributor role has Microsoft.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

yupwei68 commented 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.

philspokas commented 3 years ago

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?

yupwei68 commented 3 years ago

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/*.

philspokas commented 3 years ago

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!