The Kubernetes community discloses three vulnerabilities that involve multiple components, such as kube-apiserver, kube-controller-manager, and kubectl. If the log level of a system component is equal to or higher than a specific level, sensitive data may be leaked.
Vulnerabilities CVE-2020-8564, CVE-2020-8565, and CVE-2020-8566 are rated as Medium.
- For open source Kubernetes clusters:
- For Container Service for Kubernetes (ACK) clusters:
- These vulnerabilities do not affect standard managed or serverless clusters.
- These vulnerabilities do not affect standard dedicated clusters if you retain the default log levels of system components.
- For a standard dedicated cluster, if the log level of a system component is equal to or higher than the level that causes security risks, these vulnerabilities affect your cluster. For more information, see Preventative measures.
Assume that you have stored secrets that are used to pull images from a private repository in a Docker config file. If the log level of kubelet is four or higher, an attacker may exploit the vulnerability to obtain the secrets from the logs of kubelet.
If the log level of kube-apiserver is nine or higher, an attacker may exploit the vulnerability to obtain the
basic auth token.
Assume that you have used Ceph RADOS Block Device (RBD) to store application data. If the log level of kube-controller-manager is four or higher, an attacker may exploit the vulnerability to obtain the Ceph RBD admin secret from the logs of kube-controller-manager.
- Make sure that untrusted users do not have read permissions on the logs of system components.
- If an attacker may have permissions to read logs, we recommend that you rotate the secrets and modify the log levels.
- Clients such as kubectl may also cause data leakage. If you use kubectl, make sure that the log level of kubectl is lower than the level that causes security risks or the read permissions on log data are granted to trusted users.