自 2014 年开源以来，Kubernetes 迅速崛起，受到了众多厂商和开发者们的热烈追捧。发展 5 年时间，Kubernetes 已经成为了容器管理领域的实施标准。然而，随着 Kubernetes 的发展，它的漏洞与变化亦随之成为了广大厂商和开发者们最为关心的问题。
在本文当中，我们将带您重点回顾 2019 年 Kubernetes 的 CVE 漏洞和变化，并关注这些漏洞和变化是如何影响 2019 年的 Kubernetes。最后，我们将重点讲述，针对这些漏洞和变化，Rancher 如何应对，我们又为广大厂商和开发者们保驾护航做了哪些改变？
Kubernetes 安全成头等大事
Rancher 全球第一时间响应
纵观 2019 年，CNCF 中的解决方案都将安全放在了首要位置，并根据安全策略来制定产品战略和设计。2019 年 8 月，Kubernetes 发布了安全性审查的初步结果（https://www.cncf.io/blog/2019/08/06/open-sourcing-the-kubernetes-security-audit/），并提出在项目中推进安全性的计划。
2019 年 1 月 7 日
CVE-2018-18264（Kubernetes 仪表盘漏洞）
漏洞详情：
用户可以“跳过”登录过程，使用配置的服务帐户，最后获得仪表盘所使用的自定义 TLS 证书。
Rancher 第一时间响应：
Rancher 第一时间向用户响应。Rancher 1.6.x 不受此漏洞影响，在 Rancher 2.x 中，默认情况下不会启动仪表盘。如果更改了默认设置，则参考 Kubernetes 官方提供的指南修复漏洞。
Kubernetes API 服务器外部 IP 地址代理漏洞
漏洞详情：
Kubernetes API 服务器使用节点、node 或服务代理 API，将请求代理到 pod 或节点。通过直接修改 podIP 或 nodeIP，可以将代理请求定向到任何 IP。API 服务器总是被部署在某网络中的，利用这个漏洞就访问该网络中的任何可用 IP 了。
Rancher 第一时间响应：
Rancher 第一时间向用户响应。Rancher 1.6.x 不受这一漏洞影响。对于 Rancher 2.x 的用户可以在 Rancher v2.1.5 和 v2.0.10 中使用已经修复了该漏洞的 Kubernetes 版本（v1.10.12、v1.11.6 和 v1.12.4）。
2019 年 2 月 11 日
runc 容器逃逸漏洞
漏洞详情：
该漏洞允许以 root 身份运行的容器以特权用户身份在主机上执行任意代码。这一安全漏洞影响了几乎所有 Docker 和 Kubernetes 用户。
Rancher 第一时间响应：
Rancher 5 小时快速响应，邮件提醒所有用户漏洞详情及补丁与升级方法。此外，Rancher 立即更新 v2.1.6、v2.0.11 和 v1.6.26 三个版本以支持 Docker 修复漏洞的 18.09.2 新版本，并将修复程序反向移植到所有版本的 Docker 并提供给用户，供不能升级 Docker 的用户修复此漏洞问题。
2019 年 3 月 2 日
CVE-2019-1002100
K8S新安全漏洞的应对之策：API Server拒绝服务漏洞
漏洞详情：
该漏洞使得有 API 写入权限的用户在写入资源时导致 Kubernetes API server 过度消耗资源。
Rancher 第一时间响应：
Rancher 发布 v2.1.7、v2.0.12 两个版本，支持 Kubernetes 已修复漏洞的新版本（v1.11.8、v1.12.6、v1.13.4）。对于 Rancher 1.6.x 的用户，可以在 Rancher v1.6.26 的 Catalog 中使用 Kubernetes 发布的修复版本 v1.11.8 和 v1.12.6
2019 年 3 月 29 日
Kubernetes新近kubectl及CNI漏洞修复，Rancher 2.2.1发布
CVE-2019-1002101
漏洞详情：
这是 kubectl cp 命令中存在的安全漏洞，严重等级为【高】。攻击者可以使用 kubectl cp 命令替换或删除用户工作站上的文件，在用户计算机的任何路径上写入恶意文件。
CVE-2019-9946
漏洞详情：
这是 Kubernetes CNI 框架中的安全漏洞，严重等级为【中等】。这一漏洞使得我们配置 HostPorts 端口映射方式时 CNI 插件会在 iptables nat 链之前插入规则，这将优先于 KUBE- SERVICES 链。因此，传入流量时，流量会优先经过 HostPort 的规则，即使之后在链中出现了更适合、更具体的服务定义规则（例如 NodePorts），依然会由 HostPort 的规则来匹配传入的流量。
Rancher 第一时间响应：
Rancher 在当天紧急更新，发布了 Rancher v2.2.1、v2.1.8 以及 v2.0.13 这三个新版本，支持 Kubernetes 已经修复本次漏洞的版本（1.11.9、1.12.7 和 1.13.5）。对于 Rancher 1.6.x 的用户，已在 Rancher v1.6.26 的 Catalog（应用程序目录）中添加了对 Kubernetes v1.11.9 和 v1.12.7 的支持。
2019 年 4 月 19 日
CVE-2019-11202
Rancher 2.2.2 Stable版本发布，生产可用！
漏洞详情：
Rancher 首次启动时创建的默认管理员帐户将在 Rancher 的后续重新启动时重新创建，即使 Rancher 管理员明确删除了该帐户，也仍会如此。攻击者可以使用这些默认账号密码来获取对 Rancher Server 的管理员访问权限。
Rancher 第一时间响应：
发布 Rancher 2.2.2，在其中提供这一漏洞的修复程序。在 Rancher 2.1.x 和 Rancher2.0.x 中也包含了修复程序。此外，对于所有的 Rancher 版本，只要通过禁用默认管理员帐户而不是完全删除它，就可以不受此漏洞影响。
2019 年 6 月 6 日
CVE-2019-12303
漏洞详情：
CVE-2019-12303 漏洞中项目管理员可以在对接日志系统时，通过注入额外的 Fluentd 配置参数，来读取到 Fluentd 容器内的文件或执行任意命令，例如其他项目管理员配置的 ElasticSearch。
CVE-2019-12274
漏洞详情：
CVE-2019-12303 漏洞中某些内嵌的主机驱动可以配置一个文件路径的参数。通过主机驱动创建主机时，创建者可以通过该漏洞获取 Rancher Server 内任意容器的内容，例如 /root/.kube/config。这样，主机创建者可以获取 Rancher 管理平面的访问权限。
Rancher 第一时间响应：
立刻发布 Rancher 2.2.4 修复以上两个安全漏洞。
2019 年 7 月 16 日
CVE-2019-13209
Rancher 2.2.5发布，CVE修复，支持K8S 1.15
漏洞详情：
该漏洞称为“跨站点 Websocket 劫持攻击”。攻击者可以通过被攻击者的角色/权限来访问由 Rancher 管理的集群。它要求被攻击者登录到 Rancher 服务器，然后访问由开发者托管的第三方站点。一旦完成，开发人员就能够利用被攻击者的权限和身份对 Kubernetes API 执行命令。
Rancher 第一时间响应：
Rancher 立刻更新，发布了 v2.2.5 版本修复该漏洞，同时还发布了 Rancher v2.1.11 和 v2.0.16，这两个版本也提供了此漏洞的修复程序，可供尚未升级至 Rancher 2.2.x 的用户使用。
2019 年 8 月 6 日
CVE-2019-11247 和 CVE-2019-11249
Rancher 2.2.7发布！修复CVE，支持Kubernetes新版本！
漏洞详情：
CVE-2019-11247 漏洞会导致 API Server 允许通过错误的范围访问自定义资源。
CVE-2019-11249 漏洞会导致恶意容器在客户端使用 kubectl cp 操作时将有权限在客户端计算机上创建或替换文件。
Rancher 第一时间响应：
8 月 7 日，Rancher 发布了最新版本 Rancher 2.2.7，支持 Kubernetes 最新发布的补丁版本（v1.13.9、v1.14.5、v1.15.2）。此外，还发布了 Rancher v2.1.12，可供尚未升级至 Rancher 2.2.x 的用户使用。
2019 年 8 月 20 日
CVE-2019-9512 和 CVE-2019-9514
Rancher 2.2.8发布，支持K8S新CVE的补丁版本！
漏洞详情：
Go 语言由于受到 CVE-2019-9512 和 CVE-2019-9514 漏洞影响，因此 Kubernetes 的所有版本和所有组件都受到该漏洞影响。此外，受到影响的还有 HTTP/2 流量（including/healthz）。这两个漏洞还允许不受信任的客户端分配无限量的内存，直到服务器崩溃。
Rancher 第一时间响应：
8 月 21 日凌晨，Rancher 紧急发布了 2.2.8 版本，支持 Kubernetes 新的补丁版本（v1.13.10、v1.14.6、v1.15.3）。同时，Rancher Labs 官方还发布了 v2.1.13，可供尚未升级至 Rancher 2.2.x 的用户使用。
2019 年 10 月 17 日
全球第一时间响应：Rancher发布2.3.1，支持K8S CVE修复版本
CVE-2019-11253
漏洞详情：
CVE-2019-11253 是 kube-apiserver 中的一个拒绝服务漏洞，它允许授权用户发送恶意的 YAML 或 JSON 有效负载，然后导致 kube-apiserver 消耗过多的 CPU 或内存，从而可能崩溃并变得不可用。
CVE-2019-16276
漏洞详情：
CVE-2019-16276 这一漏洞在 Go 的 net/ http 库中 CVE-2019-16276 会导致无效的请求头被 HTTP 服务器规范化并解释为有效。如果 Go HTTP 服务器前的反向代理允许并转发某无效的请求头，但又不对其进行规范化，则 Go 服务器对这些请求头的解释可能与反向代理不同。
Rancher 第一时间响应：
Rancher 全球第一时间响应 ，在当天紧急发布了新的版本 Rancher 2.3.1 和 Rancher 2.2.9 以支持 Kubernetes 补丁版本（v1.13.12、v1.14.8、v1.15.5）。Rancher 2.3.1 还添加了对 Kubernetes 1.16.2 的实验性支持。
Rancher 安全体系全新升级
为您的安全保驾护航
为了让 Rancher 的用户能够轻松提升安全意识，我们对安全问题的解决程序进行了全面改革。我们实施了新程序，以确保我们可以将问题及其解决方案引起用户注意，同时避免用户因此遭受损失。具体来说，这一新程序使得我们能够快速发布 Rancher 和 Kubernetes 的安全更新，并在必要时为用户提供 Rancher 工程师的额外支持。
除此之外，我们还 发布了 CIS 自我评估、强化指南，并聘请第三方公司对 Rancher 产品进行渗透测试 。因此，我们整套事件管理流程比以往更高效，并且我们在产品里添加了一些功能，这些功能使用户可以更轻松地保证 Kubernetes 环境的安全。
安全审核是由两家独立的公司进行的，他们对 Rancher 平台进行了白盒渗透测试。名为 Cure53 的公司进行对 Rancher 平台了最新测试，这家公司曾为 CNCF 执行 Prometheus 和 CoreDNS 的安全审核。另外，我们还聘请了 Untamed Theory，它对平台进行了测试并指出可以改进的地方。我们的研发部门结合两组报告修复和验证所有问题。现在，这些报告已经公开（https://rancher.com/docs/rancher/v2.x/en/security/#third-party-pen-test-reports）。后续，我们将继续监控并改进流程，最大程度地提高平台安全性。
在过去一年中，我们在 Rancher 和 RKE 中添加了一些功能，这些功能让 Kubernetes 集群变得更加坚不可摧。
例如，RKE 现在可以：
直接启用加密程序
配置审核日志以及速率限制
通过集群模板轻松部署安全配置的集群
从 Rancher 2.3 开始，管理员可以直接升级新版本的Kubernetes而无需先升级 Rancher。这一特性将 Rancher 发布周期与 Kubernetes 发布周期解耦，这体现了我们确保 Rancher 用户安全的承诺。
我们保障用户安全的工作会在持续改进中前行，而我们计划在 2020 年第二季度初发布 Rancher 2.4 版本。在新版本中，您可以看到令人惊喜的新特性—— 集群将在产品的核心中嵌入 CIS 扫描 ，进而确保安全性和运维团队对 Kubernetes 进行企业部署所需的可观察性。
如果你想要了解更多有关 Kubernetes 和 Rancher 中安全性的信息，或者要查看已经修复的 CVE 或下载 Rancher 强化指南，欢迎查看 Rancher 文档中的安全性部分：
https://rancher.com/docs/rancher/v2.x/en/security/
回首 2019，对于 Kubernetes 来说这是极具挑战的一年，在这一年里安全成为了 Kubernetes 的头等大事。随着 Kubernetes 在企业中的关注度日益增加，集群管理员必须了解如何部署以及保证 Kubernetes 及其工作负载的安全。
Rancher 作为全球用户量最大的企业级 Kubernetes 管理平台，本着对用户负责的态度，在与众多厂商和开发者们息息相关的 Kubernetes 漏洞及变化问题上毫不懈怠，永恒站在修复与安全的第一线，为众多厂商和开发者们的 Kubernetes 旅途保驾护航。
未来，Rancher 也将一如既往支持与守护在用户的 K8S 之路左右，确保大家安全、稳妥、无虞地继续前进。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论