CNCF Open Sources Security Audit of Core Kubernetes Components
This week, the Cloud Native Computing Foundation (CNCF) has released the final results of a two-month-long, third-party security audit of eight core Kubernetes components, uncovering a variety of vulnerabilities.
CVEs have already been created for the vulnerabilities, which have been addressed already, according to the CNCF. In addition, the analysis found a number of issues found in many Kubernetes deployments, including:
- Policies may not be applied, leading to a false sense of security.
- Insecure TLS is in use by default.
- Most components accept inbound HTTP.
- Most components do not enforce outbound HTTPS.
- Credentials are exposed in environment variables and command-line arguments.
- Names of secrets are leaked in logs.
- No certificate revocation.
- seccomp is not enabled by default.
The process originated last year with audits of the CoreDNS service discovery software, the Envoy proxy and Prometheus monitoring tool, before the foundation turned its attention to Kubernetes itself with the creation of the Security Audit Working Group to lead the process. After receiving proposals from six independent vendors, two teamed up to perform the security audits and create the resultant report, which will be fully available in the working group’s GitHub repository, as are full details of the process thus far — a point that the Cloud Native Computing Foundation Chief Technology Officer and Chief Operating Officer Chris Aniszczyk points to as one of differentiation.
“I don’t think there are many security audits out there that are done in an open community way. It was an open RFP with a Kubernetes governance structure behind it with a working group. We’re open sourcing all the results and the paper, which generally doesn’t happen with security audits,” said Aniszczyk. “The beauty of doing these audits for open source projects is you get to benchmark and test how the security disclosure process worked, and it worked fairly well. CVEs were created for a lot of the high severity issues that were found in Kubernetes.”
Indeed, the entire process is visible in the Security Audit Working Group repository, including the RFP, the RFP decision process, and the accepted proposal from Atredis and Trail of Bits, which were chosen to perform the audit. The components audited in this process included kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager, kubelet, kube-proxy and container runtime, according to a CNCF blog post. These components were chosen as being core to the control plane of Kubernetes across six aspects — networking, cryptography, authentication, authorization, secrets management and multitenancy.
In addition to finding numerous vulnerabilities, the security audits resulted in a number of recommendations for both Kubernetes developers and cluster administrators. Aniszczyk compared some of the recommendations to those you might expect compiling Linux from scratch, as compared to using a hardened version provided by a vendor. For example, Kubernetes developers are advised to check file permissions and avoid hard-coding dependencies, while cluster administrators should pay attention to role-based access control (RBAC) best practices and node-host configurations and permissions, among other issues.
These security audits were partially inspired by the Core Infrastructure Initiative (CII) Best Practices Badge program, which is required of all CNCF members and is meant to show that projects are following best security practices, according to the CNCF blog post. Moving forward, the CNCF will offer security audits to its other projects, with preference given to graduated projects, although Aniszczyk says there is no prescribed process.
“The way the audit process works in CNCF is projects get to request it when they want it essentially. We don’t dictate that they must get audits on an annual basis. All we dictate is that any project that becomes a graduated CNCF project must go through an independent security audit and open source the results,” said Aniszczyk. “I envision something like this maybe happening on a once every couple of years, but it’s really for the security audit working group to come up with a decision since they’re the experts.”
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature image by David Mark from Pixabay.
