Kubernetes Looks Inside and Finds Security Holes
The Kubernetes ecosystem took a look in the security mirror and found it has some work to do in order to ensure a better security posture for the container orchestration platform. The move comes as a rash of Kubernetes security flaws have cropped up over the past eight months.
The introspective look came via the first security audit of Kubernetes conducted by the Cloud Native Computing Foundation (CNCF), which hosts the open source platform. The audit itself was conducted by Trail of Bits and Atredis Partners, and was focused on eight components within the Kubernetes ecosystem.
That internal look found 37 vulnerability issues with the 1.13.4 iteration of Kubernetes. These included five high-severity issues and 17 medium-severity issues. Fixes for those issues have already been deployed.
The audit found a number of Kubernetes-wide issues. These included policies that may not be applied and that can lead to a false sense of security; insecure transport layer security (TLS) being used by default; credentials being exposed in unsecure environments; names of secrets being leaked in logs; a lack of certificate revocation; and seccomp, which filters a process’s systems calls, not being enabled by default.
The overall size and operational complexity of Kubernetes was cited as being a key reason for these security holes.
“The assessment team found configuration and deployment of Kubernetes to be non-trivial, with certain components having confusing default settings, missing operational controls, and implicitly defined security controls,” the audit explained.
It also found that the extensive Kubernetes codebase lacks detailed documentation to guide administrators and developers in setting up a robust security posture.
“The codebase is large and complex, with large sections of code containing minimal documentation and numerous dependencies, including systems external to Kubernetes,” the audit noted. “There are many cases of logic re-implementation within the codebase, which could be centralized into supporting libraries to reduce complexity, facilitate easier patching, and reduce the burden of documentation across disparate areas of the codebase.”
Despite those concerns, the audit did find that Kubernetes does streamline “difficult tasks related to maintaining and operating cluster workloads such as deployments, replication, and storage management.” The use of role-based access controls (RBAC) also allows users an avenue to increase security.
“Continued development of these security features and further refinement of best practices and sane defaults will lead the Kubernetes project towards a secure-by-default configuration,” the audit found.
The audit recommended a handful of steps to better secure Kubernetes-based environments. For administrators it recommended a greater focus on attribute-based access controls instead of RBAC; implementation of RBAC best practices; and the use of default settings and backwards compatibility. For developers, the audit recommended avoiding hardcoding paths to dependencies; checking file permissions; and monitoring processes on Linux.
Part of the Process
CNCF CTO Chris Aniszczyk said that the audit and findings are an important part of the open source community. He explained that the organization has a requirement in place that all projects go through a security audit when they graduate. However, that requirement was still in a pilot phase when Kubernetes was the first project to be handed its CNCF diploma early last year. Aniszczyk also noted that the openness of the Kubernetes audit process added to the timeline.
While the security issues are not being taken lightly, Aniszczyk said that it was notable how quickly the community – across vendors – developed fixes to the issues.
“Software that’s as complex and as extensive as Kubernetes is bound to have vulnerabilities,” wrote Rani Osnat, vice president of product marketing at Aqua Security, in an email to SDxCentral. “Taking the initiative to perform an extensive third-party security audit … is absolutely the right thing to do in order to get ahead of having those vulnerabilities exposed ‘in the wild.’”
While CNCF took the lead on the audit process, Aniszczyk explained that it was not really up to the organization to take the lead on mandating the security posture of projects like Kubernetes.
“It’s not necessarily the role of the community to ship out all of the latest security fixes, that’s really the role of the member companies to do,” Aniszczyk said. “But we do want to provide the knobs to make that easier.”
He did add that CNCF has recently set up a new security group that will look to drive audit recommendations back into the organization’s projects. And that the community was moving to beef up security options in upcoming Kubernetes releases.
CNCF is also weighing the merits of a bug bounty program for its projects. Aniszczyk said that such projects have become increasingly popular and often provide “interesting results.”
The audit comes at an important time for the Kubernetes ecosystem, which has discovered a handful of security bugs over the past 8 months. The most pressing was one discovered late last year, which scored an impressive 9.8 (critical) score out of 10 on the Common Vulnerability Scoring System (CVSS).
Since then, other flaws have been uncovered, including one earlier this week that has been hounding the space for several months.
The community itself has repeatedly stated that such flaws are to be expected and that the main focus should be on how quickly it can send out updates.
“While many observers will emphasize the number and severity of vulnerabilities that were reported, that focus misses the forest for the trees,” explained Wei Lien Dang, co-founder and head of product for security firm StackRox, in an email to SDxCentral. “This audit provides value far more broad and critical than identifying additional vulnerabilities. Such vulnerabilities will keep surfacing – with or without this audit, given the combination of the rich code base with such broad, rapid adoption.”