K8S漏洞报告 | 近期bug fix解读&1.13主要bug fix汇总

因为这一漏洞，用户可以“跳过”登录过程获得仪表盘所使用的自定义TLS证书。如果您已将Kubernetes仪表盘配置为需要登录并将其配置为使用自定义TLS证书，那么这一漏洞会影响到您。

具体来说，该漏洞的运作原理是：

首先，因为登陆时用户可以选择“跳过”这一选项，那么任何用户都可以绕过登录过程，该过程在v1.10.0或更早版本中始终默认启用。这样一来，用户就完全跳过登录过程并能使用仪表盘配置的服务账户。

之后，使用仪表盘配置的服务账户，必须最低限度地有权限访问自定义TLS证书（以secret的形式存储）。未经身份验证的登录，加上仪表板使用配置的服务账户来检索这些secret的能力，组合在一起的结果就是这一安全问题。

社区已经在仪表盘v1.10.1对这个漏洞进行了修复，默认情况下将不再启用“跳过”选项，并且会禁用仪表盘在UI中检索和显示它的功能。

参考链接：

Kubernetes API server可以使用pod、node或service代理api，将请求代理的pod或节点上，通过修改podIP或nodeIP，可以将代理请求定向到任何IP。API server总是被部署在某网络中的，利用这个漏洞就访问该网络中的任何可用IP了。

该漏洞的具体运作原理是：

通过使用Kubernetes API，用户可以使用节点代理、pod代理或服务代理API请求与pod或节点的连接。Kubernetes接受此请求，找到podIP或nodeIP的关联IP，并最终将该请求转发到该IP。这些IP通常由Kubernetes自动分配。但是，集群管理员（或具有类似“超级用户”权限的不同角色）可以更新资源的podIP或nodeIP字段以指向任意IP。

这在很大程度上不是问题，因为“普通”用户无法更改资源的podIP或nodeIP。podIP和nodeIP字段位于pod和节点资源的状态子资源中。为了更新状态子资源，必须专门授予RBAC规则。默认情况下，除了集群管理员和内部Kubernetes组件（例如kubelet、controller-manager、scheduler）之外，没有Kubernetes角色可以访问状态子资源。想要利用此漏洞，首先得拥有对集群的高级别访问权限。

但是在一些特殊场景下，比如云提供商为用户提供的kubernetes集群，API server可能和集群运行在不同的平面，集群管理员不能访问运行API server的主机。

参考链接：

Kubernetes-csi（container storage interface）是kubernetes提供的一种容器存储接口，kubernetes可以与街上上运行的外部csi卷驱动程序交互，从而可以将任意存储系统暴露给自己的容器工作负载。

根据我们介绍的这个漏洞，借点上运行的kubernetes-csi sidecars，当日志级别提高到5或者更高时，会打印所有CSI RPC请求和响应的信息，其中包括请求过程中使用的secret的详细信息。这显然是不能接受的。

目前该漏洞的修复仅涉及kubernetes-csi项目维护的组件，包括：

如果您正在使用上述版本，可以将组件升级到下面版本以解决这个漏洞：

而其他csi driver提供商也应该评估是否存在相似的问题。

12/25-1/22期间，虽然没有特别严重的bug，但是需要关注的漏洞修复比较多，且都涉及到比较核心的组件和功能。