New Resource: azurerm_key_vault_secret

[tombuildsstuff]

Adds the azurerm_key_vault_secret resource - with support for setting secrets at particular versions.

Note this doesn't implement the Enabled, Activation Date or Expiration Date fields due to us being unable to make API calls for a disabled secret (due to the way the API's designed.

Tests pass:

$ TF_ACC=1 envchain azurerm go test ./azurerm -v -timeout 120m -run TestAccAzureRMKeyVaultSec
=== RUN   TestAccAzureRMKeyVaultSecret_importBasic
--- PASS: TestAccAzureRMKeyVaultSecret_importBasic (75.62s)
=== RUN   TestAccAzureRMKeyVaultSecret_importComplete
--- PASS: TestAccAzureRMKeyVaultSecret_importComplete (84.79s)
=== RUN   TestAccAzureRMKeyVaultSecret_basic
--- PASS: TestAccAzureRMKeyVaultSecret_basic (80.49s)
=== RUN   TestAccAzureRMKeyVaultSecret_complete
--- PASS: TestAccAzureRMKeyVaultSecret_complete (82.81s)
=== RUN   TestAccAzureRMKeyVaultSecret_update
--- PASS: TestAccAzureRMKeyVaultSecret_update (98.13s)
PASS
ok  	github.com/terraform-providers/terraform-provider-azurerm/azurerm	421.867s

$ TF_ACC=1 envchain azurerm go test ./azurerm -v -timeout 120m -run TestAccAzureRMKeyVaultSecret_validateName
=== RUN   TestAccAzureRMKeyVaultSecret_validateName
--- PASS: TestAccAzureRMKeyVaultSecret_validateName (0.00s)
PASS
ok  	github.com/terraform-providers/terraform-provider-azurerm/azurerm	0.017s

$ TF_ACC=1 envchain azurerm go test ./azurerm -v -timeout 120m -run TestAccAzureRMKeyVaultSecret_parseID
=== RUN   TestAccAzureRMKeyVaultSecret_parseID
--- PASS: TestAccAzureRMKeyVaultSecret_parseID (0.00s)
PASS
ok  	github.com/terraform-providers/terraform-provider-azurerm/azurerm	0.018s

[grubernaut]

LGTM, couple of potential panics that should be caught, but otherwise looks good.

[grubernaut]

If tags is optional, this cast will panic on a nil "tags" block:

tags { }

With the complex types here, easier to try the cast to verify against potential panics.

[grubernaut]

& repeated other areas 😄

[tombuildsstuff]

I'd agree, but afaik HCL is returning an empty map here - given we use this pattern throughout the provider - example from azurerm_resource_group:

$ cat main.tf
resource "azurerm_resource_group" "test"{
  name = "tom"
  location = "westus"
  tags { }
}

$ envchain azurerm terraform plan -refresh
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

  + azurerm_resource_group.test
      location: "westus"
      name:     "tom"
      tags.%:   "<computed>"


Plan: 1 to add, 0 to change, 0 to destroy.
✔ ~/code/src/tmp/jake
17:01 $ envchain azurerm terraform apply
azurerm_resource_group.test: Creating...
  location: "" => "westus"
  name:     "" => "tom"
  tags.%:   "" => "<computed>"
azurerm_resource_group.test: Creation complete (ID: /subscriptions/xxxxxxxxxx/resourceGroups/tom)

[grubernaut]

complex types should always check the returned error from d.Set(), more opportunities for things to go wrong

[tombuildsstuff]

given this affects every resource in the Provider - I'm going to make this a separate task & do this across everything

[ghost]

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!