Support GEP-995 / Support Attaching Policies to Route Rules

[guydc]

Description: https://github.com/kubernetes-sigs/gateway-api/pull/2985

Wait for GW-API v1.2

• Propagate route rule names to xds as route metadata
• Support attachment of policies to route rules

[arkodg]

also related to https://github.com/envoyproxy/gateway/issues/2054

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[kkk777-7]

Hello @arkodg , @guydc Do you know if anyone is working on this? If not, can I try to work on it?

[arkodg]

got for it @kkk777-7 !

[kkk777-7]

@arkodg I'm not sure about the scope in this PR should cover, so I'd like to hear your thoughts.

---

It seems that targetRef with a sectionName is recommended only for use with Direct policies.

LocalPolicyTargetReferenceWithSectionName identifies an API object to apply a direct policy to.

https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/policy_types.go#L84

From what I understand, policies like BackendTrafficPolicy (BTP) and SecurityPolicy (SP) are considered Inherited policies, which can target either Gateway or HTTPRoute.

• https://gateway.envoyproxy.io/contributions/design/backend-traffic-policy/#design-decisions
• https://gateway.envoyproxy.io/contributions/design/security-policy/#design-decisions
• https://gateway-api.sigs.k8s.io/geps/gep-2649

Therefore, I'm considering the following options for the scope of implementation — which do you think would be the most appropriate?

---

Option 1: Support only the most specific resource scope

• (Inherited) Gateway/HTTPRoute, attached to Gateway – Not Supported
• (Inherited) Gateway/HTTPRoute, attached to HTTPRoute – Supported
• (Direct) Gateway, attached to Gateway – Supported

※ In this option, the mergeType feature in BTP would not be supported.

This approach is simple and treats inherited policies as effectively direct policies by limiting them to the most specific target. However, it would not allow applying policies at the Gateway listener level for BTP/SP.

---

Option 2: Full support

Policies would be applied in the following order of precedence:

xRoute sectionName > xRoute > Gateway sectionName > Gateway

If sectionName is specified on a Gateway, the policy is applied only to the xRoutes attached to the corresponding listener.

This approach is more complex and diverges from the standard conventions of the Gateway API. However, users can specify sectionName on all resources.

[kkk777-7]

I found that using section name with Inherited policies with other oss gateway api providers.

Kuadrant RateLimitPolicy. https://docs.kuadrant.io/1.2.x/kuadrant-operator/doc/overviews/rate-limiting/#overlapping-gateway-and-httproute-ratelimitpolicies

So, I'll proceed with implementation with Option2 Full support.

[arkodg]

Thanks @kkk777-7 yes option 2 is what we have implemented in the project ( Gateway and Route) , this feature will add another level