Notifications
Clear all
Topic starter
19/08/2026 3:39 pm
TL;DR: Shared policy objects, zero-downtime migration, and a clearer control plane for MCP server access are the material changes as ToolHive v0.23.0 graduates its MCP server CRDs to v1beta1, shifting shared OIDC, telemetry, tool filters, remote server entries, virtual servers, and registry management into referenced resources that are stable enough for production use, according to Stacklok. For IAM and NHI practitioners, the material change is not feature count but governability: reusable policy objects, zero-downtime migration, and a clearer control plane for MCP server access.
NHIMG editorial — based on content published by Stacklok: ToolHive grows up, what the CRD graduation to v1beta1 means for your cluster
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.
Questions worth separating out
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: What breaks when MCP access controls stay embedded in each server manifest?
A: Configuration drift breaks first.
Q: When should security teams move MCP settings into shared referenced resources?
A: As soon as multiple servers reuse the same identity provider, telemetry stack, or tool allow list.
Practitioner guidance
- Standardise shared MCP identity controls Move OIDC, telemetry, tool filters, and external auth into referenced CRDs so the same control set is reused across the cluster instead of copied into each manifest.
- Inventory and replace inline configuration Find every remaining inline oidcConfig, telemetry, and tools block, then migrate each one to a reusable resource before deprecation warnings become removal events.
- Govern remote servers as catalog entries Use MCPServerEntry for hosted or external MCP endpoints so access, ownership, and trust can be tracked without inventing unnecessary proxy infrastructure.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact v1alpha1 to v1beta1 migration sequence, including stored-version handling and deprecation warnings.
- The full CRD surface for MCPOIDCConfig, MCPTelemetryConfig, MCPToolConfig, MCPExternalAuthConfig, and VirtualMCPServer.
- Implementation detail on session restore, backend routing, composite tool definitions, and policy evaluation.
- Registry deployment options and the spec-aligned browse endpoints that were not expanded here.
👉 Read Stacklok's ToolHive v1beta1 graduation post for MCP server migration details →
MCP server CRD graduation to v1beta1: what teams need to know?
Explore further
19/08/2026 4:19 pm
MCP control planes are now part of NHI governance, not just platform plumbing. Once MCP servers become shared entry points to tools and data, they inherit the same governance expectations as service accounts and API keys. The shift to reusable CRDs in ToolHive reflects a broader requirement: identity configuration must be stable, scoping must be explicit, and lifecycle changes must be managed centrally. That is the baseline control model practitioners should assume for MCP estates.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security.
A question worth separating out:
Q: What should operators check before upgrading from v1alpha1 to v1beta1?
A: Confirm which objects still write the deprecated version, then reapply manifests at v1beta1 and watch stored versions until the old API disappears from the cluster. That prevents upgrade surprises and prepares the fleet for eventual removal of v1alpha1 without downtime.
👉 Read our full editorial: ToolHive v1beta1 graduation changes how MCP servers scale
