fix: over-restrictive validation of wildcard match patterns

[bencouture]

What this PR does / why we need it:

validating regex update

The regex used for field validation in the CRDs for wildcard match patterns is:
^(\*|\*-)?[a-z0-9]([-:a-z0-9]*[a-z0-9])?(\*|-\*)?$

It looks to me like this is pretty much just the same regex that the Kubernetes apimachinery package uses for validating resource names, just with (\*|\*-)? tacked on the front and (\*|-\*)? tacked on the end.

Apimachinery regex:
const dns1123LabelFmt string = "[a-z0-9]([-a-z0-9]*[a-z0-9])?"
https://github.com/kubernetes/kubernetes/blob/466d9378dbb0a185df9680657f5cd96d5e5aab57/staging/src/k8s.io/apimachinery/pkg/util/validation/validation.go#L177

The problem is that that regex is designed to validate a full, valid resource name, but by definition a wildcard match only includes a partial resource name. So the validating regex is saying "you must provide a valid DNS name with an optional wildcard symbol at the beginning or end" when what should really be expected is "you must provide a partial valid DNS name". The validation should just check that no invalid characters are supplied, but other than that I don't think it should restrict the value.

As a specific example of how the regex is over-restrictive, dns1123 allows multiple hyphens in a row. unusual--------name is a valid resource name, and Kubernetes will accept that. If I try to use Gatekeeper to match on *--*, the Gatekeeper resource is rejected for failed field validation, even though it's still a perfectly valid wildcard match.

field documentation update

I just updated the language explaining the match fields to explicitly say that you can use a prefix and suffix match at the same time. That wasn't initially clear to me from the existing documentation.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged): none
Fixes #

Special notes for your reviewer:

The regex has a colon (:) in it as a valid character. Does anybody know why? That's not actually a valid DNS1123 character, according to the RFC, and Kubernetes rejects resources with a : in the name. I initially was going to remove it, but was concerned that it might be for some edge case I'm not aware of. The test suite still passed when I removed it, so there aren't any tests that rely on it. I would propose removing it if nobody can think of a reason why it's there.

[maxsmythe]

1 small comment about tests

[maxsmythe]

Is there a reason tests were removed? Pre-existing tests should still pass with this change?

[maxsmythe]

Thanks for the PR!

It looks like : was added to support cluster role names: #2797

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.31%. Comparing base (3350319) to head (7b4b023).
Report is 37 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3310      +/-   ##
==========================================
- Coverage   54.49%   54.31%   -0.18%     
==========================================
  Files         134      134              
  Lines       12329    10258    -2071     
==========================================
- Hits         6719     5572    -1147     
+ Misses       5116     4180     -936     
- Partials      494      506      +12     

Flag	Coverage Δ
unittests	54.31% <ø> (-0.18%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maxsmythe]

LGTM, thanks for the PR!

[ritazh]

LGTM

Thanks for the PR!