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

毋庸置疑，K8s已经成为云容器编排系统的标准，可是，若是缺少K8s环境相关的安全问题认识的话，会导致各类组件暴露在网络集群内外的攻击之下。本文将介绍经过强身份验证如何确保企业的K8s集群免受外部攻击。

---

这是关于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）。记得保持关注~