Remove unnecessary validation of WAF bundle filepaths used in apBundle
and apLogBundle
fields of waf Policy
#6641
Labels
proposal
An issue that proposes a feature request
Is your feature request related to a problem? Please describe.
As a user with many different WAF policies being defined using pre-compiled bundles, I want to be able to keep my various bundle files that I manage well-organized.
For example, I have several different Virtual Servers, and many different routes. Some of these routes are used for gRPC traffic, which require their own
grpc-profiles
in the WAF policies, while others may have specific signatures and bot policies. There is also the need to be able to provide new versions as we pick up the latest attack signatures & threat campaigns, or need to compile new versions for a NIC upgrade that has a new WAF engine version.These result in bundles that we'd like to organize in a logical filesystem hierarchy, a la
/etc/nginx/waf/bundles/version/server/route/policy.tgz
. Or to put in more concrete examples:/etc/nginx/waf/bundles/3.6.2-11.48.0/cafe/coffee/blocking.tgz
,/etc/nginx/waf/bundles/3.7.0-11.133.0/cafe/tea/transparent.tgz
, etc. (whereapBundle: "3.6.2-11.48.0/cafe/coffee/blocking.tgz"
Unfortunately, this would result in a validation error:
Describe the solution you'd like
Given that this
apBundle
andapLogBundle
are supposed to be filepaths, ideally the validation would only consist of confirming the file does exist and is readable. The use of k8s "Qualified Name" validation on these fields is restrictive to managing many bundle files in a logical way, and doesn't make sense to do for filepaths (qualified names are for k8s resource references, as I understand it).Describe alternatives you've considered
Because the "Qualified Name" validation allows a
dir/file
pattern (simply by coincidence) I can organize bundle files in a single nested directory, eg.cafe-policies/coffee-blocking-11.48.0.tgz
is allowed, and works just fine.I can also make really complex file names and dump ALL policy bundles and log bundles into a single directory (this seems to be the suggested methodology) but then it makes management of these bundles unnecessarily difficult.
Additional context
The text was updated successfully, but these errors were encountered: