CRD Vulnerability Cause for Kubernetes Concern

A CRD vulnerability is the latest in a slew of security issues impacting Kubernetes

A CVE-2019-11247 vulnerability disclosed this week that affects Kubernetes application programming interfaces (APIs)  highlights the need for organizations to focus on ensuring more than just the core of components of Kubernetes are secure.

The vulnerability compromises Kubernetes APIs in a way that might allow users to read, modify or delete customer resource definitions (CRDs) across an entire cluster when role-based access is enabled.

CRDs are employed to add extensions to Kubernetes through which third-party vendors add value on top of a Kubernetes cluster. Wei Lien Dang, vice president of product for StackRox, says organizations making use of such services need to be sure Kubernetes APIs and associated CRDs are as secure as the rest of the environment. It’s easy to assume the provider of the add-on technologies leveraging those APIs and CRDs has ensured they are secure when in fact they might not be, he says.

It’s not clear how many organizations are employing instances of Kubernetes that make use of CRDs. Dang says organizations will need to look at how various third-party tools they are using integrate with Kubernetes to understand the severity of the risk they might face.

The Cloud Native Computing Foundation (CNCF), which oversees the development of Kubernetes, earlier this week released the results of a security audit focused on the core Kubernetes modules, including the Kubernetes API server. However, the CRD vulnerability was not specifically addressed.

The easiest way to eliminate this issue is to upgrade the Kubernetes cluster to versions 1.13.9, 1.14.5, or 1.15.2, which include a fix to the problem. If upgrading is not an immediate option, IT teams will need check all the Roles in Kubernetes clusters to make sure none of them have “*” allowed for resources or apiGroups.

The bug covered by CVE-2019-11247 arises from incorrect handling of K8s API calls made for globally scoped custom resources. If the API endpoint is scoped with a namespace, the permissions are evaluated in the scope of that namespace, even though the resource is global. When making authenticated calls to the Kubernetes API server with a service account that has wildcards (“*”) in its Role definition and a RoleBinding in any namespace, it becomes possible to act on cluster-scoped resources by passing that namespace as the scope of the API call.

Despite what may feel like a rash of Kubernetes vulnerabilities being discovered lately, Dang says the rate at which cybersecurity issues are being discovered and addressed shows how much focus is now being placed on Kubernetes as more organizations start to deploy Kubernetes clusters in production environments. For example, the CNCF is in the early stages of rolling out a bug bounty program for Kubernetes. The fixes to those vulnerabilities may require sooner-than-planned upgrades to clusters. However, leaving those vulnerabilities unaddressed will not be an acceptable level of risk for most organizations.

In the meantime, Dang says IT teams would be well-advised to remember that Kubernetes is not a monolithic platform. Rather, it and the all the software deployed on top it create an environment made up of several layers of software that each need to be continuously monitored and secured.

Mike Vizard

Mike Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

Mike Vizard has 620 posts and counting. See all posts by Mike Vizard