Kuadrant 1.5.3 brings API policy and developer credentials to gRPC routes

Kuadrant Operator 1.5.3 extends its policy model to gRPC services and introduces Kubernetes APIs for requesting and approving developer API keys. The release, published September 3, adds GRPCRoute support to AuthPolicy, RateLimitPolicy and PlanPolicy, alongside APIKeyRequest and APIKeyApproval resources for the developer portal.

What changed for platform teams

Previously, teams applying Kuadrant policy through Gateway API resources had a more complete path for HTTP routes than for gRPC. The 1.5.3 work makes GRPCRoute a supported policy target and documents both route-wide and method-level attachment. A policy can target the route, or use a section name to address an individual GRPCRouteRule; Kuadrant’s accompanying gRPC guide and policy-reference update demonstrate authentication and rate limiting at those two levels.

That matters for rollout because a platform team does not have to translate a gRPC service into an HTTP-specific policy model or protect every method identically. It can establish a baseline on the route, then add a tighter limit or authentication requirement to a named method section. The same documentation also records practical boundaries: policy targets remain constrained to the same namespace, and HTTP and gRPC routes cannot share a hostname in the documented configuration.

The release includes related control-plane work: unified route-policy discovery for GRPCRoute, support in PlanPolicy, and updated examples. It also refreshes the bundled Authorino, Limitador, DNS, WASM, console-plugin and developer-portal-controller components.

What changed for developer onboarding

The developer-portal path now has explicit request and approval objects rather than treating an API key only as an opaque credential handed out outside the cluster workflow. The API-key change adds APIKeyRequest and APIKeyApproval, updates operator permissions for their status and lifecycle, and revises the APIKey schema with an API-product namespace reference and a required Secret reference.

For developers, that creates a declarative handoff: request access to an API product, wait for an approval decision, then consume the resulting key through a referenced Kubernetes Secret. For platform teams, the request and approval state is represented in cluster resources that can be governed with RBAC and observed through status conditions. The new Approved printer column is a small but useful operational detail when checking requests with Kubernetes tooling.

What to do

Teams evaluating 1.5.3 should first test policy precedence on representative gRPC methods, especially where route-level defaults and section-level overrides combine. They should also review who may create requests, grant approvals and read referenced Secrets before exposing the developer-portal workflow. The release makes the mechanics Kubernetes-native; it does not remove the need to define the organization’s approval and credential-access policy.