Introduce WAF in guard-gate

[jcchavezs]

Currently we don't have any sort of web application WAF in guard-gate and without this we miss some features:

1. injection prevention
2. virtual patching
3. payload inspection

we could implement WAF with @corazawaf as it is also in Go. I would be up for a PR.

[davidhadas]

Hi jcchavezs, Welcome

The overall direction of identifying functionality that WAFs typically use and considering using it as part of Guard is a positive one and we will gladly endorse any such functionality if it proved to be suitable to protect Microservice Pods and adds to the protection Guard already offers.

However, we need to recognize two main aspects:

1. Guard is not a WAF and does not try to replace a WAF - this does not mean that functionality common in WAFs has no place in Guard, it just means that each function needs to be reviewed and considered face value

   • Do we need it in front of every Pod?
   • Do we gain from placing it in each Pod vs placing it in at the ingress, etc.

2. Guard is very much tuned into improving security operations - This means that when we consider adding a function, we ask if it can be useful without any configuration/rules being set by DevOps. It is ok, if under certain conditions (when there is a CVE for example), rules will be required to improve security - but we do aim to offer "out-of-the-box" security even without human-created rules. To do that, we often look into options for creating the rules with ML (but this is not a must).

Please try to analyze the functionality you wish to add in view of these two aspects. Maybe best if we create a document to start discussing this - I do ask that we separate each functionality that we want to add and consider these aspects first, then understand the planned design and only then move to PR. I created a feature track document for this (we normally use it as a template to organize the information we gather about a proposal and discuss).

cc: @evankanderson, @nainaz

[evankanderson]

+1 to minimal configuration, or to making it easy to layer WAF into the ingress path before the queue-proxy. It looks like the Gateway API may be reaching a sufficiently-supported stage that looking at the policy extension options in that API might make sense as an alternative to embedding a WAF and WAF configuration inside guard.

In particular, because of where it lives, the path for steering complex configuration like virtual patching into guard is not entirely clear. (guard already does some payload inspection, so that might be a good place to start?)

[davidhadas]

+1 to minimal configuration, or to making it easy to layer WAF into the ingress path before the queue-proxy. It looks like the Gateway API may be reaching a sufficiently-supported stage that looking at the policy extension options in that API might make sense as an alternative to embedding a WAF and WAF configuration inside guard.

In particular, because of where it lives, the path for steering complex configuration like virtual patching into guard is not entirely clear.

Let's shed more light on this topic - Guard does implement a per-service configuration which we call Guardian. Guardian is a CRD Object that includes the service "micro-rules". These micro-rules can be learned with ML but users also have the ability to adapt them manually. Guardian also includes a per-service configuration such as:

• Do we want to continue learning?
  • Do we want to use the learned set of rues or the manually configured one?
  • Do we want to block traffic when alerts are raised or not?

What @evankanderson seek to highlight is that the boot sequence of Guard is presently limited such that we do not have a good way to pass too many config parameters on boot (this is the result of some limitations on how Guard and Queue-Proxy interact).

virtual patching can be configured into a Guardian or instead, we could have a per-service configuration in Guardian that indicates that a virtual patch exists and be fetched from some location.

In principle, I believe placing virtual patching in Guard can be a nice fit. Note that for most microservices, we will have no patch - this is in-line with Guard's "out-of-the-box" protection. However, it does empower the users to add a patch as a last resort when other defenses fail.

(guard already does some payload inspection, so that might be a good place to start?)

That is correct - we need to better understand what is offered in the area of payload inspection and injection prevention and to see if this is not already covered by the existing protection offered by Guard. Since we already have a given level of protection in this area, we need to identify attacks that Guard does not protect from, and then consider the right path forward.

[jcchavezs]

Thanks for the careful feedback.

First of all, most of the WAF solutions offer coreruleset support which means we might not need configuration as we can leverage CRS under a low paranoia level or even better careful chose a default subset of it that can be leverage in every sidecar. I still believe per sidecar makes sense as an attacker can aim to exploit vulnerabilities from a compromised host to the entire cluster. Virtual patching can be achieved by CRS by the way.

As for injection prevention we could leverage a small validator for injection using https://github.com/corazawaf/libinjection-go inside the guard. This will not require config and it is pretty standard.

As for Gateway API, main issue here is that there is no (and I think there won't be) a way to uniformly extend the Gateway. Different implementations might chose their own plugin system and that is not only a huge friction but sometimes even if the implementation API allows it, the implementation might not be as performant as we would like to.

[davidhadas]

@jcchavezs Would you be able to describe each WAF feature you seek to add separately in https://docs.google.com/document/d/1Q2UnKJ99YG_LNSQTc2PTAmM1HGH0Ctvc-bc9a43p3-8/edit#,

Maybe best to start by describing one feature first. I can suggest "virtual patching" since from where I stand it looks like a good match to Guard to cover more sophisticated filtering that can't be achieved by Guard's Microrules.

For each feature, try to analyze (I will help with this analysis based on what you will write):

1. Why it would make sense to have it in a per-pod gate
2. How can it work out of the box and provide basic common protection
3. What additional configurations will it add for DevOps (or DevSecOps) and when will they need to be configured (examples will be useful)
4. What is the interplay it has with what Guard already does (what does it cover that the existing technology does not) - I will defiantly help you with this one :)
5. The design we should have (e.g. should it block before or after other mechanisms)
6. If you rely on existing code or library point to it, please.

[jcchavezs]

Thanks for the detailed request. I will definitively go through it.

On Wed, 10 May 2023, 08:50 David Hadas, @.***> wrote:

@jcchavezs https://github.com/jcchavezs Would you be able to describe each WAF feature you seek to add separately in https://docs.google.com/document/d/1Q2UnKJ99YG_LNSQTc2PTAmM1HGH0Ctvc-bc9a43p3-8/edit# ,

Maybe best to start by describing one feature first. I can suggest "virtual patching" since from where I stand it looks like a good match to Guard to cover more sophisticated filtering that can't be achieved by Guard's Microrules.

For each feature, try to analyze (I will help with this analysis based on what you will write):

1. Why it would make sense to have it in a per-pod gate
2. How can it work out of the box and provide basic common protection
3. What additional configurations will it add for DevOps (or DevSecOps) and will they need to be configured (examples will be useful)
4. What is the interplay it has with what Guard already does (what does it cover that the existing technology does not) - I will defiantly help you with this one :)
5. The design we should have (e.g. should it block before or after other mechanisms)
6. If you rely on existing code or library point to it, please.

— Reply to this email directly, view it on GitHub https://github.com/knative-sandbox/security-guard/issues/205#issuecomment-1541443841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXOYATCALP3CILYKE7BKQ3XFM3D3ANCNFSM6AAAAAAXXAPY5Q . You are receiving this because you were mentioned.Message ID: @.***>

[jcchavezs]

I just filled the document, I am up for feedback! https://docs.google.com/document/d/1Q2UnKJ99YG_LNSQTc2PTAmM1HGH0Ctvc-bc9a43p3-8/edit#

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.