bug: Why does vault_kv_secret_v2 need metadata access? First apply fails, second works

[Nivedita-coder]

Hi folks,
I'm using terraform with Vault KV v2 to manage secrets. When I try to update a secret for the first time, I get the following error:

vault_kv_secret_v2.user: Modifying... [id=xxxx/data/]
╷
│ Error: error writing custom metadata to xxxx/metadata/xxxx, err=Error making API request.
│ 
│ URL: PUT v1/xxxx/metadata/xxxx
│ Code: 403. Errors:
│ 
│ * 1 error occurred:
│       * permission denied
│ 
│ 
│   with vault_kv_secret_v2.user,
│   on main.tf line 49, in resource "vault_kv_secret_v2" "user":
│   49: resource "vault_kv_secret_v2" "user" {

Interestingly, if I try the same operation a second time, it succeeds.Why does vault_kv_secret_v2 require access to the metadata/... path even if I’m only updating a secret under data/...?

[heatherezell]

Hi there! Can you provide more information about your setup? (In the bug report template, there are commands that help us identify your version, etc.) Also, do you have any log information that you can pass along? Thanks!

[Nivedita-coder]

HI @heatherezell.
I'm using 5.3.0 version of terraform provider.

And, i'm encountering this issue like when I'm applying the changes terraform apply -var="role_id=" -var="secret_id=" -var="new_username=" -var="new_password="

Also, i guess the issue coming form here: https://github.com/hashicorp/terraform-provider-vault/blob/65368d23d04ae03cd9d25130c71f89dad33c5d33/vault/resource_kv_secret_v2.go#L250-L259

[Nivedita-coder]

Some users have encountered a similar issue in the past, but there hasn’t been any comment from the community here: hashicorp/terraform-provider-vault#1885

I would really appreciate any references or explanations to help me understand why an update scope is required on the metadata path, especially since we are using the KV v2 secrets engine.

Additionally, I’d like to understand whether it is safe to grant update or create permissions on the metadata path in the policy. From what I know, metadata contains system information, and so far policies have typically only included read, list, and delete on metadata.

I’m seeking clarification from the Vault community on how granting access to the metadata path can be done safely, and how to avoid this error message.

[heatherezell]

Thanks! I appreciate that extra information. I'll see what we can find out for you.