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

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

• 来源:网络
• 更新日期:2020-07-22

摘要：云计算 毋庸置疑，K8s已经成为云容器编排系统的标准，但是，如果缺乏K8s环境相关的安全问题认识的话，会致使各种组件暴露在网络集群内外的***之

云计算 毋庸置疑，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）。记得保持关注~