KSOC Adds Tools to Strengthen Kubernetes Security
Kubernetes Security Operations Center (KSOC) this week made generally available a zero-trust policy generator to make it simpler to manage role-based access control (RBAC) for Kubernetes clusters.
At the same time, KSOC has added support for Kubernetes Custom Resources to its Kubernetes security posture management platform and is making available a GitHub application to make it simpler to integrate its platform within the context of a DevOps workflow.
Finally, KSOC can now track the usage of curated container images provided by Chainguard to help ensure IT teams are embracing DevSecOps best practices when building and deploying cloud-native applications.
KSOC CTO Jimmy Mesta said managing RBAC in Kubernetes environments has been a thorny issue because there has been no way to effectively prevent over-permissioning. As a result, it’s too easy for cybercriminals that gain access to credentials to escalate privileges, he added. Once those privileges are gained, many cybercriminals will, rather than immediately launching an attack, now study workflows and processes for weeks to enable them to launch an even more lethal attack.
The KSOC zero-trust policy generator addresses that issue by automatically creating least-privilege recommendations and surfacing insights into malicious identities discovered by the KSOC identity threat detection and response (ITDR) platform.
In general, Kubernetes platforms are being increasingly targeted in part because more cybercriminals are using the platform to build their malware, said Mesta. The experience and insights they gain as a result are then being used to identify cybersecurity weaknesses in Kubernetes environments, he added.
The challenge is that, as IT platforms go, Kubernetes is unique, which requires organizations to embrace a set of cybersecurity best practices that are specific to Kubernetes environments. It’s also essential to stay current on the latest versions of Kubernetes as more vulnerabilities are discovered. Now that Kubernetes clusters are being deployed in enterprise IT environments, they are attracting more attention from cybersecurity researchers.
Unfortunately, much of that research is also closely read by cybercriminals looking to exploit vulnerabilities in clusters that have not been updated to remediate a known issue. The issue, of course, is that many IT teams are reluctant to update Kubernetes clusters for fear of breaking an application. However, as cyberattacks continue to increase in both volume and sophistication, the risk of, for example, a ransomware attack that exploits a Kubernetes vulnerability is starting to outweigh the potential disruption that might result from application downtime.
The challenge, as always, is that it’s still not always clear who within organizations is responsible for Kubernetes security. In theory, the same team responsible for securing IT infrastructure should also ensure Kubernetes security. However, many of those teams still lack Kubernetes expertise. Developers that often provision Kubernetes clusters themselves similarly lack Kubernetes security knowledge, and few existing cybersecurity teams have any familiarity with the platform.
As a result, it should not come as a surprise there are Kubernetes security incidents. The issue now is finding a way to put the best tools and processes in place to make sure the number of incidents that might occur in the future are minimized as much as possible.
