Topic starter
20/08/2026 5:23 pm
TL;DR: An Okta-authenticated BigQuery MCP server can be moved from local development into a Kubernetes deployment using ToolHive, token exchange, and ngrok for remote access, according to Stacklok. The practical lesson is that MCP access, secrets handling, and workload identity still require explicit governance, because orchestration does not remove the identity risk.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Deploy an Okta-authenticated BigQuery MCP server on Kubernetes”.
Key questions
Q: How should teams govern MCP servers once they are exposed through Kubernetes CRDs?
A: Treat MCP servers like any other governed identity surface.
Q: Why do Kubernetes-hosted MCP services still need explicit identity controls?
A: Because Kubernetes only changes the runtime, not the trust model.
Q: What breaks when a local MCP prototype is moved into production without redesigning access control?
A: The biggest failure is assuming local trust boundaries still apply.
Practitioner guidance
- Define the MCP identity boundary Document where user identity ends, where workload identity begins, and which component is responsible for each trust decision in the BigQuery access path.
- Harden Kubernetes Secret handling Restrict who can read the Okta client secret, audit Secret access, and ensure only the intended proxy workload can mount it.
- Constrain token exchange inputs Validate issuer, audience, subject token type, and scope so the STS exchange can only produce the BigQuery privileges the service actually needs.
Bottom line: The article shows that an Okta-authenticated MCP server still needs explicit governance when it moves into Kubernetes and remote exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:13 pm
Local prototype assumptions break as soon as MCP reaches Kubernetes and the public internet. The article is not really about deployment convenience, it is about moving a trusted local workflow into a runtime where identity must be revalidated at every hop. Once the service relies on Okta, Google STS, Kubernetes Secrets, and ngrok, the security model is distributed across systems that each need explicit governance. Practitioners should treat the deployment as a new identity boundary, not a scaled-up version of the lab setup.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
A: They should compare the change in trust assumptions, not just the convenience of remote connectivity. Internet exposure adds endpoint validation, transport trust, and public authentication flow management, which means the remote version needs stronger identity and secret governance than a local-only deployment.
👉 Read our full editorial: Okta-authenticated MCP servers on Kubernetes need tighter identity controls