Addressing the Kubernetes privilege escalation flaw

The Kubernetes community is in the throes of dealing with a serious
security flaw. At Atomist, we run many of our services on Kubernetes using multiple cloud providers. Some of our clusters were automatically patched and updated (thanks, Google). On other providers, we mitigated the issue ourselves by disabling access to the Kubernetes controller API endpoint from outside the private network in which the Kubernetes cluster runs. We will migrate off the older clusters soon.

The potential impact is serious and detection, according to the CVE,
is not feasible. From the CVE report:

An API call to any aggregated API server endpoint can be escalated
to perform any API request against that aggregated API server, as
long as that aggregated API server is directly accessible from the
Kubernetes API server’s network. In default configurations, all
users (authenticated and unauthenticated) are allowed to perform
discovery API calls that allow this escalation.

A pod exec/attach/portforward API call can be escalated to perform
any API request against the kubelet API on the node specified in the
pod spec (e.g. listing all pods on the node, running arbitrary
commands inside those pods, and obtaining the command output). Pod
exec/attach/portforward permissions are included in the
admin/edit/view RBAC roles intended for namespace-constrained users.

As of Monday 3 December 2018 at 23:00 UTC, all of our systems had the
flaw mitigated.

If you have any questions about this issue, please
contact us at support@atomist.com.