fuzz testing of KubeArmor

[nyrahul]

Feature Request

Short Description

KubeArmor is a security tool and thus security testing of KubeArmor itself is important/imperative.

Fuzz testing involves testing all/most combinations of external inputs to the subsystem. For example, KubeArmor policies are provided by the users and thus might have unwanted effects if the policies are incorrectly formed. The intention of the fuzz testing is to ensure that appropriate input set is derived by the test tool (Google's oss-fuzz is popular) and provided as input to KubeArmor. The execution is then profiled (either using pprof/other tools) to check for any anomalies and unwanted side effects of the execution.

Tasks:

• [ ] Identify/Prototype the fuzz testing tool to use (oss-fuzz, AFL are some popular choices)
• [ ] Generate input set that will guide the fuzz testing tool
• [ ] Identify a way to profile KubeArmor during execution (possibly using pprof + ...?)
• [ ] Identify components that will be fuzz tested. For example:
  • KubeArmor policy controller
  • KubeArmor operator
  • KubeArmor configmap handler
  • KubeArmor GRPC endpoints.
• [ ] Document the whole process to ensure repeatability for future versions
• [ ] Automation strategy for fuzz testing

[mastersans]

@DelusionalOptimist I'll more research regarding all the possible components of the project that would benefits with fuzzing and will share my findings.

[DelusionalOptimist]

Thanks @mastersans. Was great to know about your experience with fuzz testing in the community call. Looking forward to you findings!

[nyrahul]

@DelusionalOptimist I'll more research regarding all the possible components of the project that would benefits with fuzzing and will share my findings.

This would be amazing to get it done! Fuzzing is an interesting topic. One good reference is Cilium fuzzing audit report.

A good first step would be to simply use go fuzzing with KubeArmor ginkgo testsuites.

[mastersans]

@DelusionalOptimist I wanted to ask that the kubearmor configmap handler referred here, is it referred to THIS FUNCTION. ?

[DelusionalOptimist]

This function is the one where KubeArmor reads the configmap data - https://github.com/kubearmor/KubeArmor/blob/a5f584c38ee7cd674d1e95a3f7ce7842212dfe12/KubeArmor/core/kubeUpdate.go#L2361

[prady0t]

Here is a workflow example of how we can proceed :

• Finding fuzz targets: These are the functions whose input needs to be fuzz tested. For example here : https://github.com/kubearmor/KubeArmor/blob/a5f584c38ee7cd674d1e95a3f7ce7842212dfe12/KubeArmor/policy/policy.go#L24 (This could be a wrong/not-so-helpful example, I'm new to KubeArmor) We can fuzz test ContainerPolicy for different values of data taking valid json structures as initial values (seed corpus).
• Writing fuzzers: Once we know the fuzz target, we can write a fuzzer for it. Initial seed corpus values can be given according to the function definition.
• Check locally if they work.
• Integrate with OSS fuzz : OSS fuzz basically runs the fuzzer continoulsy until it finds an error, which is then reported. For setting up Kubearmor on OSS fuzz, we need to create a folder for Kubearmor inside projects directory. We can see a vast number of projects already using oss-fuzz here. This folder has essentially two files: a) A Dockerfile : to define the Docker image that OSS-Fuzz will use to build and run your fuzz targets, b) project.yaml : file to define the project configuration for OSS-Fuzz. Once we have our PR merged (on oss-fuzz repo) oss-fuzz will run the fuzzers (which are available) continously. For future additions of fuzzers, we will just have to modify the files accordingly such that they are discoverable by oss-fuzz. Any reported bug can then be fixed.

We can start by finding functions whose fuzz testing can potentially find vulnerabilities. We can look at the Cilium report (mentioned above) to find such functions in the Cilium repo and look for similar (if any) functions in KubeArmor.

[nyrahul]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

[prady0t]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

Do you think the function I mentioned above is a good one to write a fuzzer for?

[nyrahul]

@prady0t This makes complete sense to me! Automation using OSS Fuzz can be tried later once we have a single fucntion fuzz tested. Thanks

Do you think the function I mentioned above is a good one to write a fuzzer for?

KubeArmor receives external input in following ways:

1. Policy {ContainerPolicy, HostPolicy, GlobalPolicy}
2. ConfigMap
3. GRPC

It is best we start with any of these and your proposal to start with ContainerPolicy makes sense to me.