search

Kuadrant / kuadrant-operator

The Operator to install and manage the lifecycle of the Kuadrant components deployments.
Apache License 2.0
31 stars 31 forks source link

Support the concept of Policy constraints #757

Open maleck13 opened 1 month ago

maleck13 commented 1 month ago

What

While overrides and defaults provide valuable ways for different personas to collaborate on different policies that form a single effective policy, there is a weakness in this concept. Overrides and defaults do not allow a persona working higher in the hierarchy to pick a set of boundaries and rules within which someone can override a default from lower in the hierarchy.

Use Case:

As a gateway admin I have set a generic limit of x requests per remote IP per minute across all endpoints as a default to ensure there is some level of protection for endpoints exposed via the targeted gateway. I understand that the development teams may need to override this limit and potentially increase it for a given end point. I want to allow them to do so, but within a particular set of constraints IE they can override my limit for their endpoint up y requests per IP per minute but not beyond that.

As a gateway admin, I have set a default DENY all auth policy at the gateway. I want development teams to override this for their endpoints but only if they use the company SSO server. I don't want to allow them simply to set an override that allows all or allows API key access

maleck13 commented 1 month ago

@guicassolato @alexsnaps perhaps you can come up with better use cases to describe the role of constraints in overrides and defaults. I have attempted to capture what we were discussing.

guicassolato commented 1 month ago

What you described looks good IMO @maleck13. It's also described here: https://docs.kuadrant.io/0.8.0/architecture/rfcs/0009-defaults-and-overrides/ (see User story policy-constraints.)

Because we were planning to implement this via when condidions, these issues were opened:

But I can see the relevance of having it described at use-case level too, after all we may end up implementing differently than originally thought (probably will.)