Notifications
Clear all
Topic starter
20/08/2026 5:36 pm
TL;DR: Running MCP servers in Kubernetes creates a familiar identity and secrets problem: hardcoded credentials and direct mounts expand exposure, while controlled vault access can narrow the blast radius, according to Stacklok. The real challenge is not secret storage alone, but governing how MCP workloads authenticate, retrieve, and limit secrets across runtime environments.
NHIMG editorial — based on content published by Stacklok: Securing MCP secrets with Vault + ToolHive in Kubernetes
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP workloads increase secrets governance risk in Kubernetes?
A: MCP workloads can touch many tools and data sources, which increases the number of credentials they need.
Q: What breaks when secrets are stored in MCP configuration files?
A: A single exposed config can turn a helper process into a durable access path.
Practitioner guidance
- Define MCP workloads as governed non-human identities Assign each MCP server a distinct workload identity, then map secret access to that identity rather than to cluster-wide convenience.
- Remove hardcoded and directly mounted secrets Eliminate secret values from manifests, images, and shared configuration paths.
- Scope Vault policies to function and environment Create policies that bind each secret to a specific workload, namespace, and purpose.
What's in the full article
Stacklok's full integration guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Vault and ToolHive integration guidance for Kubernetes-based MCP servers.
- Configuration details for controlled secret access patterns that avoid hardcoded credentials.
- Video demo material that shows the integration workflow in practice.
- Implementation context for teams that are already standardising MCP runtime access.
👉 Read Stacklok's integration guide for securing MCP secrets with Vault and ToolHive →
MCP secrets in Kubernetes: what governance gap teams are missing?
Explore further
20/08/2026 6:22 pm
MCP servers in Kubernetes should be treated as non-human identities, not just applications. Once a server can request secrets to reach tools and data, it becomes part of the identity governance surface. That means lifecycle, authentication, and privilege boundaries matter just as much as pod scheduling or service configuration. Teams that ignore the identity dimension will keep solving deployment mechanics while leaving secret exposure unchanged.
A question worth separating out:
Q: What is the difference between vault-based secret access and secret mounting?
A: Vault-based access retrieves secrets only when needed and allows policy-based control over who or what can request them. Secret mounting places credential material directly into the runtime environment, which is simpler to deploy but harder to segment, revoke, and trace across Kubernetes workloads.
👉 Read our full editorial: Kubernetes MCP secrets governance needs controlled vault access
