Add Secret Injection Middleware proposal #2357
Draft
+514
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Many backend services use static authentication (API keys, tokens) instead of OAuth/OIDC. Our token exchange middleware works great for OAuth-compatible backends, but we can't handle scenarios where users need their own individual credentials.
Right now,
pkg/secretsresolves secrets once at workload startup and injects them as environment variables. This means secrets are shared across all users - there's no way to isolate credentials per user or track which user accessed what.Use Cases
Per-User Algolia Admin Keys
When multiple developers manage Algolia search indices through an MCP server, all modifications currently appear to come from one shared account. There's no way to audit who made which changes or enforce individual permissions.
With secret injection, each user's admin key is stored in Vault under their identity. When Alice modifies an index, the middleware authenticates to Vault as Alice and retrieves her specific key. Now we get proper attribution and a complete audit trail.
Multi-Tenant SaaS
Running a single MCP server for multiple customers breaks down when you need tenant-specific credentials. One shared API key for Jira or Salesforce means all tenant data gets accessed through a single account - no isolation.
The solution is storing each tenant's API key in Vault (like
secret/tenants/acme-corp/jira-api-key). The user's JWT contains their tenant claim, and the middleware fetches the right credential for that tenant.Centralized Secret Management
Static secrets in environment variables don't meet enterprise security requirements. Security teams want centralized policies, rotation, and audit logs.
This middleware lets us store API keys only in Vault with proper access controls. The proxy fetches them dynamically, and every access is logged with the user's identity.
How It Works
The middleware sits in the proxy chain after token exchange:
In Phase 1, we support static paths. Phase 2 adds Go templating so paths can include user claims like
secret/users/{{.email}}/api-key.Design Decisions
We're using a generic
SecretFetcherinterface with Vault as the first implementation. This keeps the door open for AWS Secrets Manager or Azure Key Vault later.The Vault integration uses JWT authentication so each user's identity flows through to secret access. We're implementing the Vault client with direct HTTP calls instead of importing their SDK to avoid BSL 1.1 licensing issues.
Two-phase delivery: static paths first to prove the pattern, then templating for per-user isolation. This gets us something useful quickly while reducing risk.
This is complementary to
pkg/secrets, not a replacement. Usepkg/secretsfor shared startup credentials like database URLs. Use secret injection for per-user request-time credentials like personal API keys.What's In The Proposal
pkg/secretsRefs: THV-2063 (token exchange middleware)