Effective plan policy behavior explained

[eguzki]

@didierofrivia can you confirm the analysis is correct?

[didierofrivia]

AFAIK, there's no effective PlanPolicy per se, one would be talking about the resulting effective RateLimitPolicy as you mention here... however, I'm not entirely sure how the most specific (HTTPRoute) rules would rule out when there's an override in the Gateway, I think it doesn't matter it always gets the most restrictive rule in the end?

[eguzki]

Indeed, PlanPolicy does not follow Policy Attachment rules and lacks default and override stanzas.

I have investigated the multiple PlanPolicy scenario and found that it is currently broken in Kuadrant. I’ve opened an issue in the kuadrant-operator repo (#1741) detailing my findings.

PlanPolicy reconciliation has two primary jobs:

1. Reconciling the rate limit policies on behalf of the PlanPolicy owner.
2. Reconciling the AuthConfig resource to apply the PlanPolicy mapping so that, during the authentication phase, a "plan" attribute is populated with the plan_id to be used as a rate-limiting descriptor.

The good news is that rate limit policies are correctly reconciled; as the function comment suggests, the gateway-level rate limit policy is atomically overridden (and thus, effectively not enforced). However, the authentication portion is broken, and the overridden PlanPolicy configuration is still being enforced.

Regardless, the multiple PlanPolicy scenario, as designed today, is based on an atomic override merging strategy. Therefore, the HTTPRoute policy should take precedence and be enforced once the issue is fixed. Given this, I believe the proposed comment is correct as of today.