Closed StraysWonderland closed 1 month ago
Can we modify the policy to support both CAP_NET_RAW and NET_RAW capabilities instead of omiting CAP prefix
that would be an option. However; My concern is that when specifying CAP_NET_RAW on your kubernetes resources, the pod still has the capabilities that should be dropped. So while kyverno will say that all is fine and secure; the pod is still vulnerable to i.e. spoofing attacks as pods still have access to the NET_RAW capabilities.
My tests indicate that behaviour but I think ideally someone would need to confirm my suspicion to be sure about this. If my suspicion is incorrect then allowing both is a suitable solution I believe
I have seen in some deployment manifests CAP_NET_RAW is used. It might be Operating system specific. For now, good option is to allow both CAP_NET_RAW and NET_RAW.
The changes are done and tested. will be submitting the pull request shortly.
PR is submitted https://github.com/kyverno/policies/pull/1168
Kyverno Version
1.11
Kubernetes Version
1.26
Kubernetes Platform
EKS
Description
We have implemented a subset of the best practices policies on our aks cluster. The issue I'm facing is related to the require-drop-cap-net-raw policy which can be found here within the kyverno policies repository
However this policy does only recognize a pod as passing the policy if the capability section is defined as:
so with the CAP prefix
According to the official kubernetes documentation however, these capabilities should omit the CAP prefix as can be seen here:
And the problem is that kyverno does not seem to recognize resources dropping the capabilities in this manner:
Ive done a bit of testing on some pods and it seems that pods with the CAP_NET_RAW definition, tough passing the kyverno policy, are not actually dropping the security capabilities while pods with the NET_RAW definition fail kyverno but are correctly dropping the security capability.
Ive also visualised how kyverno fails/passes these different definitions in the kyverno playground via this test using the official kyverno policy and two pods with the different capability syntax.
And the playground test also shows that CAP_NET_RAW is passing while NET_RAW is failing
Steps to reproduce
Expected behavior
Kyverno should allow the 2nd pod with NET_RAW syntax as according to kubernetes this is the correct way to drop the capability. And likely not accept the CAP_NET_RAW definition as this does not actually seem to achieve what it should within the container.
Screenshots
No response
Kyverno logs
No response
Slack discussion
No response
Troubleshooting