Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

azurerm_communication_service shows sensitive data #26548

Closed
1 task done
MariiaDzhenkova opened this issue Jul 5, 2024 · 1 comment 路 Fixed by #26560
Closed
1 task done

azurerm_communication_service shows sensitive data #26548

MariiaDzhenkova opened this issue Jul 5, 2024 · 1 comment 路 Fixed by #26560

Comments

@MariiaDzhenkova
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.9.1

AzureRM Provider Version

3.111.0

Affected Resource(s)/Data Source(s)

azurerm_communication_service

Terraform Configuration Files

resource "azurerm_resource_group" "acs-rg" {
  name     = "rg-acs"
  location = "North Europe"
  lifecycle {
    ignore_changes = [
      tags["created"],
    ]
  }
}

resource "azurerm_communication_service" "acs" {
  name                = "comm"
  resource_group_name = azurerm_resource_group.acs-rg.name
  data_location       = "Europe"
}

Debug Output/Panic Output

Terraform will perform the following actions:

  # azurerm_communication_service.acs is tainted, so must be replaced
-/+ resource "azurerm_communication_service" "acs" {
      ~ id                          = "/subscriptions/***/resourceGroups/<rg>/providers/Microsoft.Communication/communicationServices/<comm_service>" -> (known after apply)
        name                        = "<comm_service>"
      ~ primary_connection_string   = "endpoint=https://<comm_service>.europe.communication.azure.com/;accesskey=LyCpcTrjBJl" -> (known after apply)
      ~ primary_key                 = "AsKMyrpsdfoRnViXBOAB3BJl" -> (known after apply)
      ~ secondary_connection_string = "endpoint=https://<comm_service>.europe.communication.azure.com/;accesskey=FlIcA1KUBaM" -> (known after apply)
      ~ secondary_key               = "BaMqkHACg2dssefsdAAAAZCSEX4x" -> (known after apply)
        # (2 unchanged attributes hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Expected Behaviour

We expect primary_connection_string, primary_key, secondary_connection_string, secondary_key to be hidden in azurerm_communication_service.

Expected log:

Terraform will perform the following actions:

  # azurerm_communication_service.acs is tainted, so must be replaced
-/+ resource "azurerm_communication_service" "acs" {
      ~ id                          = "/subscriptions/***/resourceGroups/<rg>/providers/Microsoft.Communication/communicationServices/<comm_service>" -> (known after apply)
        name                        = "<comm_service>"
      ~ primary_connection_string   = "******" -> (known after apply)
      ~ primary_key                 = "******" -> (known after apply)
      ~ secondary_connection_string = "******" -> (known after apply)
      ~ secondary_key               = "******" -> (known after apply)
        # (2 unchanged attributes hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Actual Behaviour

Azurerm_communication_service resource displays sensitive data that is hidden in azure portal:

  • primary_connection_string
  • primary_key
  • secondary_connection_string
  • secondary_key

Steps to Reproduce

terraform plan -destroy
terraform destroy

or

terraform apply

Important Factoids

No response

References

No response

@lonegunmanb
Copy link
Contributor

Thanks @MariiaDzhenkova for opening this issue to us, I agree with you, these fields should be considered as sensitive. I'll try to make a pr for this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants