alexsnaps / gw-policies-playground

Gateway API Policy Attachment playground

Kuadrant is trying to figure how to best implement the default & override hierarchy, as proposed by the specification. This is done in two different contexts:

• AuthPolicy, providing externalized authn/z to your services; and
• RateLimitPolicy, which lets you rate limit the access to your services from within the gateway.

The Playground

This simple playground aims at providing a space to programmatically test out different Policy "languages" (i.e. how do you declaratively express these constraints) while supporting the default and override concepts.

The idea is to use test code, to spec your Policy and most importantly your merging algorithm for these and use the tests as specification for what the expected outcome to applying these different Policyies would be.

Some quick examples

• How would a cluster operator express that any traffic to the cluster needs some sort of authentication, while leaving it to the application developer to specify how that authentication happens?
• How would a cluster operator require authentication with the company SSO, while the application developer specifies what role a user of the app would need for certain end-points?
• How does a cluster operator rate limits a whole subnet of clients, while the application developer bypasses it for authenticated admin users from that same subnet?
• … more?

Ideas behind the playground

• The array of Policyies is meant to represent "time ordering" of Policy CRs, as the "oldest" has precedence.
• It builds on the assumption that a Policy merge is only required once a Service will be hit, i.e. at the HTTPRoute level.
• Actual use cases should only require a _test.go file, with the Policy under test and a Merger function that knows about the semantic of the Policy and the possible "language" used (e.g. the user could submit a Policy CR with fields different from the actual resulting Policy applied, following the "merge").
• … more?

gw-policies-playground's Issues

Add host et al to GW-API mocks

The mock structs for the Gateway API Gateway and Route resources currently do not define the routing/filtering properties:

• Gateway: hostname
• HTTPRoute: hostnames and route matchers path, headers, queryParams and method

These are especially needed to write tests for deciding when a merger between policies is needed, provided the policies target distinct network resources that are strict subsets one of another.

Tests for policies targeting wildcard/hostnames and analogous

For cases that involving deciding on merging or not policies that target network resources that are strict subsets one of another. E.g.:

• Policy A → Gateway: hostname="*.acme.com"
• Policy B → HTTPRoute: headers{name="Authorization", type=RegularExpression, value="Bearer .+"}

Depending on the intent, the following variations might be possible:

1. Policy A merge overrides Policy B
2. Policy A merges providing defaults to Policy B
3. Policy A is accepted and Policy B is discarded (no merger)
4. Policy A is discarded and Policy B is accepted (no merger)
5. Policy A and Policy B are both accepted (no merger)

Depends on #3.