Red Hat Connectivity Link

GRPCRoute policy attachment

Beginning with Connectivity Link 1.4.0, GRPCRoute policy attachment is supported.

You can now use GRPCRoute custom resources (CRs) for your Remote Procedure Call (gRPC)-native applications and services in all of your Connectivity Link policies except TokenRateLimitPolicy CRs. You can migrate existing policies after you create your GRPCRoute CRs.

Important

GRPCRoute policy attachment is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

Connectivity Link policies can now target GRPCRoute resources with the targetRef parameter. Specifically, AuthPolicy and RateLimitPolicy accept GRPCRoute as a valid target kind. The following well-known attributes are also available for Common Expression Language (CEL) expressions:

request.grpc.service: Represents the exact service being called.
request.grpc.method: Represents the exact function being executed.

Using a GRPCRoute CR instead of an HTTPRoute CR when you already have a gRPC service can be an advantage in the following scenarios:

Native service or method matching in routing rules instead of raw path patterns.
Clearer intent. The route type declares that this is a gRPC service, making the topology more readable.
Gateway API validation. GRPCMethodMatch enforces valid service or method structure rather than free-form path strings.

The following CRs support GRPCRoute CRs in their targetRef fields:

AuthPolicy CRs
RateLimitPolicy CRs

DNSPolicy and TLSPolicy policies cover attached GRPCRoute CRs automatically.

Telemetry works with GRPCRoute CRs with no updates required. Although telemetry objects target the Gateway object, telemetry captures and reports on gRPC traffic matched by attached GRPCRoute CRs. You have the same level of observability for gRPC traffic as you currently do for traffic routed through HTTPRoute CRs.

Important

Ensure that there is not a mismatch between your Envoy proxy layer and upstream application layers in performing URL normalization.

Envoy serves raw request paths to the wasm-shim component unless normalize_path and merge_slashes are explicitly enabled in the Envoy HTTP Connection Manager (HCM) settings. This means that you can treat /admin and //admin as distinct paths in your CEL predicates, and so on.

However, your application receives the requests. That upstream service can strip redundant slashes or decode URL-encoded values. This means it bypasses your configuration, serving the protected route.

Make sure that you configure your upstream service so that you do not unintentionally bypass your own security. For more information, see "Customize your system on path normalization" in the Istio documentation.

Create a GRPCRoute custom resource

You can implement policy attachments based on qualified service and method names by using GRPCRoute policy attachment support. First, you must create a GRPCRoute custom resource (CR).

Important

GRPCRoute policy attachment support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

Prerequisites

You installed OpenShift Container Platform.
You installed OpenShift CLI (oc).
You installed the MCP gateway Operator.
You created a Gateway object.

Procedure

Create a GRPCRoute YAML by using the following example:

Example GRPCRoute CR

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: <grpcstore>
spec:
  parentRefs:
    - name: <kuadrant_ingressgateway>
      namespace: <gateway_system>
  hostnames: [<"grpc.example.com">]
  rules:
    - matches:
        - method:
            service: <"talker.TalkerService">
            method: <"Echo">
      backendRefs:
        - name: grpcstore
          port: 9000

See the "GRPCRoute custom resource parameters" reference information for details about parameters.

Important

If you include a spec.rules.matches.method block, you must specify a service name, a method name, or both. Omitting the method block entirely matches all gRPC traffic.

Apply your GRPCRoute CR by running the following command:
```
$ oc apply -f <grpcstore_route.yaml>
```
Replace <grpcstore_route.yaml> with the name of your gRPC YAML.
Example output
```
grpcroute.gateway.networking.k8s.io/grpcstore-route created
```
The output indicates that the route to the object exists.

Next steps

Create your policies with targetRef values that reference your GRPCRoute CR.
If you are migrating HTTPRoute CRs to GRPCRoute CRs, update existing policies to reference your GRPCRoute CR.

GRPCRoute custom resource parameters

You can use the following information about parameters and their values to create a GRPCRoute custom resource (CR) for Connectivity Link.

Table 7. GRPCRoute custom resource parameter reference table
Parameter	Definition and Details
`metadata.name`	The gRPC route name. Replaceable value.
`spec.parentRefs.name`	The name of the `Gateway` object to attach this policy to. Replaceable value.
`spec.hostnames`	List of your public DNS entries. Define this to match the DNS records pointing to your cluster.
`spec.parentRefs.namespace`	Use this parameter value if your `Gateway` object is in a different namespace than the route. Use the `Gateway` object namespace.
`spec.rules.matches.method.service`	The fully qualified name of the gRPC service from your `.proto` file. Copy the value exactly from your application code definitions. If you specify a `service`, but leave the `spec.rules.matches.method.method` unspecified, the rule applies to all of the functions within this specific gRPC service. You must specify at least one value for the `spec.rules.matches.method` parameter. Valid values are `service` or `method`.
`spec.rules.matches.method.method`	Use if you want a highly precise filter to isolate a specific function. You must specify at least one value for the `spec.rules.matches.method` parameter. Valid values are `service` or `method`.
`spec.rules.backendRefs.name` and `.port`	Point to your application pod. Replace the example values with the name of the service that is running your gRPC application and the port that your application service is listening on.

Migrate policies to GRPCRoute support

Important

When you want to replace your HTTPRoute custom resources (CRs) with GRPCRoute CRs, you must update your policies to reference a GRPCRoute CR. You must also configure other parameters in those policies as required for your use case.

Important

A GRPCRoute CR cannot coexist with an HTTPRoute CR on the same hostname. If both gRPC and HTTP traffic must share a hostname, use an HTTPRoute CR. Otherwise, use separate hostnames for HTTP and gRPC traffic.

Prerequisites

You installed OpenShift Container Platform.
You installed OpenShift CLI (oc).
You installed the MCP gateway Operator.
You created a Gateway object.
You have an existing HTTPRoute CR routing traffic to a gRPC service.

Procedure

Delete your HTTPRoute CRs. You must remove the HTTPRoute CR must before you can use the GRPCRoute CR on the same hostname.
Update the spec.targetRef.kind parameter value in your AuthPolicy and RateLimitPolicy CRs to GRPCRoute by using the following example:
Example AuthPolicy CR updated to gRPC
```
#...
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: GRPCRoute
    name: grpcstore
#...
```