Where the OpenShift MCP gateway draws its trust boundaries

A Red Hat AI Services field repository turns MCP gateway security into a concrete OpenShift deployment. The useful part is not the installation script by itself; it is the guide’s explicit separation of identity, routing and tool authorization.

The repository targets OpenShift 4.19 or later and Red Hat Connectivity Link 1.4, with Red Hat build of Keycloak as the identity provider. It is a companion guide rather than a replacement for Red Hat’s supported product documentation.

Authentication ends at the public listener

The gateway exposes a public mcp listener. A Kuadrant AuthPolicy validates JSON Web Tokens issued by Keycloak there, while OAuth protected-resource metadata gives compatible clients the authorization-server location and supported scopes. Requests without a valid token receive a 401 and a WWW-Authenticate response.

That answers who may enter the gateway. It does not yet answer which MCP tool that identity may execute.

The guide places that second decision on an internal mcps listener. The MCP router intercepts tools/call, resolves the tool prefix to a registered backend, strips the prefix and adds x-mcp-servername and x-mcp-toolname headers. A separate AuthPolicy evaluates those router-generated values against Keycloak resource_access roles such as tool:greet or tool:calculate_dti. Session setup is excluded from this check so initialization is not mistaken for a tool invocation.

The trust boundary is the router, not just the token

This architecture creates four boundaries practitioners should review:

1. Keycloak owns identity and role claims. A valid token is necessary, but its per-server tool roles are what constrain execution.
2. The public listener owns authentication. OAuth discovery remains unauthenticated; the MCP endpoint does not.
3. The router owns execution context. Authorization depends on headers produced after parsing the MCP request, so filter order matters: the external-processing router must populate tool and server names before Kuadrant evaluates policy on the internal listener.
4. Registered backends remain trusted workloads. The controller resolves MCPServerRegistration and HTTPRoute resources into backend configuration; authorization controls access to a selected server and tool, not the behavior of that tool after invocation.

The split also explains why copying one policy is insufficient. Deleting the public authentication policy leaves the identity boundary incomplete; applying tool checks on the public listener occurs too early, before routing metadata exists.

What to change before production

The repository uses sample users, passwords and a password-grant flow for verification. Treat those as test fixtures, not an identity design. Production teams should connect a managed realm and approved OAuth client flow, replace sample credentials, restrict who can create gateway and server-registration resources, and test both allowed and denied calls.

The guide notes another operational edge: if Kuadrant’s WASM plugin is unavailable when the proxy starts, traffic can fail closed. Teams should therefore verify both AuthPolicies report Enforced, exercise OAuth discovery, confirm 401 and 403 paths, and monitor Authorino authorization denials.

The larger lesson is precise: centralizing MCP traffic does not create one trust decision. It creates a sequence—authenticate the caller, derive the requested server and tool, authorize that pair, then route to a separately governed backend.