Back

HIGH

kubelet-started container uid changes to root after first restart or if image is already pulled to the node

Published Aug 29, 2019

Description

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.

Affected products

Remediation

Vendor solution

Specify runAsUser directives in pods to control the uid a container runs as. Specify mustRunAsNonRoot:true directives in pods to prevent starting as root (note this means the attempt to start the container will fail on affected kubelet versions).

Red Hat 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.

Red Hat 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

Metrics

References (11)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner kubernetes
Published Aug 29, 2019
Updated Sep 16, 2024
Reserved Apr 17, 2019
NVD
Status Modified
Modified Jun 17, 2026
Red Hat
Severity Moderate
Public date May 24, 2019
GHSA-R76G-G87F-VW8F