Yesterday (3 Dec 2018), news broke of a critical vulnerability in Kubernetes. Many customers have asked questions about what this means to them and what Twistlock does to help and this post is designed to help answer them.
The specific CVE in question is CVE-2018-1002105. You can read more details about it in the Kubernetes’ project GitHub repo (https://github.com/kubernetes/kubernetes/issues/71411) or from Red Hat (https://access.redhat.com/security/vulnerabilities/3716411). Note that while a CVE ID has been assigned, details are not yet published in the National Vulnerability Database (https://nvd.nist.gov/vuln/detail/CVE-2018-1002105), though they likely will be soon. A short lag between vendor specific reports becoming available and the NVD being updated is not uncommon in cases where vulnerabilities are responsibly reported to vendors under embargo.
The specific details of the vulnerability are covered well in the Red Hat report, so we won’t go into them again in detail here. At the core of the problem is that unprivileged requests are not fully terminated, resulting in the potential to elevate privilege, potentially to cluster admin levels. This bug has been patched in Kubernetes, with updates available for 1.10, 1.11, and 1.12.
Security is always about defense in depth and Twistlock provides several layers that help mitigate the risk from this particular CVE. First, our vulnerability management feature already identifies affected OpenShift nodes so you can easily identify vulnerable systems. Other, non-Red Hat, Kubernetes distributions are actively pushing updates and that data will immediately be ingested into the Twistlock Intelligence Stream (and thus be used for detection in customer environments) as soon as those vendors publish them.
Second, we have a compliance check for anonymous access to the API master. Note that in an escalation of privilege scenario like this CVE, only preventing anonymous access is not sufficient to mitigate the problem. However, it does greatly limit the scope of risk posed by external users.
Finally, our runtime defense capabilities are explicitly designed to provide a backstop for unpredictable, anomalous activities. For example, if an attacker compromises app within a container and attempts to download and run tools like curl or kubectl to access the API, runtime sensors will automatically detect the anomalous binaries and prevent them from ever running. Further, the entire sequence of activities an attacker may follow to attempt the compromise are securely logged with our forensics feature, so you can understand the attempted attack’s flow from beginning to end.
Even given these multi-layered defenses, though, the core recommendation to everyone is simple: update your Kubernetes deployment to one of the fixed versions:
Kubernetes v1.10.0-1.10.10 (fixed in v1.10.11)
Kubernetes v1.11.0-1.11.4 (fixed in v1.11.5)
Kubernetes v1.12.0-1.12.2 (fixed in v1.12.3)
If you use a managed Kubernetes platform, your provider may be doing the work for you. For example, see the Google (https://cloud.google.com/kubernetes-engine/docs/security-bulletins) and Azure (https://azure.microsoft.com/en-us/updates/aks-clusters-patched-for-kubernetes-vulnerability/) announcements.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Key Differences in Security, Management for Serverless vs. ContainersRead the Blog
Docker vs. KubernetesRead the Blog
How Cloud Workload Protection is Different than Application SecurityRead the Blog
Zero-Trust Security: What It Means and How to Achieve ItRead the Blog
Service Mesh. Service Fabric. Service Bus. What Does It All Mean?!Read the Blog