Skip to main content

Kubernetes privilege escalation update for Tectonic users

Overview

A flaw has been detected in Kubernetes which allows privilege escalation and access to sensitive information in all Kubernetes deployments, including Tectonic. This vulnerability existed in all versions of Kubernetes since 1.2. Vulnerable versions of Tectonic Platform allow for complete exploitation of all pods running on a compute node to which a pod is scheduled with normal user privilege. This exploitation includes access to secrets, pods, environment variables, running pod/container processes, and persistent volumes.

In the Tectonic environments, a regular user, with pod exec/attach/portforward permissions, can gain full (cluster-admin) level privileges on any compute node that allows them to run a pod. Cluster-admin level privileges include exec access to all running workloads, read/write access all current secrets, read access to logs, etc.

Red Hat Product Security has rated this vulnerability CVE-2018-1002105 as CRITICAL, and advises customers to apply patches as soon as they can and to evaluate mitigation if exposed systems can not be remediated quickly.

Mitigation

To address this vulnerability, today we're releasing two new versions of Tectonic. Customers running earlier versions should update to the latest release and deploy these security updates:

- Tectonic 1.8.9-tectonic.4 on our 1.8 production and preproduction channels

- Tectonic 1.9.6-tectonic.2 on our 1.9 production and preproduction channels

Apply the update to your clusters by clicking “Check for Update” in your cluster settings. Visit  Upgrading Tectonic and Kubernetes for more information on this process.

Background

The Kubernetes API Server is included in all Tectonic installations and handles all the administration tasks for the cluster. Administrators and developers usually call the API via the ‘kubectl’ binary.

The API server provides various functionality, including the following kubectl commands:

  • kubectl exec

  • kubectl port-forward

It does this by acting as a reverse proxy to the kubelet running on the compute nodes. For more information, read the Get a Shell to A Running Container document.