feature: support kubernetes proxy verb

[M0NsTeRRR]

✨ Describe the feature you'd like

It would be cool to have the possibility to pass a kubeconfig and use kubernetes proxy verb. It will allow to unseal a kubernetes vault HA cluster from non kubernetes nodes.

🌧 Is your feature request related to a problem?

If you want to run an HA vault cluster exposed only in the cluster.

🔎 Describe alternatives you've considered

• Exposing each pod with an ingress (I don't like the idea to expose something that is not needed).
• Install vault-unseal in the cluster, I don't like the idea to run this software in the same cluster as my vault cluster. For example a compromise node (with a SSH key) can result in discovering vault unseal keys and secret in one time.

⚠ If implemented, do you think this feature will be a breaking change to users?

No

⚙ Additional context

No response

🤝 Requirements

• [X] I have confirmed that someone else has not submitted a similar feature request.
• [X] If implemented, I believe this feature will help others, in addition to solving my problems.
• [X] I have looked into alternative solutions to the best of my ability.
• [X] (optional) I would be willing to contribute to testing this feature if implemented, or making a PR to implement this functionality.

[lrstanley]

I appreciate the contribution, however, I think this is a rather niche scenario that I don't think is worth the maintenance and testing overhead. I work quite a bit in Kubernetes, including using vault-unseal, and other kms-based sealing methods, and I've never needed this specific scenario.

For simplicity, I'd recommend unsealing in-cluster using a sidecar or separate deployment, or using KMS based solutions. If you have concerns with security, the first thing to not do would be to run all vault instances in the same cluster. Vault-unseal's unsealing method shouldn't be used unless you isolate your vault instances in separate clusters (including separate deployments of vault-unseal). If they share the same control plane, you are already risking quite a bit by having the potential for shared credentials, shared ingress, shared authentication/OIDC/etc.

If all vault instances are on a shared cluster, and a node is compromised, and you use the same central ingress entrypoint, you can still leak your tokens by an attacker man-in-the-middling that ingress traffic (thus the requests from vault-unseal to the vault cluster), using PROXY verb or not.

[M0NsTeRRR]

Hello,

Thanks for your detailed answer. I know about the security issues; it's for a homelab purpose :). The idea behind this (if you don't have a KMS) is to keep your Vault unseal credentials in a separate zone from the Kubernetes one. It doesn't solve every case I agree, but it adds a layer in my case. I understand the concern about the niche scenario, so I'll keep it in my fork.

Regards,