Vulnerabilities in open source are vital to a lot of organizations and developers are paying close attention to. Any little breach can be very bad, especially when it comes to container orchestration.

开源漏洞对于许多组织至关重要，开发人员正在密切关注。 任何小的违反都可能是非常糟糕的，尤其是在涉及容器编排时。

Kubernetes has become one of the leaders in the container market. Most companies are now employing the capabilities of Kubernetes to manage their container workloads.

Kubernetes已成为集装箱市场的领导者之一。 现在，大多数公司都在使用Kubernetes的功能来管理其容器工作负载。

According to a survey, over 86% of companies are using Kubernetes for their container operations. Also, self-managed Kubernetes (35%) is now second to Amazon EKS (37%) with just a 2% difference after previously being the most used. Take a look at the figures below:

根据一项调查，超过86％的公司正在使用Kubernetes进行其容器运营。 此外，自我管理的Kubernetes(35％)现在仅次于Amazon EKS(37％)，仅次于最常用的2％，仅次于Amazon EKS。 看一下下面的数字：

With all these, you should have guessed by now that there will be a lot of accompanying security vulnerabilities. For every version released, there’s a list of security vulnerabilities discovered and fixes released.

有了这些，您现在应该已经猜到会有很多伴随的安全漏洞。 对于每个发布的版本，都有一个发现的安全漏洞和发布的修复程序的列表。

In this article, we’ll be exploring the Kubernetes security vulnerabilities that have been found this year so far, and the security best practices to follow so you can avoid and fix them.

在本文中，我们将探索今年迄今为止发现的Kubernetes安全漏洞，以及遵循的最佳安全最佳实践 ，您可以避免和修复它们。

Kubernetes ContainerNetworking — CVE-2020–10749 (Kubernetes ContainerNetworking — CVE-2020–10749)

This was found in all versions of container networking/plugins before the version 0.8.6. It allowed containers in Kubernetes clusters to perform man-in-the-middle (MitM) attacks.

在版本0.8.6之前的所有版本的容器网络/插件中都可以找到它。 它允许Kubernetes集群中的容器执行中间人(MitM)攻击。

A malicious container can send rogue IPv6 router advertisements to the host or other containers, to redirect traffic to the malicious container, as per the official description. The Bugzilla report it says:

根据官方描述，恶意容器可以将恶意IPv6路由器广告发送到主机或其他容器，以将流量重定向到恶意容器。 Bugzilla 报告说：

• The vulnerable code is not exploitable in the OpenShift Container Platform 3.11 and considered low.
  易受攻击的代码在OpenShift Container Platform 3.11中无法利用，并且被认为很低。
• OpenShift Container Platform 4 does not forward IPv6 traffic, hence making this vulnerability not exploitable.
  OpenShift容器平台4不会转发IPv6流量，因此使此漏洞无法利用。

The recommended solution is to prevent untrusted, non-privileged containers from running with CAP_NET_RAW. A fix can be found in this upstream.

推荐的解决方案是防止不受信任的非特权容器与CAP_NET_RAW运行。 可以在此上游找到修复程序。

Jenkins Google Kubernetes引擎— CVE-2020–2121 (Jenkins Google Kubernetes Engine — CVE-2020–2121)

Jenkins Google Kubernetes Engine Plugin 0.8.0 and earlier does not configure its YAML parser to prevent the instantiation of arbitrary types. This results in a remote code execution vulnerability by users able to provide YAML input files to Google Kubernetes Engine Plugin’s build step, as shown on their website.

Jenkins Google Kubernetes Engine插件0.8.0及更早版本未配置其YAML解析器以防止实例化任意类型。 这导致用户能够向Google Kubernetes Engine插件的构建步骤提供YAML输入文件的用户执行远程代码执行漏洞，如其网站上所示。

As you can see in WhiteSource’s Vulnerability Lab, the severity score for this vulnerability is 8.8 — pretty high. A fix has been released in Google Kubernetes Engine Plugin 0.8.1. It configures its YAML parser to only instantiate safe types.

如您在WhiteSource的Vulnerability Lab中看到的那样，此漏洞的严重性得分为8.8-很高。 谷歌Kubernetes引擎插件0.8.1中已发布了修复程序。 它将其YAML解析器配置为仅实例化安全类型。

You will need to have the 0.8.1 version upward to fix this vulnerability.

您需要具有0.8.1更高的版本才能修复此漏洞。

Kubernetes API服务器— CVE-2020–8552 (Kubernetes API Server — CVE-2020–8552)

The Kubernetes API server component in versions prior to 1.15.9, 1.16.0–1.16.6, and 1.17.0–1.17.2 has been known to be vulnerable to a denial of service attack through successful API requests.

已知1.15.9、1.16.0-1.16.6和1.17.0-1.17.2之前的版本中的Kubernetes API服务器组件很容易通过成功的API请求受到拒绝服务攻击。

This vulnerability has effects over the API server which is the cluster’s gateway component responsible for receiving, authenticating, authorizing, and processing administration requests on the cluster. The vulnerability has a severity score of 7.5, which is considered a medium-level vulnerability.

此漏洞影响了API服务器，该服务器是群集的网关组件，负责在群集上接收，认证，授权和处理管理请求。 该漏洞的严重性评分为7.5，被认为是中等级别的漏洞。

