Support excluding some containers of pods from privileged check

[horecoli]

Overview

Kubescape supports some exceptions, but it is only possible at the level of pods. Since a pod can have more than one container, it would be useful to allow the exclusion of specific containers of pod from scan.

Problem

If your deployment workload resource definition (eg. helm) pulls in external upstream container images during runtime, those images may have Pod definitions with the privilege flag policy set to true for one or more their Pods. It is recommended that the CNF developer audits and cleans up any upstream images to respect this rule ensuring the privilege flag is set to false when following this best practice.
Some Pods may need privileges to provide required functionality. For example kube-proxy or the Envoy side-car.
It is the responsibility of the CNF developer to communicate the privileges needed by their CNF. Source ( https://github.com/lfn-cnti/bestpractices/blob/main/doc/cbpps/0004-do-not-run-containers-with-privilege-flag.md#notesconstraintscaveats ).

So, I believe it would be beneficial to allow the exclusion of specific containers from the privileged test.

Solution

To address this, the ability to add container types to the exception file can be implemented. This will allow the exclusion of those containers from the scan.

[RomanTheLegend]

What about applying labels to particular pods and/or containers and then specifying corresponding exception in Controls?

https://github.com/kubescape/kubescape/tree/master/examples/exceptions

[dwertent]

@horecoli The current exception handling in Kubescape is designed to be compatible with Kubernetes objects, which is why exceptions are supported at the pod level and higher, as the pod is the smallest unit of execution in Kubernetes.

When approaching compliance and security, it's important to differentiate between the two. From a compliance perspective, even if one of the containers in your pod needs to run as privileged, the workload is still non-compliant if the framework requires workloads to run as non-privileged. However, from a security standpoint, the focus should be on the behavior of each running container and its runtime behavior, as you suggested.

These aspects should be addressed separately, as many platforms, including ARMO, do. This is why the exceptions, which serve as a vehicle for compliance scanning, do not differentiate between containers.

[horecoli]

@dwertent So you think that this feature is not relevant and won't be accepted in Kubescape?

[dwertent]

Well, this is my opinion. @slashben , @yossi77 do you think otherwise?