In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0. Reference: https://github.com/kubernetes/kubernetes/issues/78308 https://github.com/rancher/k3s/issues/511 https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod
Upstream Fixes: https://github.com/kubernetes/kubernetes/pull/78261 (master) https://github.com/kubernetes/kubernetes/pull/78320 (1.13.7) https://github.com/kubernetes/kubernetes/pull/78316 (1.14.3)
Flaw introduced by: https://github.com/kubernetes/kubernetes/pull/76665 (master) https://github.com/kubernetes/kubernetes/pull/77322 (1.13) https://github.com/kubernetes/kubernetes/pull/77320 (1.14)
Gluster embeds very old kubernetes version v1.5.5 with heketi, which is not affected by this vulnerability. v1.5.5 ====== 140 uid, username, err := m.getImageUser(container.Image) 141 if err != nil { 142 return nil, err 143 }
Statement: This vulnerability only affects upstream Kubernetes versions 1.13.6 and 1.14.2. All released versions of Red Hat OpenShift Container Platform and Red Hat Gluster Storage 3 are not affected by this flaw as they do not contain the vulnerable code.
External References: https://discuss.kubernetes.io/t/security-regression-in-kubernetes-kubelet-v1-13-6-and-v1-14-2-only-cve-2019-11245/6584
Mitigation: There are two potential mitigations to this issue: 1. Downgrade to kubelet v1.13.5 or v1.14.1 as instructed by your Kubernetes distribution. 2. Set RunAsUser on all pods in the cluster that should not run as root. This is a Security Context feature; the docs are at https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod