Filtering: when the target value is `*` it should be a `true-bypass`

[ncounter]

Example:

Policy A has RESOURCES: * Policy B has RESOURCES: Pod Policy C has RESOURCES: * Policy D has RESOURCES: Ingress

Case 1: Filtering by RESOURCES with the value Pod: what is the expected filtered result? Proposal: Policy A, B and C are listed because Policy B contains Pod and Policy A and C are for all therefore for Pod.

Case 2: Filtering by RESOURCES with the value *: what is the expected filtered result? Proposal 1: disable filtering by the value * Proposal 2: only Policy A and C are listed as they are valid policies for all the resources

@flavio do you agree? Especially in Case 2, what is the best solution from your POV?

[flavio]

@ereslibre the safe-labels policy can be used against any kind of Kubernetes resource. This is the first policy we have that can do that.

The policy-hub metadata requires us to specify the resources this policy can target. I didn't know what to put in there and I ended up using the * symbol.

Now that causes some issues when filtering policies. Do you think we should stick with the * symbol or is there something better suited?

[ereslibre]

I think it would make sense to stick with '*' when a policy can target any resource. This matches the way configuration is provided to Kubernetes, so it's somewhat familiar to users.

I would be in favour of doing something like the following:

The Web interface allows to filter with the following rules:

• I can introduce a set of resources: Pod, Namespace, would list policies that act specifically on Pod and Namespaces, as well as policies indirectly acting upon them; those with * as the resource.
• I can introduce a specific resource called any (that looks different in the interface) in the search field (or a check box called Any -- that could disable the search field for Resource for example). This would list policies acting literally on any resource.
• I can introduce * as a criteria, that would match policies matching * strictly -- I can discover policies that.

By having a specific search criteria any the user can provide, we allow them to specifically search for *, matching only resources that act on any resource, so that target * exclusively.

What do you think?

[flavio]

• I can introduce a set of resources: Pod, Namespace, would list policies that act specifically on Pod and Namespaces, as well as policies indirectly acting upon them; those with * as the resource.

I like it

• I can introduce a specific resource called any (that looks different in the interface) in the search field (or a check box called Any -- that could disable the search field for Resource for example). This would list policies acting literally on any resource.

I like the idea of using any. I'm also fine with the UX ideas, but I leave to @ncounter to last word on that.

• I can introduce * as a criteria, that would match policies matching * strictly -- I can discover policies that.

Fine, only if that doesn't make @ncounter's life harder. I don't know how many policies are going to be so generic