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.
At a glance
What this is: This is a deployment walkthrough showing that an Okta-authenticated BigQuery MCP server on Kubernetes still requires explicit identity governance across secrets, OIDC, token exchange, and public exposure.
Why it matters: It matters because IAM and NHI teams cannot assume Kubernetes orchestration removes identity risk when machine access, external identity federation, and exposed service endpoints are all still in play.
Context
An Okta-authenticated MCP server on Kubernetes is still an identity problem, not just a deployment problem. The article shows how local access patterns move into a cloud-hosted runtime where secrets, token exchange, and proxy exposure all become part of the trust model.
For IAM and NHI programmes, the important shift is that Kubernetes does not remove the need to govern who or what can obtain credentials, how those credentials are exchanged, and which network edges make the service reachable. The control boundary now spans Okta, Google Cloud, the MCP proxy, and the public tunnel.
That makes workload identity and service authentication the core governance issues, even though the implementation is framed as an integration exercise. The deployment pattern is typical of teams pushing developer tooling into production without first restating the identity assumptions that held in local development.
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. Use reusable CRDs for shared OIDC, telemetry, and tool permissions, assign ownership to each server or catalog entry, and review who can add backends or widen discovery. The goal is to keep identity, observability, and authorization controls stable as the fleet grows.
Q: Why do Kubernetes-hosted MCP services still need explicit identity controls?
A: Because Kubernetes only changes the runtime, not the trust model. The service still depends on stored secrets, federated tokens, and exposed endpoints, so governance must cover who can authenticate, what can be exchanged, and whether the public path is actually intended for production use.
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. A service that worked on a developer machine can inherit broader reach, wider credential exposure, and weaker operator separation once it is deployed behind a proxy and made reachable from outside the cluster.
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.
Technical breakdown
How OIDC, token exchange, and workload identity fit together
The deployment uses Okta as the user-facing identity provider, Google Cloud Workload Identity Federation as the trust bridge, and Google STS to mint temporary BigQuery access tokens. The MCP server does not need long-lived Google service-account keys if the OIDC assertion is exchanged correctly for short-lived cloud credentials. That reduces key persistence but does not remove the need to govern token audience, issuer, scope, and client secret handling. In practice, the security of the chain depends on each hop asserting exactly the identity and privilege needed for the next hop.
Practical implication: verify the token exchange path end to end and treat every trust hop as an access control boundary.
Why Kubernetes does not eliminate secret handling risk
Kubernetes changes where the credentials live, not whether credentials exist. The Okta client secret is still stored in a Kubernetes Secret, which means the deployment inherits cluster-level risks around namespace access, pod escape, and secret retrieval. ToolHive can orchestrate the proxy and server lifecycle, but lifecycle management is not the same as secret governance. Any team moving an authenticated MCP service into Kubernetes has to account for who can read the Secret, who can mount it, and whether that scope aligns with the intended operator role.
Practical implication: govern Kubernetes Secrets as production credentials, not as implementation details.
Why public tunnel access changes the attack surface
Exposing the proxy through ngrok creates a public entry point for authentication flows that were previously local. That is useful for remote access, but it also makes the MCP endpoint dependent on external reachability, OIDC correctness, and proxy validation behaving exactly as intended. Once the service is reachable over the internet, the relevant security question becomes whether the public URL, issuer, and audience settings are tightly bound to the intended application instance. In other words, the exposure model now includes transport, identity, and session establishment together.
Practical implication: bind the public endpoint to a single intended issuer, audience, and resource URL before allowing remote use.
Threat narrative
Attacker objective: The attacker would aim to obtain authenticated access to BigQuery through the exposed MCP service and use that trust chain to reach cloud data or tooling outside its intended scope.
- Entry occurs when an internet-reachable ngrok URL exposes the MCP proxy to remote clients rather than only to local developers.
- Credential and token handling depend on Okta client secrets, OIDC assertions, and Google STS exchange, so any weakness in that chain can broaden access beyond the intended user or workload.
- Impact would be unauthorized BigQuery access through a production-facing MCP service that was assumed to be safely isolated because it started as a local prototype.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Ephemeral cloud credentials reduce key persistence, but they do not remove trust concentration. The article shows a shift away from long-lived Google service-account keys toward token exchange, which is directionally better for machine identity hygiene. But the governance burden moves to issuer trust, audience binding, secret storage, and proxy validation. That means the control plane is narrower in one respect and more complex in another. Teams need to understand that short-lived credentials still require lifecycle, scope, and provenance control.
Identity is now shared across user, workload, and transport layers. Okta authenticates the user, Kubernetes hosts the workload, Google STS issues the cloud credential, and ngrok exposes the reachable endpoint. None of those layers can be assessed in isolation if the service is used for production analytics or sensitive data access. The practical implication is that NHI governance, workload identity, and access management have converged into a single operating model for MCP services.
BigQuery MCP access is a governance problem because the proxy becomes part of the trust perimeter. The ToolHive proxy is doing more than forwarding requests. It is enforcing the authentication and token exchange path that decides whether the server can act on behalf of a user. That places the proxy inside the identity architecture, not outside it. Practitioners should review proxy-mediated access the same way they review federation and service-to-service trust.
Observed deployment patterns suggest a named concept: identity boundary drift. The service starts as a local developer convenience, then becomes a remotely reachable production endpoint without a corresponding reset in governance assumptions. That drift is what creates risk, not Kubernetes itself. The implication is that teams must redraw identity ownership and trust boundaries whenever an MCP service changes environment, exposure model, or credential source.
From our research library:
- 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.
- Read next: NHI Lifecycle Management Guide
What this signals
Identity boundary drift: when an MCP server moves from local development into Kubernetes and remote access, the security model shifts from a contained prototype to a multi-system trust chain. That transition should trigger a fresh review of secret ownership, token audience, and public endpoint exposure before production use.
Machine identity controls become more important here than the deployment platform itself. The core decision is whether the service can obtain only the credentials it needs, through the one identity path it is supposed to use, without creating a reusable trust shortcut for operators or clients.
Kubernetes can host the workload, but it does not define acceptable authentication scope. The deployment remains safe only if proxy validation, OIDC configuration, and external credential exchange all point to the same intended service boundary.
For practitioners
- 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.
- Review public exposure before remote use Treat the ngrok URL as a production entry point and confirm that the resource URL, proxy validation, and OIDC settings are all aligned.
- Separate developer convenience from production governance Require a production review whenever a local MCP prototype is moved into Kubernetes, because the access model changes even if the application code does not.
Key takeaways
- The article shows that an Okta-authenticated MCP server still needs explicit governance when it moves into Kubernetes and remote exposure.
- The main control issues are secret handling, token exchange scope, and whether the public endpoint really matches the intended trust boundary.
- Practitioners should review MCP deployments as identity systems, because orchestration does not remove the need to control who can authenticate and what they can reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on OIDC, token exchange, and service authentication for an MCP server. |
| NHI-02 — Secret Leakage | The Okta client secret is stored in Kubernetes and becomes a governed credential. | |
| NHI-07 — Long-Lived Secrets | The article explicitly contrasts temporary credentials with the pain of managing Google service-account keys. | |
| Recommendation — Apply NHI-04 controls to validate OIDC flows, issuer trust, and service authentication boundaries. Reduce exposure of stored client secrets and audit every place the secret can be mounted or read. Replace long-lived credentials with short-lived token exchange wherever the service model permits it. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The deployment depends on tightly scoping who and what can access the BigQuery-backed MCP service. |
| Recommendation — Limit entitlements on the MCP service so only intended identities can obtain BigQuery access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Client secrets, OIDC tokens, and exchanged credentials all fall under authenticator lifecycle control. |
| Recommendation — Manage authenticators so secrets, tokens, and exchanged credentials are issued, stored, and revoked deliberately. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Publicly reachable credentials and token exchange create pathways an attacker could abuse to reach cloud data. |
| Recommendation — Map exposed identity flows to credential access and lateral movement to prioritise detection and containment. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
- Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
- Kubernetes Secret: A Kubernetes Secret is an object used to store sensitive data such as passwords, tokens, certificates, and API keys outside application code. It simplifies delivery to Pods, but it does not automatically protect the data. Security depends on storage encryption, access control, and monitoring of how the secret is used.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org