The Cloud Native Computing Foundation (CNCF) today released a security audit of Kubernetes, the widely used container orchestration software, and the findings are about what you’d expect for a project with about two million lines of code: there are plenty of flaws that need to be addressed.
The CNCF engaged two security firms, Trail of Bits and Atredis Partners, to poke around Kubernetes code over the course of four months. The companies looked at Kubernetes components involved in networking, cryptography, authentication, authorization, secrets management, and multi-tenancy.
Having identified 34 vulnerabilities – 4 high severity, 15 medium severity, 8 low severity and 7 informational severity – the Trail of Bits report advises project developers to rely more on standard libraries, to avoid custom parsers and specialized configuration systems, to choose “sane defaults,” and to ensure correct filesystem and kernel interactions prior to performing operations.
“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 designed security controls,” the Trail of Bits report revealed. “Also, the state of the Kubernetes codebase has significant room for improvement.”
Underscoring these findings, Kubernetes 1.13.9, 1.14.5, and 1.15.2 were released on Monday to fix two security issues in the software, CVE-2019-11247 and CVE-2019-11249. The former could allow a user in one namespace to access a resource scoped to a cluster. The latter could allow a malicious container to create or replace a file on the client computer when the client employs the kubectl cp command.
As noted by the CNCF, the security auditors found: policy application inconsistencies, which prompt a false sense of security; insecure TLS used by default; environmental variables and command-line arguments that reveal credentials; secrets leaked in logs; no support for certificate revocation, and seccomp (a system-call filtering mechanism in the Linux kernel) not activated by default.
The findings include advice to cluster admins, such as not using both Role-Based Access Controls and Attribute-Based Access Controls because of the potential for inadvertent permission grants if one of these fails.
They also include various recommendations and best practices for developers to follow as they continue making contributions to Kubernetes.
For example, one recommendation is to avoid hardcoding file paths to dependencies. The report points to Kubernetes’ kublet process, “where a dependency on hardcoded paths for PID files led to a race condition which could allow an attacker to escalate privileges.”
The report also advises enforcing minimum files permissions, monitoring processes on Linux, and various other steps to make Kubernetes more secure.
In an email to The Register, Chris Aniszczyk, CTO and COO of CNCF, expressed satisfaction with the audit process. “We view it positively that the whole process of doing a security audit was handled transparently by the members of the Kubernetes Security Audit WG, from selecting a vendor to working with the upstream project,” he said. “I don’t know of any other open source organization that has shared and open sourced the whole process around a security audit and the results. Transparency builds trust in open source communities, especially around security.”
Asked how he’d characterize the risks present in Kubernetes at the moment, Aniszczyk said, “The Kubernetes developers responded quickly and created appropriate CVEs for critical issues. In the end, we would rather have the report speak for itself in terms of the findings and recommendations.”
Why is this good? Because these holes will be fixed instead of exploited.