Does the vault provider support /v1/sys/config/auditing?

I’m interested in trying to move our Vault configuration to the Vault Terraform provider. However, I can’t find a likely resource to represent /v1/sys/config/auditing/request-headers. It doesn’t appear to be part of the vault_audit resource. Is there a resource representing this config option?

It is not supported, no, as I found out when trying to do this too.

However, a mostly acceptable kludge can be achieved using the vault_generic_endpoint resource - although because this API perplexingly returns a different shape of JSON on read, compared to how it is written, ignore_absent_fields is needed, meaning you sacrifice correct drift detection.

Do you have a working example? I tried this:

resource "vault_generic_endpoint" "audit_headers" {
  for_each = toset(["X-Forwarded-For", "X-Audit"])

  data_json = jsonencode({ hmac = false })
  path      = "sys/config/auditing/request-headers/${each.key}"

  ignore_absent_fields = true
}

But I get an error when the header doesn’t already exist:

╷
│ Error: error reading sys/config/auditing/request-headers/X-Audit from Vault: Error making API request.
│
│ URL: GET https://127.0.0.1:40301/v1/sys/config/auditing/request-headers/X-Audit
│ Code: 400. Errors:
│
│ * Could not find header in config
│
│   with vault_generic_endpoint.audit_headers["X-Audit"],
│   on audit.tf line 12, in resource "vault_generic_endpoint" "audit_headers":
│   12: resource "vault_generic_endpoint" "audit_headers" {
│
╵

Even adding disable_read = true doesn’t seem to fix this for some reason.

This seems to happen if the resource is removed outside of Terraform, but then still exists in the Terraform state, so that plan can’t read the resource to plan the change that sets disable_read.

If the resource is created with disable_read, then Terraform won’t recreate it at all if it’s deleted outside of Terraform.

With only disable_read and not ignore_absent_fields, there’s no error, but still the same behavior of Terraform not noticing at all if it’s deleted from outside Terraform. (Why doesn’t it write every time if it knows the endpoint only supports write? That’s the only way it can ensure the resource actually exists!)

This workaround is not really acceptable. I’ll have to keep managing these from outside of Terraform.

Oh, you’re right, I wrote my previous message at the weekend, relying on memory, but now I look at the config we ended up with at work, we did settle on using disable_read instead.

It’s not a great workaround, I agree.

Thanks for the help. I can add this to the provider in my free time eventually, but I don’t have time to do it on the job right now.