Feature: Support write-only / direct push to Vault/OpenBao for ESO secrets without storing plaintext in PostgreSQL #7062

🔖 Feature description

We want to see if we can improve how Devtron handles HashiCorp Vault / OpenBao secrets via External Secrets Operator (ESO).

Right now, if we use Vault with ESO, Devtron works in read-only mode (just mapping YAML). If we use native Devtron secrets, the values end up sitting in PostgreSQL.

The idea is simple:

1. Direct push to Vault/OpenBao: Allow Devtron to push secret key-values straight to Vault/OpenBao KV store (ideally write-only, so Devtron doesn't even need read access).
2. Safe storage in PostgreSQL: Keep Postgres completely clean of plaintext or reversible Base64. Instead, store only a masked preview (like sk_****abcd) or a version tag.
3. Instant redeploy: When a secret updates, pin the version in the ESO manifest so the rollout triggers immediately—no waiting around for background timer polling.

🎤 Pitch / Usecases

What’s the pain point?

Currently, while setting up Vault/OpenBao with ESO in Devtron:

• Too much context switching: To update a credential, developers/admins have to jump out of Devtron, open Vault, update the secret, copy paths, come back to Devtron, and update YAML manually. It breaks the flow.
• Delayed rollouts: Since updates depend on ESO’s polling interval (refreshInterval), redeployments don’t happen immediately, and more importantly, they happen outside Devtron's deployment history and audit trail.
• Compliance headache with native secrets: Using native Devtron secrets gives a great 1-click redeploy experience, but security/compliance audits flag credentials sitting in Postgres (even as Base64). External vaults are mandatory for us.

Why I'm proposing this

I am actively setting up this pipeline for our own platform workloads right now. We hit this exact blocker where we need immediate, zero-polling redeployments and strict compliance without leaking credentials into PostgreSQL.

Instead of hacking together a private sidecar or custom script just for my team, I felt this is a genuine friction point that almost anyone using Devtron with Vault/OpenBao in production must be facing. If we bake this into Devtron cleanly, it becomes a win for everyone.

Open to ideas on the architecture

I don't want to enforce a rigid implementation—I'd love the core team's input on what fits Devtron's architecture best:

• Should this be an extra mode/toggle under the existing ESO_HashiCorpVault provider, or a separate type altogether?
• On save, an interceptor/hook pushes the values to Vault KV v2 and leaves only masked strings/metadata in secret_data.
• On deploy, the generated ESO manifest pins the updated version, triggering an instant K8s rollout.

Happy to build and contribute

Since this is an active requirement for me, I am more than happy to invest the time to write the Go backend logic, add tests, and update docs.

Would love to hear your thoughts and get your guidance on the right approach before I raise a PR!

🔄️ Alternative

1. Manual Vault UI + ESO polling: What we have today. Works, but involves jumping across multiple tools, delayed rollouts, and missing deploy-history records.
2. Native Devtron Secrets: Great developer experience, but storing sensitive credentials in the application database doesn't pass security audits.
3. Custom external webhooks/sidecars: Felt too hacky and brittle to maintain across Devtron upgrades when it could just be handled natively.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct