We're excited to announce a significant enhancement to the ToolHive Operator: multi-namespace deployment support. This update provides organizations with greater flexibility and security when deploying MCP (Model Context Protocol) servers across their Kubernetes environments.

What's New

The ToolHive Operator now supports two distinct deployment modes:

🌍 Cluster Mode (Default)

Suitable for platform teams managing MCPServers across the entire cluster

• Full cluster-wide access to manage MCPServer's in any namespace
• Uses ClusterRole and ClusterRoleBinding for broad permissions

🔒 Namespace Mode (New!)

Perfect for multi-tenant environments and organizations following the principle of least privilege

• Restricted access to only specified namespaces
• Uses ClusterRole with namespace-specific RoleBindings for precise access control

Why Multi-Namespace Support Matters

Enhanced Security

In namespace mode, the ToolHive Operator only has permissions in the namespaces you explicitly specify. This significantly reduces the blast radius and follows Kubernetes security best practices. This prevents a compromised operator from accessing sensitive workloads in other namespaces. For example, if an attacker exploits the operator, they can't pivot to your production databases, payment systems, or other critical applications running in separate namespaces. It also eliminates the risk of accidental misconfiguration affecting unrelated services across your entire cluster.

Multi-Tenancy Support

Different teams can now have their own namespaces with MCPServers while maintaining strict isolation. The operator in the toolhive-system namespace can manage resources across designated team namespaces without requiring cluster-wide permissions. This eliminates resource conflicts where one team's MCP configuration could interfere with another team's. It also prevents competing resource quotas or conflicting network policies that could degrade performance. Teams can iterate independently without waiting for central infrastructure changes, accelerating development cycles while maintaining security boundaries between departments.

Compliance and Governance

Organizations with strict security requirements can now deploy ToolHive with minimal necessary permissions, making it easier to pass security audits and meet compliance requirements. Security auditors can quickly verify that ToolHive follows the principle of least privilege by examining a limited set of namespace-scoped permissions rather than auditing complex cluster-wide access patterns. This reduces audit preparation time from weeks to days and helps developers satisfy InfoSec requirements upfront, avoiding the common scenario where security teams block deployments due to overly broad permissions that violate corporate security policies.

How It Works

The magic happens through an RBAC pattern where the operator uses a ClusterRole (for permission consistency) but applies it through namespace-specific RoleBindings. This means:

• Single source of truth: One ClusterRole defines all the permissions
• Namespace isolation: RoleBindings restrict where those permissions apply
• Dynamic scaling: Easy to add or remove namespace access as needed

Helm Configuration Examples

Cluster Mode (Default)

# values.yaml
operator:
  rbac:
    scope: "cluster"

This creates a ClusterRoleBinding granting the operator access to all namespaces.

Namespace Mode

# values.yaml
operator:
  rbac:
    scope: "namespace"
    allowedNamespaces:
      - "team-frontend"
      - "team-backend"
      - "staging"
      - "production"

This creates individual RoleBindings in each specified namespace, granting the operator access only where needed.

What Permissions Does the Operator Get?

The ToolHive Operator requires specific permissions to manage MCPServer resources and their associated Kubernetes objects:

Core Permissions

• MCPServers: Full lifecycle management of your custom resources
• ServiceAccounts: Creates dedicated service accounts for each MCPServer
• Roles & RoleBindings: Manages RBAC for ProxyRunner and MCPServer workloads
• ConfigMaps & Secrets: Handles configuration and credentials
• Deployments & Services: Manages the underlying workloads

Additional Permissions

These are permissions that are needed by the toolhive-operator so that it can grant these privileges to the ProxyRunners in the dedicated namespaces. The ProxyRunners are the component that uses these permissions.

• Pod logs: Ability to get pod logs
• Pod attach: Ability to attach to the pod (for stdio MCP Servers)

Note: The above are what are currently used, these are likely to evolve in future.

Scope-Specific Behavior

• Cluster mode: These permissions apply cluster-wide
• Namespace mode: These permissions apply only to specified namespaces

Real-World Use Cases

Multi-Team Organization

# Platform team controls toolhive-system
# Individual teams get their own namespaces
operator:
  rbac:
    scope: "namespace"
    allowedNamespaces:
      - "team-data"
      - "team-ai"
      - "team-platform"

Environment Separation

operator:
  rbac:
    scope: "namespace"
    allowedNamespaces:
      - "development"
      - "staging"

What's Next?

This multi-namespace support is just the beginning. We're looking into additional features including:

• Dynamic namespace discovery: Automatically detect and manage namespaces based on labels
• Separate ProxyRunner and MCPServer permissions: The ProxyRunner and the MCPServer pod do not need to share permissions, we want to make this even more secure by following the principle of least privilege

Community Feedback

We'd love to hear how you're using multi-namespace support! Share your use cases, feedback, and questions:

• GitHub
• Discussions: Join our community discussions on Discord
• Issues: Report bugs or request features

The ToolHive Operator's multi-namespace support represents our commitment to providing secure, flexible, and enterprise-ready solutions for MCP server management. Whether you're a platform team managing cluster-wide resources or a security-conscious organization requiring strict namespace isolation, we've got you covered.

Happy deploying! 🚀