It would be nice if the auth/kubernetes/config path supported delete operation about vault-plugin-auth-kubernetes

[jefferai]

Doesn't this mean that the Terraform provider needs to be fixed? Or that something other than the generic secret provider should be used?

[rberlind]

No, I don't think so. Terraform needs to be able to destroy any resource it creates. So, when the vault_generic_secret resource is used to write to a particular path such as auth/kubernetes/config, it would need to be able to invoked the delete operation against that path. Even if the Kubernetes provider was extended with some specific resource for interacting with that path, that resource would still have to be able to delete the path it had created.

There might be good reasons for Vault not supporting the delete operation on the auth/kubernetes/config and similar paths for other auth backends. And changing might be challenging. I have no idea. But if it could easily be implemented in Vault, that would be nice.

If you think making the change is undesirable, then I can create a ticket for the Terraform Vault provider and you could close this one.

[jefferai]

Honestly, it feels like a strange change to make for one single backend for one single client. The client behavior should be fixed instead, which might mean not using vault_generic_secret (as this isn't a secret).

[rberlind]

I updated my last comment to say "Vault provider" instead of "Kubernetes provider". We're not just talking about some arbitrary provider, but the main integration point between Terraform and Vault. What I'm doing is actually provisioning an actual instance of a Vault auth backend and then configuring it with Terraform. Eventually when my k8s cluster is destroyed, the auth backend would also be destroyed.

While I talked in this issue about Terraform interacting with Vault to create an instance of one specific auth backend (kubernetes), the same problem would likely occur for any of our auth backends and mounts (which can be created with the Vault provider's vault_mount resource). For instance, I recently tried to see if I could provision an instance of the PKI secret backend and had the same problem with some of its configuration paths.

Fundamentally, I think it would be useful to support delete operations on all the configuration paths for all our auth and secret backends to make it easier for Terraform to interact with Vault. I suspect the change needs to be made in Vault rather than Terraform.

Note that the consequences of not being able to do terraform destroy after having provisioned an auth backend or a secrets backend mount are pretty severe. Customers then end up in a situation like I did where they can neither destroy their infrastructure (which could include many other things) with Terraform or even remove the Vault resources from their Terraform code.