Configurations not reconciled by Kuadrant operator

[Boomatang]

When kuadrant is configured using an AuthPolicy and RateLimitPolicy CRs, a user can still edit the configurations in the AuthConfig and Limitador CRs. These edits are not reverted by the kuadrant operator and leads to a misalignment in expect configurations.

Solution here would be for the kuadrant operator to monitor changes to the AuthConfig & Limitador CRs and reconcile configuration changes back to what is stated in the AuthPolicy & RateLimitPolicy.

Related Issue:

• Support MGC requirements to configure Redis' URL for limitador #163
• Define how Kuadrant lets the user configure "some" of the underlying services #164
• Custom underlying services architecture#16

[eguzki]

This might be hard. If I change the limits of a Limitador CR manually, the operator needs to map a change of a limitador CR to (one or multiple) RLP CRs. This mapping needs to be designed in advance.

One possible implementation would be based on back reference annotations, that is, the Limitador CR has one annotation per RLP which has added configuration to it. When the limitador CR change event is handled, you read the CR and you know all of the RLP's that need to be reconciled. Not saying we must do that, just giving ideas

For authconfig change, it might be easier, because there is one-to-one mapping between authconfig and authpolicy. (easier to implement, but not simpler, though)

[Boomatang]

I have some open questions that would be good to clear up.

1. Do we expect more than one RPL to be attached to a single HttpRoute?
2. Are multiple RPLs expected in a single namespace?
3. Can RPLs attach across namespaces?
4. what is different about how we handle RPLs that are attached to the gateway?

The same questions would apply to the AuthPolicies.

[guicassolato]

1. Do we expect more than one RPL to be attached to a single HttpRoute?

No.

2. Are multiple RPLs expected in a single namespace?

Yes.

3. Can RPLs attach across namespaces?

No.

4. what is different about how we handle RPLs that are attached to the gateway?

Attaching a policy to a gateway works more or less as a "dynamic shortcut" to targeting all HTTPRoutes attached to and accepted by that gateway.

The RLP controller finds and goes through all those HTTPRoutes, and acts as if the RLP were attached to the routes directly (kinda). The resource that traces back to the policy (through the direct back-ref annotation) is the gateway though; not the route.

Any changes in the topology of the HTTPRoutes and parent gateways must be reconciled by the RLP controller. E.g.: new HTTPRoutes attaching to the gateway, HTTPRoutes that gets the parent gateway removed, or are deleted, etc. (This the "dynamic" part of the "shortcut".)

RLPs that target a gateway cannot specify routeSelectors, meaning all HTTPRouteRules of the HTTPRoute are implicitly selected.

The same questions would apply to the AuthPolicies.

The same principle should apply, although we haven't started working on AuthPolicy v2 yet, and therefore the current state of things might differ from this description.

[Boomatang]

When using kuadrant a user is expected to create the RLPs for the required routes and kuadrant configures the limitador CR. Is there anything that would stop a user from configuring a second limitador CR in the name space that is not managed by limitador? If this is possible, is it expected behaviour?

[eguzki]

Is there anything that would stop a user from configuring a second limitador CR in the name space that is not managed by limitador?

No, there isn't. If the user wants a limitador CR in her/his namespace, there is no conflict with the instance managed by kuadrant's control plane in the kuadrant's namespace. To be clear, the limitador operator is the one reconciling limitador CR's.

PS: There could be a conflict if two limitador instances share the same backend (i.e. redis). Each instance will have it's own limits (given by the Limitador CR), but counters could overlap and conflict.