摘要：近期，仪表盘和外部代理接连被发现存在安全问题。本文将更深入解读这两个安全漏洞的原理会对您的部署造成的影响以及相应的应对之策。在中，仪表盘作为每个集群环境的一部分包含在内但是，部署不受影响，因为充当了仪表盘的身份验证授权和代理。
近期，Kubernetes仪表盘和外部IP代理接连被发现存在安全问题。针对这两个漏洞，Kubernetes发布了相应的补丁版本供会受漏洞影响的用户解决问题。本文将更深入解读这两个安全漏洞的原理、会对您的Kubernetes部署造成的影响以及相应的应对之策。
通过kubernetes仪表盘访问自定义TLS证书
Kubernetes仪表盘漏洞（CVE-2018-18264）会影响v1.10.0或更早的仪表盘版本。因为这一漏洞，用户可以“跳过”登录过程，假设配置的服务帐户，最后获得仪表盘所使用的自定义TLS证书。如果您已将Kubernetes仪表盘配置为需要登录并将其配置为使用自定义TLS证书，那么这一漏洞会影响到您，您需要及时注意。
该漏洞的运作原理
此漏洞可以分为两部分来解释。
第一个是，因为登陆时用户可以选择“跳过”这一选项，那么任何用户都可以绕过登录过程，该过程在v1.10.0或更早版本中始终默认启用。这样一来，用户就完全跳过登录过程并能使用仪表盘配置的服务帐户。
第二个是，使用仪表盘配置的服务帐户，必须最低限度地有权限访问自定义TLS证书（以secret的形式存储）。未经身份验证的登录，加上仪表板使用配置的服务帐户来检索这些secret的能力，组合在一起的结果就是这一安全问题。
使用仪表盘v1.10.1补丁时，默认情况下将不再启用“跳过”选项，并且会禁用仪表盘在UI中检索和显示它的功能。
该漏洞对Rancher 1.6.x和2.x意味着什么？
在Rancher 2.x中，默认情况下不会启用Kubernetes仪表盘，因为Rancher 2.0用户界面可用作替代方案。若您不会使用到仪表盘代码库，则不受此漏洞的影响。如果您更改了默认设置、在Rancher管理的任何Kubernetes集群之上部署了Kubernetes仪表盘，请务必使用Kubernetes官方提供的指南及补丁修复这一漏洞。
如果你使用的是Rancher 1.6.x，则完全无需担心。在Rancher 1.6.x中，Kubernetes仪表盘作为每个Kubernetes集群环境的一部分包含在内；但是，1.6.x部署不受影响，因为Rancher Server充当了Kubernetes仪表盘的身份验证授权和代理。它不利用默认的Kubernetes仪表盘登录机制。此外，Rancher部署的Kubernetes仪表盘不使用任何自定义TLS证书。
Kubernetes API服务器外部IP地址代理漏洞
下面让我们来探讨Kubernetes公告所描述的第二个漏洞。
Kubernetes API服务器使用节点、node或服务代理API，将请求代理到pod或节点。通过直接修改podIP或nodeIP，可以将代理请求定向到任何IP。API服务器总是被部署在某网络中的，利用这个漏洞就访问该网络中的任何可用IP了。尽管自从v1.10发布以来，Kubernetes已经在很大程度上增加了检查以缓解这个问题，但最近才发现有一条路径的问题并没有被完全解决——将代理指向本地地址到运行API服务器的主机。
该漏洞的运作原理
通过使用Kubernetes API，用户可以使用节点代理、pod代理或服务代理API请求与pod或节点的连接。Kubernetes接受此请求，找到podIP或nodeIP的关联IP，并最终将该请求转发到该IP。这些通常由Kubernetes自动分配。但是，集群管理员（或具有类似“超级用户”权限的不同角色）可以更新资源的podIP或nodeIP字段以指向任意IP。
这在很大程度上不是问题，因为“普通”用户无法更改资源的podIP或nodeIP。podIP和nodeIP字段位于pod和节点资源的状态子资源中。为了更新状态子资源，必须专门授予RBAC规则。默认情况下，除了集群管理员和内部Kubernetes组件（例如kubelet、controller-manager、scheduler）之外，没有Kubernetes角色可以访问状态子资源。想要利用此漏洞，首先得拥有对集群的高级别访问权限。
这一次Kubernetes官方发布的修复，是确定攻击向量可以存在于与集群分开管理控制面板的设置中。在这种情况下，集群管理员是不能访问运行API服务器的主机的。这种情况存在于您从云提供商处获得的托管Kubernetes服务中。在这种情况下，集群管理员可以通过将podIP / nodeIP修改为本地地址（如127.0.0.1）来访问API服务器的本地地址。今天发布的修复将阻止代理到本地地址。
这对Rancher用户意味着什么？
Rancher托管集群的默认权限，仅允许集群所有者和成员更改podIP或nodeIP字段。将该权限提供给其他用户时，必须假定允许用户能够完全访问集群中的任何节点。所有其他默认角色（例如项目所有者/成员）都无权访问这些字段。今天发布的修复程序所适用的部署的Kubernete集群，是其控制面板网络与应用程序使用的网络不同的。在Rancher 1.6.x或2.x中创建的Kubernete集群，均默认集群管理员具有对控制面板节点的完全访问权限。如果您正在使用Rancher 2.x，并且正在使用托管云提供商（例如EKS、GKE、AKS），请与他们核实安全性是否存在问题，因为控制面板是归云提供商所有。
我们始终希望能确保Rancher用户能够在最短时间内使用到最新的安全修复程序和相应补丁，Kubernetes版本v1.10.12、v1.11.6和v1.12.4解决了这两个安全漏洞，这三个版本的Kubernetes将可在Rancher 版本v2.1.5和v2.0.10中使用。如果你是Rancher v1.6.x版本的用户，则无需做任何更新，因为标准的v1.6.x安装不受这次安全漏洞影响。
您还可以通过下述两个链接了解到Kubernetes官方针对这两个漏洞的相应讨论：
https://discuss.kubernetes.io...
https://discuss.kubernetes.io...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/32829.html
摘要：爆出中等严重性安全漏洞拒绝服务漏洞。本文将进行漏洞解读和情景再现，并分享漏洞修复方案，用户来看应对之策了漏洞美国当地时间年月日，社区发布了拒绝服务的漏洞，即有写入权限的用户在写入资源时会导致过度消耗资源，此漏洞被评级为中等严重性。 Kubernetes爆出中等严重性安全漏洞——Kubernetes API Server拒绝服务漏洞CVE-2019-1002100。 本文将进行漏洞解读和...
摘要：年月日，研究人员通过邮件列表披露了容器逃逸漏洞的详情，根据的规定会在天后也就是年月日公开。在号当天已通过公众号文章详细分析了漏洞详情和用户的应对之策。 美国时间2019年2月11日晚，runc通过oss-security邮件列表披露了runc容器逃逸漏洞CVE-2019-5736的详情。runc是Docker、CRI-O、Containerd、Kubernetes等底层的容器运行时，此...
摘要：今天，发布了一系列补丁版本，修复新近发现的两个安全漏洞命令安全漏洞和端口映射插件漏洞。因为端口映射插件是嵌入到版本中的，只有升级至新版本的才能解决此问题。现在修复之后，将端口映射插件的规则由最优先变为附加，则可以让流量优先由规则处理。 今天，Kubernetes发布了一系列补丁版本，修复新近发现的两个安全漏洞CVE-2019-1002101（kubectl cp命令安全漏洞）和CVE-...
摘要：本文将介绍通过强身份验证如何确保企业的集群免受外部攻击。服务器虽然面向公开，但是受到证书身份验证的保护。年年底被爆出的首个严重安全漏洞，就是由联合创始人及首席架构师发现的。 毋庸置疑，K8s已经成为云容器编排系统的标准，但是，如果缺乏K8s环境相关的安全问题认识的话，会致使各种组件暴露在网络集群内外的攻击之下。本文将介绍通过强身份验证如何确保企业的K8s集群免受外部攻击。 showIm...
摘要：漏洞披露后，在第一时间发布了，用户可升级到此版本以修复该漏洞。年年底被爆出的首个严重安全漏洞，就是由联合创始人及首席架构师发现的。年月被爆出仪表盘和外部代理安全漏洞时，也是第一时间向用户响应，确保所有和的用户都完全不被漏洞影响。 runC是一个根据OCI（Open Container Initiative）标准创建并运行容器的CLI工具，目前Docker引擎内部也是基于runc构建的。...
阅读 1555·2021-09-22 15:52
阅读 3465·2021-09-22 14:59
阅读 2846·2021-09-02 15:12
阅读 974·2021-08-20 09:35
阅读 1580·2019-08-30 14:09
阅读 2713·2019-08-30 13:56
阅读 1651·2019-08-26 18:27
阅读 3365·2019-08-26 13:37
