Intro
This vulnerability makes for two new vulnerabilities in the third party Kubernetes ecosystem this month, including the recent Rancher vulnerability. This vulnerability is unique in that it impacts the security ecosystem for Kubernetes; specifically in Kyverno, a popular Kubernetes Security admission controller. Though the vulnerability is rated as Medium, the popularity of Kyverno and the difficulty of making the critical update needed to resolve the issue warrants a closer look.
What is Kyverno in Kubernetes Security?
Kyverno is a popular policy engine for Kubernetes, offering admission control. It is viewed broadly as one of the primary options for security policies in Kubernetes, with competing offerings including Open Policy Agent (OPA) and jsPolicy. Generally, it is one of the easier admission controllers to use because it doesn’t require learning Rego. That being said, it doesn’t allow for the de-coupling of policies from Kubernetes resources themselves, so it is a little less flexible for writing and using admission control policies at scale or even earlier in CI/CD pipeline. Kyverno has four thousand stars on Github and is a Cloud Native Computing Foundation (CNCF) incubating project.
How does CVE-2023-34091 work?
Under certain circumstances, the vulnerability, which is rated Medium, makes it possible to circumvent a Kyverno admission control policy. The way Kyverno has been set up was in such a way that Kubernetes resources that were going to be deleted were not included in the list of resources to validate policy against, to try and improve performance.
In this vulnerability though, resources with the deletionTimestamp field defined were able to bypass any policy, even when the policy was set to enforce mode. If somebody used a Kubernetes finalizer to set the timestamp without deleting the resource, they could bypass the admission control policy.
Notably, this particular vulnerability does not affect policies on pods, primarily because after the deletion process begins, there’s no way to update the process; the pod will continue to termination. The vulnerability works instead on a Kubernetes service, where you are able to add a finalizer without deleting the resource, then make changes to the service that go against policy. See this blog for a refresher on the Kubernetes deployment lifecycle.
What can you do?
V1.10 was recently released and includes a fix for the issue, but it’s worth mentioning that this version causes breaking changes. There is manual work required when doing the deployment via Helm, and zero upgrade path from previous versions when using YAML manifests. As such, as part of the migration, you will have to figure out how to save your Kyverno policies and bring them back in.
How KSOC can help
With KSOC, you would be taking advantage of an OPA-compatible admission controller. KSOC would take care of any critical updates, mitigating any breaking changes described above in the migration process. If, hypothetically, there was a similar vulnerability in OPA, KSOC’s real-time Kubernetes Security Posture Management (KSPM) capabilities would show any malicious exploitation attempts. You would have historical context of everything that happened, ensuring a quick and speedy response and recovery.
Conclusion
The Kubernetes ecosystem is broad, so it makes sense that vulnerabilities in the Kubernetes ecosystem are more and more frequent. As such, it is absolutely essential to have a solution that can detect exploitation attempts in real-time, allowing you to respond quickly and prevent any damage. This is the first vulnerability we have seen this year in a Kubernetes security tool. For a summary of the vulnerabilities in Kubernetes and the Kubernetes ecosystem up to the first half of 2023, download the whitepaper.
