Terraform-provider-azurerm: The `password`-attribute of `site_credential` gets exposed when executing `terraform destroy`.

[baosen]

Community Note

• 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

Terraform (and AzureRM Provider) Version

Terraform v0.12.2
AzureRM Provider v1.30.1 (did not happen on v1.25)

Affected Resource(s)

• azurerm_app_service

Terraform Configuration Files

resource "azurerm_resource_group" "group" {
  name     = "test-sdfqwerty"
  location = "westeurope"
}

resource "azurerm_app_service_plan" "plan" {
  name                = "${azurerm_resource_group.group.name}"
  location            = "${azurerm_resource_group.group.location}"
  resource_group_name = "${azurerm_resource_group.group.name}"

  kind     = "Linux"
  reserved = true

  sku {
    tier = "PremiumV2"
    size = "P1v2"
  }
}

resource "azurerm_app_service" "app" {
  name                = "${azurerm_resource_group.group.name}"
  location            = "${azurerm_resource_group.group.location}"
  resource_group_name = "${azurerm_resource_group.group.name}"

  app_service_plan_id     = "${azurerm_app_service_plan.plan.id}"
  https_only              = "true"
  client_affinity_enabled = "false"

  site_config {
    ftps_state       = "Disabled"
    always_on        = "true"
    linux_fx_version = "PYTHON|3.7"
  }

  identity {
    type = "SystemAssigned"
  }
}

Expected Behavior

Do not print out the password-attribute of site_credential. Should say (sensitive value).

Actual Behavior

The password-attribute of site_credential gets printed out. Does not say (sensitive value).

Steps to Reproduce

1. terraform apply -auto-approve
2. terraform destroy

[baosen]

Hi! Does anyone know what caused this?

[tombuildsstuff]

hi @baosen

Thanks for opening this issue.

Taking a look at the code all the instances of this appear to be a Sensitive value - as such I'm wondering if you can upgrade the version of Terraform Core being used here and confirm if this still happens for you?

Thanks!

[baosen]

Upgrading Terraform Core means using the latest Terraform binary? :S. I've tried using the latest 64-bit Linux Terraform binary now, which when I run ./terraform version, it prints out:

Terraform v0.12.6

• provider.azurerm v1.32.1

and then deployed and destroyed the same config as mentioned in the first post. The output is still the same, where the password leaks :(. See attachment.

(don't worry about the pass being open to the public in this screenshot, i've destroyed the test resources :) )

[aczelandi]

@baosen @tombuildsstuff we also see the same behavior but when running terraform plan.
We are on latest terraform version and latest azurerm provider version.

[PSanetra]

This is still happening with Terraform 0.12.9 and azurerm 1.35.0

[brennerm]

This issue comes from a bug in the Terraform Plugin SDK. For this reason it is currently not possible to mask parts of nested blocks. One option would be to mark the whole site_credential block as sensitive. But to me this sounds like a workaround for the actual problem.

[ayusmadi]

Quick workaround is to omit kube_config sensitive information using egrep:

terraform plan | egrep -v 'password|other_sensitive_attribute'

[tombuildsstuff]

👋

Since this issue needs to be fixed in the Terraform Plugin SDK rather than tracking this issue in multiple places I'm going to close this issue in favour of the upstream issue. Once that's been fixed we'll update the version of the Plugin SDK being used and this should get resolved - as such please subscribe to the upstream issue for updates.

Thanks!

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!