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.
cpe:2.3:a:kubernetes:kubernetes:1.13.6:*:*:*:*:*:*:*
91091DC9-FC24-41B5-BABC-0578CFC6ACBC
cpe:2.3:a:kubernetes:kubernetes:1.14.2:*:*:*:*:*:*:*
7067A9B9-8EA2-4CB7-A80D-E1A79495F463
OR
[CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L), 4.9 (medium)

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.

CVE-2019-11245 will be **fixed** in the following Kubernetes releases:

* v1.13.7 in https://github.com/kubernetes/kubernetes/pull/78320
* v1.14.3 in https://github.com/kubernetes/kubernetes/pull/78316

Fixed by #78261 in master

### Affected components:

* Kubelet

### Affected versions:

* Kubelet v1.13.6
* Kubelet v1.14.2

### Affected configurations:

Clusters with:
* Kubelet versions v1.13.6 or v1.14.2
* Pods that do not specify an explicit `runAsUser: <uid>` or `mustRunAsNonRoot:true`

### Impact:

If a pod is run without any user controls specified in the pod spec (like `runAsUser: <uid>` or `mustRunAsNonRoot:true`), a container in that pod that would normally run as the USER specified in the container image manifest can sometimes be run as root instead (on container restart, or if the image was previously pulled to the node)

* pods that specify an explicit `runAsUser` are unaffected and continue to work properly
* podSecurityPolicies that force a `runAsUser` setting are unaffected and continue to work properly
* pods that specify `mustRunAsNonRoot:true` will refuse to start the container as uid 0, which can affect availability
* pods that do not specify `runAsUser` or `mustRunAsNonRoot:true` will run as uid 0 on restart or if the image was previously pulled to the node

### Mitigations:

This section lists possible mitigations to use prior to upgrading.

* 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)
* Downgrade kubelets to v1.14.1 or v1.13.5 as instructed by your Kubernetes distribution.

**original issue description follows**

**What happened**:

When I launch a pod from a docker image that specifies a USER in the Dockerfile, the container only runs as that user on its first launch.  After that the container runs as UID=0.

**What you expected to happen**:
I expect the container to act consistently every launch, and probably with the USER specified in the container.

**How to reproduce it (as minimally and precisely as possible)**:
Testing with minikube (same test specifying v1.14.1, `kubectl logs test` always returns 11211):
```
$ minikube start --kubernetes-version v1.14.2
😄  minikube v1.1.0 on linux (amd64)
💿  Downloading Minikube ISO ...
 131.28 MB / 131.28 MB [============================================] 100.00% 0s
🔥  Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
🐳  Configuring environment for Kubernetes v1.14.2 on Docker 18.09.6
💾  Downloading kubeadm v1.14.2
💾  Downloading kubelet v1.14.2
🚜  Pulling images ...
🚀  Launching Kubernetes ... 
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"
$ cat test.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: memcached:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/bash"]
    args:
    - -c
    - 'id -u; sleep 30'
$ kubectl apply -f test.yaml 
pod/test created

# as soon as pod starts
$ kubectl logs test
11211
# Wait 30 seconds for container to restart
$ kubectl logs test
0
# Try deleting/recreating the pod
$ kubectl delete pod test
pod "test" deleted
$ kubectl apply -f test.yaml 
pod/test created
$ kubectl logs test
0
```

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`): I get the results I expect in v1.13.5 and v1.14.1. The problem exists in v1.13.6 and v1.14.2
- Cloud provider or hardware configuration: minikube v1.1.0 using VirtualBox
- OS (e.g: `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:

CVE-2019-11245: v1.14.2, v1.13.6: container uid changes to root after first restart or if image is already pulled to the node
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : CVE-2019-11245: v1.14.2, v1.13.6: container uid changes to root after first restart or if image is already pulled to the node
Issue date:

--- start body ---
[CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L), 4.9 (medium)

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.

CVE-2019-11245 will be **fixed** in the following Kubernetes releases:

* v1.13.7 in https://github.com/kubernetes/kubernetes/pull/78320
* v1.14.3 in https://github.com/kubernetes/kubernetes/pull/78316

Fixed by #78261 in master

### Affected components:

* Kubelet

### Affected versions:

* Kubelet v1.13.6
* Kubelet v1.14.2

### Affected configurations:

Clusters with:
* Kubelet versions v1.13.6 or v1.14.2
* Pods that do not specify an explicit `runAsUser: <uid>` or `mustRunAsNonRoot:true`

### Impact:

If a pod is run without any user controls specified in the pod spec (like `runAsUser: <uid>` or `mustRunAsNonRoot:true`), a container in that pod that would normally run as the USER specified in the container image manifest can sometimes be run as root instead (on container restart, or if the image was previously pulled to the node)

* pods that specify an explicit `runAsUser` are unaffected and continue to work properly
* podSecurityPolicies that force a `runAsUser` setting are unaffected and continue to work properly
* pods that specify `mustRunAsNonRoot:true` will refuse to start the container as uid 0, which can affect availability
* pods that do not specify `runAsUser` or `mustRunAsNonRoot:true` will run as uid 0 on restart or if the image was previously pulled to the node

### Mitigations:

This section lists possible mitigations to use prior to upgrading.

* 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)
* Downgrade kubelets to v1.14.1 or v1.13.5 as instructed by your Kubernetes distribution.

**original issue description follows**

**What happened**:

When I launch a pod from a docker image that specifies a USER in the Dockerfile, the container only runs as that user on its first launch.  After that the container runs as UID=0.

**What you expected to happen**:
I expect the container to act consistently every launch, and probably with the USER specified in the container.

**How to reproduce it (as minimally and precisely as possible)**:
Testing with minikube (same test specifying v1.14.1, `kubectl logs test` always returns 11211):
```
$ minikube start --kubernetes-version v1.14.2
😄  minikube v1.1.0 on linux (amd64)
💿  Downloading Minikube ISO ...
 131.28 MB / 131.28 MB [============================================] 100.00% 0s
🔥  Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
🐳  Configuring environment for Kubernetes v1.14.2 on Docker 18.09.6
💾  Downloading kubeadm v1.14.2
💾  Downloading kubelet v1.14.2
🚜  Pulling images ...
🚀  Launching Kubernetes ... 
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"
$ cat test.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: memcached:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/bash"]
    args:
    - -c
    - 'id -u; sleep 30'
$ kubectl apply -f test.yaml 
pod/test created

# as soon as pod starts
$ kubectl logs test
11211
# Wait 30 seconds for container to restart
$ kubectl logs test
0
# Try deleting/recreating the pod
$ kubectl delete pod test
pod "test" deleted
$ kubectl apply -f test.yaml 
pod/test created
$ kubectl logs test
0
```

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`): I get the results I expect in v1.13.5 and v1.14.1. The problem exists in v1.13.6 and v1.14.2
- Cloud provider or hardware configuration: minikube v1.1.0 using VirtualBox
- OS (e.g: `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:

--- end body ---

comments :
--- start comments ---

--- end comments ---