Hello Kubernetes Community,
A security issue was discovered in kubelet that could result in the Denial of Service of a node if a pod can write to its own /etc/hosts file.
This issue has been rated Medium (5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M), and assigned CVE-2020-8557.
The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.
Any clusters allowing pods with sufficient privileges to write to their own /etc/hosts files are affected. This includes containers running with CAP_DAC_OVERRIDE in their capabilities bounding set (true by default) and either UID 0 (root) or a security context with allowPrivilegeEscalation: true (true by default).
kubelet < v1.16.13
PodSecurityPolicies or other admission webhooks could be employed to force containers to drop CAP_DAC_OVERRIDE or disallow running as root or with privilege escalation, but these measures may break existing workloads that rely upon these privileges to function properly.
To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster
Large pod etc-hosts files may indicate that a pod is attempting to perform a Denial of Service attack using this bug. A command such as
find /var/lib/kubelet/pods/*/etc-hosts -size +1M
run on a node can be used to find abnormally large pod etc-hosts files.
See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/93032
This vulnerability was reported by Kebe Liu of DaoCloud
Joel Smith on behalf of the Kubernetes Product Security Committee