Comments (4)
Doesn't this mean that the Terraform provider needs to be fixed? Or that something other than the generic secret provider should be used?
from vault-plugin-auth-kubernetes.
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.
from vault-plugin-auth-kubernetes.
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).
from vault-plugin-auth-kubernetes.
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.
from vault-plugin-auth-kubernetes.
Related Issues (20)
- Vault should support reloading service account token from disk HOT 7
- Make issuer validation work with Kubernetes 1.21+ by default HOT 6
- Rename disable_iss_validation HOT 1
- Re-configuring role fails after upgrading existing deployment to Vault 1.9.x HOT 4
- Authentication backend defined token_type is not override by role token_type HOT 1
- Allow specifying a namespace selector for the allowed namespace from which to authenticate
- BREAKING CHANGE: proposal: make `kubernetes_host` array to provide fallback mechanism and retry resiliency
- JWT signing algorithm ES384 became unsupported since version 0.13.0 HOT 1
- [docs] allow patching of roles HOT 14
- Unable to authenticate to external k8s cluster HOT 3
- Kubernetes API errors are not logged as errors HOT 5
- TLS errors after failed plugin initialization HOT 3
- CA cert on local disk is not reloaded if changed
- The audience claim is not checked, the parameter `audience` in the Kubernetes auth role is ineffective HOT 4
- Context Canceled on all authentication attempts for 10 minutes after an API node has shutdown HOT 14
- Unable to make Kubernetes requests: no such host HOT 1
- GitHub Actions - deprecated warnings found - action required!
- Support for path nesting like kv2 engine when nesting multiple kubernetes clusters configs in same path
- Add token_reviewer_jwt as login parameter
- Consider token lookup event configurable HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vault-plugin-auth-kubernetes.