Skip to main content

DNS security vulnerability patched in Kubernetes and Tectonic

Security researchers have recently discovered multiple remotely exploitable vulnerabilities affecting all users of Kubernetes 1.5.0 through 1.7.6. While the risk of an attacker successfully exploiting these flaws is relatively low, the vulnerabilities could potentially allow arbitrary code execution or DoS attacks and thus demand immediate attention. CoreOS Tectonic users can be assured, however, that patches are now available and can be applied with a single click or automatically, if configured.

Am I affected?

The vulnerabilities concern the Kubernetes DNS server which runs inside Kubernetes clusters and is a built-in service since Kubernetes 1.3. For details on identifying and fixing the issue if you are not a Tectonic user see the kubernetes-dev post.

For the Tectonic platform we are rolling out specific fix releases to our update channels for existing clusters:

Channel Version
1.6 1.6.10-tectonic.2
1.7 preproduction 1.7.5-tectonic.1
1.7 production 1.7.3-tectonic.3

 

Tectonic clusters installed with 1.7.5 already include the fix and don't need to update.

How do I update?

Fortunately, patches for these bugs are now available, and leveraging Tectonic’s automated operation capabilities, CoreOS has already pushed out fixes to the Tectonic update channels.

To update, visit your Tectonic Console, click Administration and Cluster Settings. From this console you can approve the update and check your current versions. If you have Automatic approval enabled you shouldn't need to take any action and can check the status from this page.

Screenshot showing how to check Tectonic versions and perform an update
The Tectonic Console makes it easy to check cluster version information and approve updates.

All affected Tectonic customers will receive an email detailing how to perform a manual update. Tectonic 1.5 users will also be supplied with a kubectl command to perform the patch as this release did not include automated operations.

CoreOS has made security a top priority from Day One, beginning with the automated update capabilities we designed for Container Linux. And while no software system as complex as Kubernetes can be guaranteed to be free of bugs, the ability to apply patches in near real time through automated operations means Tectonic customers can rest assured their clusters are both stable and secure.

Vulnerability Impact and References

The specific vulnerabilities have been assigned the following CVEs: CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, CVE-2017-14495, CVE-2017-14496.

Because Kubernetes DNS is not ordinarily exposed to the broader network, let alone the internet, the risk of exploits is somewhat reduced. It's worth noting, however, that exploits would be launched via DNS and DHCP packets, which often bypass typical network access controls.

Updates are key for distributed systems

Well architected systems like Kubernetes contain lots of moving parts. Kubernetes itself comprises multiple software packages to provide foundational services for distributed applications – such as a container runtime, or a DNS server to enable service discovery. Each of these components may be subject to security vulnerabilities and require updates from time to time.

Automating these update operations is the best way to ensure that distributed systems remain secure with minimal to zero downtime, which is why we've made automated operations a central tenet of our Tectonic platform. Going forward, we'll continue to broaden and extend the automated operations capabilities of Tectonic, to ensure users have the smoothest, most secure experience managing their Kubernetes clusters.

Incident response is improved

The speed with which these latest vulnerabilities were patched in upstream Kubernetes benefited greatly from the Kubernetes community's improved security release process. CoreOS helped lead the effort to standardize the community's response to security incidents, based on issues identified last October, and the response to this and other recent issues has been organized and efficient. Thank you to the entire Kubernetes release team and security team for fast and thoughtful response on this issue.