Kubernetes安全三步谈：如何通过RBAC和强身份验证确保外部安全

这是关于 Kubernetes 安全性的三篇系列文章中的第一篇，在本系列文章中，我们将依次介绍如何确保企业的 Kubernetes 集群免受外部攻击、内部攻击，以及如何处理资源消耗或 noisy neighbors 问题 。

毋庸置疑，Kubernetes 已经成为云容器编排系统的标准，据 Cloud Native Computing Foundation（CNCF）的定义，它提供了一个“ 自动化部署、扩展以及跨主机集群操作应用程序容器的平台 ”。但是，如果缺乏 Kubernetes 环境相关的安全问题认识的话，会致使各种组件暴露在网络集群内外的攻击之下。

锁定 API 服务器，Kubelets

Kubernetes 环境中有多种可由外部访问的组件，包括应用程序编程接口（API）服务器、kubelet 以及数据存储。如果没有正确锁定和保护它们的话，这些组件有可能会造成数据泄漏和系统损害。

Kubernetes 为开发、运维和安全团队提供了一个 API 结构，可用于和应用程序和 Kubernetes 平台交互。Kubelet 是一个在节点上运行并且读取容器清单的服务，它确保定义了的容器已经启动并运行。Kubernetes 利用 etcd 分布式键值存储来保存和复制 Kubernetes 在整个集群中使用的数据。基本上， 最经常受到攻击的 Kubernetes 系统是那些根本没有设置访问控制的系统。

Goins 指出，Kubernetes 易于部署，在默认情况下并没有内置太多确保安全性的东西。例如，直到 2017 年年中，容器编排系统才开始具有 RBAC（基于角色的访问控制）功能。

Kubernetes 1.8 版本的亮点之一是 RBAC（基于角色的访问控制），这是一种用于管理 Kubernetes 资源周围权限的授权机制。RBAC 允许配置灵活的授权策略，可以在不需要重启集群的情况下进行更新。

“在很多 Kubernetes 部署中，一旦出现 compromise，用户可以使用 root 权限安装和运行他们想要的软件。”Goins 说，“黑客和网络犯罪分子希望进入一个系统，升级他们的权限，接着转向其他系统，开始收集信用卡和个人身份识别数据等信息。”

2018 年 12 月在Kubernetes爆出的首个安全漏洞——特权升级漏洞(CVE-2018-1002105)，当时是由 Rancher Labs 联合创始人及首席架构师 Darren Shepherd 发现的。该漏洞演示了用户如何通过 Kubernetes API 服务器建立和后端服务器的连接。建立连接之后，攻击者可以通过网络连接直接向后端集群服务（如 kubelets）发送任意的请求。该漏洞让任何用户在任何计算节点上都拥有完整的管理员权限。后来发布了专门修复受支持的 Kubernetes 版本的补丁，在 1.10.11，1.11.5 和 1.12.3 中都提供了这样的补丁。

企业该如何保护 K8s 集群免受外部攻击

Goins 建议，Kubernetes 用户需要做的第一件事是 完全关闭外部 API 访问 ，或者将该功能封装在某种强身份验证中设置保护。为了减轻外部攻击的威胁，信息技术/安全管理员必须确保只有必要的 Kubernetes 服务能对外暴露。此外，他们必须设置身份验证并且给所有公开的服务配置正确的网络安全策略。

Handy Tecchnologies 的 Alexander Uricoli 在一篇博客中写道：“除非你在 kubelet 上指定了一些标志（flags），否则它在默认操作模式下，是会接受未经身份验证的 API 请求的。”在这篇博客中 Uricoli 分析了黑客是如何入侵同时个人服务器上的 Kubernetes 集群的：

https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c

Uricoli 说：“看来有人找到了一种方法，可以在一个正在运行的容器上放置一些加密挖掘软件，然后执行这个过程。”Kubernetes API 服务器虽然面向 internet 公开，但是受到证书身份验证的保护。

结果，同事的服务器公开了 kubelet 端口（tcp 10250 和 tcp 10255）。Uricoli 指出，尽管问题已显而易见，这样的入侵仍然应该引起大家对 Kubernetes 的部署的一些问题的关注。如果你的用户可以通过网络节点来访问你的节点，那么 kubelet API 就是一个通往集群的 API 后门，它功能齐全且未经身份验证。如果用户已经花了很多心思在 webhook、RBAC 或其他方法启用身份验证和授权上，那么他们也同样应该将 kubelet 好好地锁定上。

互联网安全中心（CIS）建议用户为 kubelet 连接部署 HTTPS。CIS 在关于为 Kubernetes 1.11 建立安全配置的指南中写道，“从 API 服务器到 kubelets 的连接可能带有机密和密钥等敏感数据。因此， 在 API 服务器和 kubeletes 之间的任何通信中使用在途加密（in-transit）是非常重要的。 ”

Kubernetes 用户应该禁用对 API 服务器的匿名请求。启用时，没有被其他配置好的身份验证方法拒绝的请求将被视为匿名请求，然后 API 服务器会处理这些请求。根据 CIS 的说法，Kubernetes 的用户应该依靠身份验证来授权访问，并切拒绝匿名请求，而组织应该根据需要实现可控制的访问。

Goins 指出，加强内部集群用户防御的安全控制——RBAC、隔离以及权限限制——对于保护 Kubernetes 免受外部攻击同等重要。

他说：“如果有人使用任何内部用户的账户从外部访问集群，他们会立刻获得完全访问权限。”所以，这并不是说你需要内部控制来抵御外部的攻击。而是说如果你没有这些措施，当受到攻击的时候你就遭大殃了。

结语

Rancher Kubernetes 平台拥有着超过一亿次下载量，我们深知安全问题对于用户而言的重要性，更遑论那些通过 Rancher 平台在生产环境中运行 Docker 及 Kubernetes 的数千万用户。

2018 年年底Kubernetes被爆出的首个严重安全漏洞CVE-2018-1002105，就是由 Rancher Labs 联合创始人及首席架构师 Darren Shepherd 发现的。

2019 年 1 月Kubernetes被爆出仪表盘和外部IP代理安全漏洞时，Rancher Labs 也是业界第一时间向用户响应，确保了所有 Rancher 2.x 和 1.6.x 的用户都完全不被漏洞影响。

未来 Rancher 将会向用户分享更多容器及 Kubernetes 安全技巧。在下一篇博客中，我们将分享三种保护 Kubernetes 不受内部攻击的方法：基于角色的访问、Kubernetes 特性（如逻辑隔离，即命名空间）和 Rancher 资源（如 Project）。记得保持关注~