每个人都必须遵守的9大Kubernates最佳安全实践

CVE-2018-1002105漏洞：只要可以从Kubernetes API服务器的网络中可以直接访问聚合API服务器，就可以提升权限对任何聚合API服务器端点进行API调用，以及对该聚合API服务器执行任何API请求（例如Pod的创建以及执行任意命令并获得返回结果）。 在默认配置中，允许所有用户（经过身份验证和未经身份验证的用户）执行允许此权限提升的API调用。

该漏洞由Rancher Labs的首席架构师兼联合创始人@Darren Shepard发现。

​ 上个月，世界上最流行的容器编排系统Kubernates生态圈被 Kubernetes第一个主要安全CVE-2018-1002105(用户权限提升漏洞)漏洞的发现 震惊。它允许攻击者通过Kubernates API服务器来危害集群，允许攻击者运行代码、安装恶意软件等进行恶意活动。

​ 今年早些时候，Tesla由于错误在Kubernates控制台配置输出内容而遭受复杂加密货币挖矿程序的感染。攻击者利用Kubernates控制台未进行密码保护的漏洞，进而提升权限对其中的pods进行访问，最终获取Tesla's更大的AWS集群环境的权限。

​ 随着公司组织加速采用容器和容器编排技术，我们有必要采取措施去加强寄保护基础计算设施。为了达到这个目的，基于用户输入，您应该好好参考如下的九大安全最佳实践去保护自己的基础设施。

1. 将环境更新到最新版本

​ 每个进度的更新都会添加新的安全特征，而不仅仅是进行bug修复，为了利用这些特征，我们建议您运行最新的稳定版本。最好的方法是使用最新发布稳定版本的补丁来进行修复，特别是考虑到CVE-2018-1002105的发现。使用的版本越久意味着升级和支持将会变得更加困难，因此计划每个季度至少进行一次更新是比较不错的选择。使用托管的Kubernates产品使得更新更为方便。

2. 开启基于角色的权限控制(RBAC)

​ 控制谁可以访问Kubernates API，以及他们具有基于角色的访问控制（RBAC）的哪些权限。RBAC在Kubernates 1.6以及后面版本(有些服务商可能稍有延迟)是默认开启的，但如果您自从更新以后就没有更改过配置了，那您就需要进行再次确认您的配置。因为Kubernates的授权控制是组合的，您必须同时开启RBAC和禁止过时的基于属性的权限控制(ABAC)

​ 一旦RBAC开启，您依然也需要有效的使用。为了支持特定于命名空间的权限，应该避免集群范围内的权限。避免分配给任何人集群管理源的权限，就算用于debugging，仅在需要的时候根据具体情况授予访问权限要安全得多。

​ 您可以通过使用 kubectl get clusterrolebinding 或者是 kubectl get rolebinding -all-namespaces 来回去集群的角色和权限。快速查看谁赋予特定"集群管理员"角色，在下面案例中，它仅仅属于"masters"组

​ 如果您的应用需要获取Kubernates API的权限，单独创建服务所需要的账户并且根据每个站点进行最小权限集配置。这比为命名空间的默认账户授予过于广泛的权限要好得多。

​ 大多数应用并不需要访问Kubernates API的权限，将 "automountServiceAccountToken" 设置为 false 即可。

3. 使用命名空间来建立安全的边界

​ 创建独立的命名空间是隔离组件的第一个重要级别。我们发现当不同类型的工作负载在不同的命名空间进行部署的时候，像网络策略这样的更容易进行安全控制。

​ 您的团队是否更有效的使用了命名空间？现在通过检查任何非默认命名空间来找出答案。

4. 隔离敏感的工作负载

​ 为了遏制集群中的潜在影响，最好的方法就是使用一系列专门的机器来运行敏感的工作负载。这种方法可以降低敏感应用可以获得较低安全应用并获取容器的运行时或者宿主信息的风险。举个例子，收到攻击的节点的kubelet凭证通常用来获取加密的内容，除非它们被挂载到该节点定时调度的pods上。如果加密的内容被调度运行在集群中的多个节点上，攻击者就会有更多的机会来窃取信息。

​ 你可以使用节点池(在云上或者是在本地)和Kubernates命名空间、污点、容忍度或者其他控制来实现。

5. 安全云元数据访问

​ 敏感的数据元，例如kubelet管理凭证，有时候会被窃取或误用来升级集群中的特权。例如最近公布的Shopify bug bounty详细说明了用户是如何通过获取云服务商的服务元信息来混淆微服务中的内存泄露信息。GKE's元数据中隐藏了集群发布特征的机制已避免这些信息暴露，并且我们推荐使用这种方式直到找到有效的解决方案，相似的对策可能在其他方案中也是必须的。

6. 创建并定义集群网络策略

​ 网络策略可以允许你控制容器化应用的网络进出。为了更好使用它们，你需要确保你有一个网络服务商来支持和管理这些资源，像托管Kubernates服务商谷歌Kubernates引擎(GKE)，当然你可以选择。如果集群已经存在，那么在GKE中启用网络策略需要进行简单的滚动升级。设置好之后，从基本的默认网络策略开始，比如默认情况下阻塞来自其他命名空间的流量。

​ 如果您运行在Google Container Engine，您可以检查您的集群是否开启了网络支持运行：

7. 运行集群范围内的pod安全策略

​ Pod安全策略设置集群中工作负载的默认运行方式，三思而后行并定义一个策略去保证Pod安全策略控制权限，指令根据不同的云服务商的不同而不同。您可以要求放弃部署NEW_RAW功能而挫败网络欺诈攻击者。

8. 强化节点安全

​ 您可以按照如下的三个步骤来提升您节点的安全：

• 确保宿主机是安全并且被正确配置 。其中一个方法就是通过CIS基准测试去检查你的配置文件，许多产品都有自动化检查器，可以自动评估是否符合标准
• 控制敏感ports网络的权限。 确保您的网络阻止了kubelet使用端口访问，包括10250和10255。考虑限制除了信任的网络以外的网络对Kubernates API的访问权限。恶意用户滥用这些端口在集群中来运行加密货币挖矿程序，这些集群没有配置为需要kubelet API服务上的身份认证和授权。
• 最小化Kubernates节点的管理员权限。 访问急群众的节点权限应该严格被控制，debugging和其他任务通常不需要获取节点的权限就可以运行。

9. 开启审核日志

​ 确保您已经开启审核日志并且监控异常和非法API调用，特别是要注意任意的授权失败的日志。这些日志记录将会有一个“禁止状态“，授权失败意味着可能有攻击者想要窃取凭证信息。包括GKE在内的托管Kubernates服务商，都在云控制台输出了这些数据，你可以配置在授权失败时进行报警。

展望未来

​ 遵循上述的几条推荐可以使得你的Kubernates集群更为安全。记住，尽管遵循了上述的几条建议可以使得您的Kubernates集群更安全，但您仍然需要在其他方面构建安全，例如容器配置、运行时操作等。在改进技术栈的安全性时，请寻找为容器部署提供治理中新点并为容器和云本地应用程序提供持续监视和保护的工具。

原文链接： 9 Kubernetes Security Best Practices Everyone Must Follow （翻译：刘明）