Kubernetes仪表盘和外部IP代理漏洞及应对之策

近期,Kubernetes仪表盘和外部IP代理接连被发现存在安全问题。针对这两个漏洞,Kubernetes发布了相应的补丁版本供会受漏洞影响的用户解决问题。本文将更深刻解读这两个安全漏洞的原理、会对您的Kubernetes部署形成的影响以及相应的应对之策。node

经过kubernetes仪表盘访问自定义TLS证书api

Kubernetes仪表盘漏洞(CVE-2018-18264)会影响v1.10.0或更早的仪表盘版本。由于这一漏洞,用户能够“跳过”登陆过程,假设配置的服务账户,最后得到仪表盘所使用的自定义TLS证书。若是您已将Kubernetes仪表盘配置为须要登陆并将其配置为使用自定义TLS证书,那么这一漏洞会影响到您,您须要及时注意。安全

该漏洞的运做原理服务器

此漏洞能够分为两部分来解释。网络

第一个是,由于登录时用户能够选择“跳过”这一选项,那么任何用户均可以绕过登陆过程,该过程在v1.10.0或更早版本中始终默认启用。这样一来,用户就彻底跳过登陆过程并能使用仪表盘配置的服务账户。spa

第二个是,使用仪表盘配置的服务账户,必须最低限度地有权限访问自定义TLS证书(以secret的形式存储)。未经身份验证的登陆,加上仪表板使用配置的服务账户来检索这些secret的能力,组合在一块儿的结果就是这一安全问题。代理

使用仪表盘v1.10.1补丁时,默认状况下将再也不启用“跳过”选项,而且会禁用仪表盘在UI中检索和显示它的功能。server

该漏洞对Rancher 1.6.x和2.x意味着什么?ip

在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.十二、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...

相关文章
相关标签/搜索