Well-known Attributes

[guicassolato]

No description provided.

[eguzki]

Overall, looking super good.

Kuadrant's well known attributes are another value added by Kuadrant to be leveraged by users.

[maleck13]

some small comments:

We should follow up to ensure the sections marked as These attributes need confirmation if they are all actually available to be requested by the Wasm-shim. are confirmed.

[alexsnaps]

some small comments:

We should follow up to ensure the sections marked as These attributes need confirmation if they are all actually available to be requested by the Wasm-shim. are confirmed.

Just to make it clear to all, these aren't spec'ed anywhere afaik, so that every other host might have a different set of those available...

[maleck13]

The wasm ones? Should we consider removing those or not adding the to the public facing docs? @guicassolato what if the public facing docs communicated only things like the request , auth and rate limit attributes?

[alexsnaps]

Some notes here from me, feel free to ignore for now, but I think we'll have to account for these:

• Currently the Rust SDK makes no difference between the property being null or actually being "not found". This might be an issue for us if we want to support multiple hosts....
• A property's value are just pub type Bytes = Vec<u8>... if there is, amongst different hosts, different types to be returned for a given property, how would we deal with these? Minor issue, if it ever happens even, but raises another question...
• Currently, Envoy's RL protocol "only" lets us pass String pairs thru the descriptors. Further more, Rust only allows valid UTF-8 strings... So we'd probably need to "stringify" the different types... Integers can be integer literals in Limitador's expression language. Timestamps could "simply" be ISO 8601 formatted strings. Which leaves us with more complex data structures... Depending on what we'd want to support as operators and whether these need to be evaluated in Limitador, we'll have to either support literals for at least Arrays and Maps, but we'd be left with Metadata & Node (that's if I don't miss anything)... Again, if these are to be evaluated in Limitador and NOT with the wasm-shim.
• Finally, I'm unsure what someone would use the wasm.* attributes for? If there is no actual use for them today, should we just avoid adding them now?

[maleck13]

@alexsnaps I am a fan on not making those wasm ones available. Or at least not documenting publicly for now. I can imagine you can get a long way with more complex use cases with the request , auth and rl properties @guicassolato WDYT

[guicassolato]

Should we consider removing those or not adding the to the public facing docs?

I'm okay with omitting the Wasm attributes. What about the Proxy configuration ones? Do we need them?

[alexsnaps]

What about the Proxy configuration ones? Do we need them?

I see you applied the same logic there, right? i.e. remove them until we actually have a use case that requires them?

[alexsnaps]

Thinking... should we only support (nested) Maps and "flatten" object structures down to these? So we'd have Strings, Numbers (i64?), arrays and nested maps... Would that be good enough... for now?

[alexsnaps]

Maps would only ever be Stringly key'able probably...

[guicassolato]

should we only support (nested) Maps and "flatten" object structures down to these? So we'd have Strings, Numbers (i64?), arrays and nested maps... Would that be good enough... for now?

I think so.

I think we only (mainly?) have this problem in the Rust-based apps, and to retrieve the Metadata attributes, which, by transition, extends the problem to the Auth attributes as well, correct?

Specifically the metadata attribute, in the Envoy environment, is a Map of String → Struct, where Struct is itself another Map of String → Value and Value can be pretty much anything.

The main use case we have for metadata in the Rust-based chain of apps (i.e. wasm shim, Limitador) is essentially of the auth service passing data to the RL service. Then, there are the edge (?) cases of users who want to inject sources of metadata in the filter chain themselves (e.g. from a Lua filter, etc).

The kind of thing that one may want to export from the auth service to RL is hard to predict, but I would guess most of them is related to attributes of the identity/principal –– or what we will later abstract as auth.identity.* in the RLP (thus achieving consistency with the AuthPolicy).

I have no recollection of identity objects ever defined as Map structs other than by only having stringy keys, i.e. auth.identity: Map<String → Any> in virtually 100% of the cases. And the values themselves are rarely of complex types – some Arrays and nested Maps no more than a 2-level deep.

E.g.,

• auth.identity.username: String
• auth.identity.verified_email: Boolean
• auth.identity.scopes: Array<String>
• auth.identity.access: Map<String → Map<String → Array<String>>>

Then we have other auth attributes (auth.(metadata|authorization|response.callbacks)) that are guaranteed to be Map<String → Any>. These are really open and the Any type becomes a problem.

Amongst all these known attributes, some could be used in conditions to be evaluated by the wasm shim, but, given the currently supported operators, not all of them.

As @alexsnaps pointed out, what is passed to Limitador in the RateLimitRequest is always String → String, although Integer literals can be already distinguished and (I'm guessing) Booleans should be easy to add support to if we want. Limitador also has its own set of operators, even though Kuadrant only needs == now. Still, this imposes a second level of constraints on the data types.

All this so far to explain (and agree) that the problem lies in the more complex data structures indeed.

Given, however:

• the use cases we know to exist,
• the operators we currently support,
• the protocol limitations we have, and
• the possibility the user almost always has to re-state the problem/implement the solution in a slight different way (e.g., in a AuthPolicy, in a Lua filter), to reduce it to an instance where only simple data types are employed,

...I think we do not need to support complex data structures. We can try to detect Numbers, maybe Booleans, but the rest can be always String.

A null value can be an empty string. Some meaning is lost in the process, but it's not the end of the world IMO (for this particular case). An Array is a String whose first character is a [ and the last is a ]; similarly, a Map starts with { and ends with }.

The user should have this in mind when defining conditions, qualifiers, or pretty much anything else that derives from Well-known attributes.