Should match.resources.kinds be required?

[realshuting]

Is your feature request related to a problem? Please describe.
With Kyverno v1.3.4, match.resources.kinds is optional while match.resources is required:

kyverno/pkg/api/kyverno/v1/policy_types.go

Lines 258 to 259 in 592394d

	// +optional
	Kinds []string `json:"kinds,omitempty" yaml:"kinds,omitempty"`

kyverno/pkg/api/kyverno/v1/policy_types.go

Lines 71 to 75 in 592394d

	// MatchResources defines when this policy rule should be applied. The match
	// criteria can include resource information (e.g. kind, name, namespace, labels)
	// and admission review request information like the user name or role.
	// At least one kind is required.
	MatchResources MatchResources `json:"match,omitempty" yaml:"match,omitempty"`

This is different from what we have on the website:

At least one element must be specified in a match or exclude block. The kind attribute is optional when working with the resources element, but if it’s not specified the policy rule will only be applicable to metadata that is common across all resource kinds.

Describe the solution you'd like
In most cases, match.resources.kinds is used to apply rules. With this, it seems okay to define this field as required. In case one wants to apply policy to metadata across all types of resources, we can allow any "*" in kinds.

Would like to get thoughts and feedback first on this issue, and then we can finalize and document the expected behaviors.

[chipzoller]

Supporting a wildcard (*) for match.resources.kinds seems like a good idea if users only want to work with metadata. So making it required but supporting either explicit kinds of * seems like a good approach. Curious to know other perspectives and what alternatives might be.

[realshuting]

I should've explained it in the description.

The reason for this change is that we can build an internal cache of the matched kinds for a fast lookup during admission review. In this issue, the user had to specify a long exclude list to reduce CPU usage, which was a pain. I came up with a solution to add the matched list, but it seems like we can build this list from the defined policies directly. Having kinds as required makes it consistent (with an exception "*"), it informs the user that the rule must match at least one kind to apply.