Support a `filter_by` option in Gaurd about vakt HOT 3 OPEN

Probably, I'm missing the point, but what is the benefit of using a separate filter_by option that user can pass to Guard and down to a particular storage?

My view of the situation is the following:
Requirements:

• We need to be able to filter on storage level for better performance.
• We need to support storage-level filtering for String (regex)-based policies.
• We need to support storage-level filtering for Rule-based policies.
• We need to support ability to use custom Rules and thus Rule-based policies defined with them.

What is needed to be done:

• Within private filter methods for any given particular Storage we can figure out the resulting filter that later be used in find_for_inquiry. Here, based on the Inquiry and Checker we can define how to construct a filter.
• Any particular Storage must adjust/implement write part of its interface to store policies in such a way that will be appropriate and convenient for the later querying with the query constructed with the aforementioned filter method (if needed, of course). Thus, it's very Storage-specific. Based on the Policy information it can be achieved both for String- and Rule-based policies.
• In order to support custom Rules we need a way to pass some kind of a mapper that will give information or hint for a Storage on how to store and/or query policies with custom rules.
• If we modify existing Storages, we need to add a migration that will adjust saved policies and add indexes where appropriate.

@ketgo, what do you think?

from vakt.

I agree with the laid out requirements and what is needed to be done.

Regarding the filter_by option, I had not thought through it completely earlier so was unclear. The idea here is to provide policy grouping. This grouping can be by a key or ID. This way the storage can then retrieve only those policies which belong to the same group during evaluation. Thus the group ID will need to be passed during inquiry by the Guard, or it can be part of the Inquiry. There are a couple of use-cases that I can think of where this might be useful:

1. Segregation of policies based on customers, accounts, etc. This way evaluation of polices for account 'A' or customer A will not require evaluation of those for account B or customer B.
2. Provisioning of policy creation limits, e.g. AWS IAM limits.

As can be seen, a good grouping strategy will result in better policy evaluation performance.

from vakt.

Yes, absolutely agree with you. Grouping will let us shard the data-set for a small query scope which will result in much better performance.
I've already thought about it, but in a little bit different context: I was thinking of creating an AuthZ server that uses vakt underneath and exposes a convenient API (REST, gRPC, etc.) for managing policies and checking policy enforcement. So I thought about this "sharding" of policies for various users, tenants, etc.
So, it's a good idea to think in terms of adding this group functionality in core vakt. Let's keep this in mind.

from vakt.