waf integration fixes / improvements

[electricjesus]

Description

This PR changes how coreruleset rules are delivered as part of the WAF integration

• add unit testing for WAF render
• remove embedded coreruleset. this greatly reduces the size of the config map rendered by operator.
• leaving only one file available by default, tigera.conf
• change dikastes command line flags to use coraza's direct file loading api
• only reference coreruleset already installed in dikastes through a 'header' file (tigera.conf)
  • remove -waf-directive flags, swap with -waf-ruleset-file flag
  • remove -waf-ruleset-base-dir because DirFS didn't work as expected

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bugfix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[peterkellydev]

LGTM from WAF perspective and the changes we want to see with ruleset files.

[tmjd]

Could you explain a bit further about this?

change dikastes command line flags to use coraza's direct file loading api

Primarily I'm wondering if this has impact on clusters that don't have internet access.

Another way to ask what I'm curious about is, how does dikastes fetch the ruleset data that is being removed in this PR?

Another thing I'm curious about, does this change what happens during upgrades? I think before this PR the ruleset gets installed/cached and then with future updates the existing ruleset would be used (I'm not sure about this behavior but it would match the behavior I usually expect with the operator). My thinking is that now if dikastes is fetching this data (or it is builtin) then I would think the data could change/update when upgrading.

[electricjesus]

@tmjd sorry for the confusion, I typically call it API because it's an 'application programming interface' within the code.. not necessarily an API endpoint.

in this case I meant to say that it that just means that in dikastes we're just loading the file directly instead of using a Include <path-to-file> directive. e.g.:

from

-waf-directive "Include /etc/modsecurity-ruleset/tigera.conf"

to

-waf-ruleset-file /etc/modsecurity-ruleset/tigera.conf

• tigera.conf is still a file mounted via config map, then used in that CLI flag
• the rest of the core ruleset files are embedded within the dikastes binary, see here:
• nothing is loaded via internet access

[tmjd]

I discussed this a bit with @electricjesus and the intention is that when a user upgrades the ruleset will be updated along with the upgrade.

[tmjd]

LGTM