The vulnerability could lead to Denial of Service (DoS) by consuming the memory of the API server. Before Kubernetes v1.14, an attacker could initiate an authorized request to your API cluster through unauthenticated requests, exploiting its vulnerability.

该漏洞可能通过消耗API服务器的内存而导致拒绝服务(DoS) 。 在Kubernetes v1.14之前，攻击者可以利用未经身份验证的请求通过未经授权的请求向您的API集群发起一个授权请求，从而利用其漏洞。

An issue was opened on Kubernetes repo and a fix has been pushed here. To fix this, you will need to upgrade to version v1.18.0-alpha.3 as the vulnerability has been patched in v1.17.3, v1.16.7, and v1.15.10.

一个问题被打开了Kubernetes回购和修复已被推这里 。 要解决此问题，您需要升级到v1.18.0-alpha.3版本，因为该漏洞已在v1.17.3，v1.16.7和v1.15.10中进行了修补。

弹性云Kubernetes — CVE-2020–7010 (Elastic Cloud Kubernetes — CVE-2020–7010)

Elastic Cloud on Kubernetes (ECK) versions prior to 1.1.0 generate passwords using a weak random number generator. If an attacker is able to determine when the current Elastic Stack cluster was deployed they may be able to force the Elasticsearch credentials generated by ECK, according to CVE.

1.1.0之前的Kubernetes上的Elastic Cloud(ECK)版本使用弱随机数生成器生成密码。 根据CVE的说法，如果攻击者能够确定当前Elastic Stack集群的部署时间，则他们可能能够强制执行ECK生成的Elasticsearch凭证。

There’s really no workaround to fix this other than upgrading to the latest version since the vulnerability fix has been patched already. You will need to upgrade to version 1.1.0 if you are using Elastic Cloud on Kubernetes. You can read upgrade instructions here.

除了已经修补了漏洞修复程序之外，除了升级到最新版本以外，实际上没有解决此问题的解决方法。 如果您在Kubernetes上使用Elastic Cloud，则需要升级到1.1.0版本。 您可以在此处阅读升级说明。

Kubelet API — CVE-2020–8551 (Kubelet API — CVE-2020–8551)

The Kubelet component in versions 1.15.0–1.15.9, 1.16.0–1.16.6, and 1.17.0–1.17.2 has been known to be vulnerable to a DoS attack through the Kubelet API. As explained in the official description, this includes the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.

已知版本1.15.0-1.15.9、1.16.0-1.16.6和1.17.0-1.17.2中的Kubelet组件容易受到Kubelet API的DoS攻击。 如官方说明中所述，这包括通常在端口10255上提供的未经身份验证的HTTP只读API，以及通常在端口10250上提供的经过身份验证的HTTPS API。

This medium-rated vulnerability affects the Kubelet — the Kubernetes components controlling resources on a node. Like CVE-2020–8552, it can cause a denial of service by consuming the memory of a Kubelet and killing it.

中级漏洞会影响Kubelet，即Kubernetes组件控制节点上的资源。 像CVE-2020–8552一样，它可以通过消耗Kubelet的内存并杀死它来导致拒绝服务。

You can read more on the issue here and a fix has been pushed here. This vulnerability is similar to CVE-2020–8552. The fix patched has been applied to version v1.18.0-alpha.4.

你可以阅读更多关于这个问题在这里 ，并修复已经被推这里 。 此漏洞类似于CVE-2020–8552。 已修补的修补程序已应用于版本v1.18.0-alpha.4。

Apart from being on the latest version, you should follow the best practices in securing and preventing malicious access to the Kubernetes API server below:

除了使用最新版本外，您还应遵循最佳做法来保护和防止恶意访问以下Kubernetes API服务器：

• Always make sure that anonymous authentication is disabled unless you know what you are doing.
  除非您知道自己在做什么，否则请始终确保禁用匿名身份验证。
• Always make sure that the API server is accessible only from trusted subnets (e.g., via appropriate firewall rules). And also do not expose it on the public Internet at all.
  始终确保仅可从受信任的子网访问API服务器(例如，通过适当的防火墙规则)。 并且也完全不要在公共Internet上公开它。

结论 (Conclusion)

We have explored some vulnerabilities found in Kubernetes so far this year 2020 and know how to fix each of these vulnerabilities.

到今年2020年为止，我们已经探索了Kubernetes中发现的一些漏洞，并且知道如何解决这些漏洞中的每一个。

The best way to beat these vulnerabilities is to:

克服这些漏洞的最佳方法是：

• Be on the latest version of Kubernetes since all vulnerability mentioned here has been fixed.
  由于此处提到的所有漏洞均已修复，因此请使用最新版本的Kubernetes。
• Scan your codebases for vulnerabilities.
  扫描您的代码库中的漏洞。
• Ensure you are following security best practices.
  确保遵循最佳安全实践。

Security vulnerabilities are a significant issue as more organizations come to rely on Kubernetes for their cloud containers. The effects of these vulnerabilities vary between each cluster depending on their nature and what resources are used to power them. It’s better to be on the safe side and always follow best practices.

随着越来越多的组织开始依赖Kubernetes作为其云容器，安全漏洞已成为一个重要问题。 在每个群集之间，这些漏洞的影响会有所不同，具体取决于群集的性质以及用于为其提供动力的资源。 为了安全起见，最好始终遵循最佳做法。