Terraform-provider-azuredevops: azuredevops_variable_group crashes on import

[A30004028]

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 Azure DevOps Provider) Version

• Terraform v0.12.26
• provider.azuredevops v0.0.1

Affected Resource(s)

• azuredevops_variable_group

Terraform Configuration Files

data "azuredevops_project" "project" {
  project_name = "AAA"
}

resource "azuredevops_variable_group" "main" {
  project_id   = data.azuredevops_project.project.id
  name         = "terraform-enterprise-test"
  description = "test"
  allow_access = true
  variable {
      name         = "terraform-team-token"
      secret_value        = "test"
      is_secret    = true
  }
}

Debug Output

https://gist.github.com/A30004028/211299a02a409303cdad651145173019

Panic Output

https://gist.github.com/A30004028/211299a02a409303cdad651145173019

Expected Behavior

Resource is imported succesfully as per https://www.terraform.io/docs/providers/azuredevops/r/variable_group.html#import

Actual Behavior

Resource import crashes

Steps to Reproduce

1. Ensure an Azure Devops variable group exists in Azure DevOps with at least one variable, I used a sensitive value but it does not appear to affect the result.
2. Use terraform to import the variable group with the following, replacing the variable group ID with your own.
   terraform import azuredevops_variable_group.main "AAA"/846

Important Factoids

References

• #0000

[xuzhang3]

Hi @A30004028 Thanks for your feedback. This is because you have secret values in your configuration, service won't return secret values. We fix this to support secret values improt ,but you will lost the secret values.

[A30004028]

Thats fine, the secrets are maintained elsewhere in code. Am I right in thinking the values will get reapplied on the next plan/apply?

[xuzhang3]

yes, you are correct.

[DamonStamper]

So how would you import a variable group with secrets? Create an additional group and confirm that your IaC is able to recreate the original group then do a cutover to remove the original group and create it with TF? Would it be better to throw a warning that you weren't able to import the secrets?

Also on a tangental topic, if TF isn't able to see secret data then how is TF able to determine if the secret changes and therefore update it? Is it possible to get anything out of MS like a one-way hash that could be used to determine changes?

[xuzhang3]

@A30004028 @DamonStamper Sorry I misunderstand you at first. Currently, ADO provider doesn't support import secret values and we cannot do that because service won't return this secret values.
Terraform check if values have been changed based on .tfstate and .tf configuration.

[A30004028]

Ok, I'm lost here again.

Will an tf import call, import the variable group AND the variable names of sensitive variables (but not the value)?

If so, will the the next plan/apply attempt to update the values of the sensitive variables due to an inconsistency between the .tfstate and .tf configuration?

[xuzhang3]

@A30004028 You point it good, we can investigate if we can import only names then apply again to get this values back into .tfstate.

[petenorth]

I have a large number of variable groups containing a mixture of sensitive and non-sensitive config. The sensitive variables are marked as secrets (i.e. in Azure DevOps they appear as ** ).

The presence of a secret in a variable group seems to result in the import failure

'Error: rpc error: code = Unavailable desc = transport is closing'

As soon as I remove the sensitive value the import succeeds.

The behaviour that I was hoping to see was that the variable group would be imported but that the state would have blank values for the secrets. Or that the variables would be missing entirely from the state. Or that the values for secrets would be some shouty text.

I would then apply a subsequent plan that is able to set these secrets (from outputs of other resources or modules).