BigQuery MCP on Kubernetes: are your identity controls ready?

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.

NHIMG editorial — based on content published by Stacklok: Deploy an Okta-authenticated BigQuery MCP server on Kubernetes

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

Questions worth separating out

Q: How should security teams govern an MCP server that uses federated identity and token exchange?

A: Treat the MCP server as a managed non-human identity with a documented owner, explicit token audience, scoped permissions, and a defined revocation path.

Q: When does an MCP server create excess identity risk?

A: Risk rises when the server can query more systems, data classes, or environment context than the task requires.

Q: What breaks when developers expose an MCP server publicly without lifecycle review?

A: The access boundary and the governance boundary stop matching.

Practitioner guidance

• Inventory every MCP endpoint as a managed NHI asset Record the server, proxy, OIDC client, external auth config, and public URL as one governed access path.
• Replace configuration-file secrets with reviewed secret references Store credentials only in dedicated secret resources or external secret systems, and verify that no client secret or token appears in deployment manifests, bootstrap files, or operator templates.
• Scope token exchange to the narrowest workable audience and scopes Limit STS audience values to the specific workload identity pool and restrict scopes to the minimum needed for BigQuery access.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Kubernetes and Helm installation commands for the ToolHive Operator
• Full MCPServer and MCPExternalAuthConfig YAML for the BigQuery deployment
• Proxy tunnel setup details for ngrok and the ToolHive CLI
• VS Code MCP client configuration and authentication prompts

👉 Read Stacklok's guide to deploying an Okta-authenticated BigQuery MCP server →

BigQuery MCP on Kubernetes: are your identity controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →