上个月，Kubernetes被曝首个重大安全漏洞，动摇了Kubernetes的生态系统。这个漏洞允许攻击者通过Kubernetes API服务器攻击集群，使其运行代码执行安装恶意软件等行为。
今年早些时候，特斯拉遭遇了一场复杂的加密货币挖矿恶意软件感染，起因是Kubernetes控制台配置错误。Kubernetes控制台没有密码保护，攻击这利用这一点访问了其中的一个pod，这里面有特斯拉在AWS环境中的访问凭证。
随着容器和容器编排器的采用率不断增加，组织需要采取必要的措施来保护关键的计算基础设施。可以参考以下9个客户反馈的Kubernetes最佳安全实践来保护你的基础设施。
1. 升级到最新版本
除了修复bug，Kubernetes每个季度的更新都会新增一些安全特性。为了用好这些特性，我们建议你运行最新的稳定版本。最好的方法是使用运行最新的版本（带有最新的补丁），特别是在发现上个月的漏洞爆发之后。你的版本越旧，升级和支持会变得越来越困难，所以你应该计划每个季度至少升级一次。使用托管的Kubernetes服务可以使升级变得非常容易。
2. 启用基于角色的访问控制(RBAC)
控制访问Kubernetes API的访问者，以及他们对RBAC有哪些权限。RBAC通常在Kubernetes 1.6或更高版本中默认启用(之后会针对某些托管服务)，但是如果你从1.6版本就开始升级，并且没有更改配置，则需要再次检查设置。由于Kubernetes授权控制器的组合方式，你必须同时启用RBAC和禁用遗留授权(ABAC)。
RBAC被强制执行后，你仍然需要有效地使用它。为了支持特定命名空间的访问权限，通常应该避免集群级别的访问权限。避免给任何人集群管理的权限，即使是调试权限——仅在需要时根据具体情况授予访问权限要安全得多。
你可以使用“kubectl get clusterrolebinding”或“kubectl get rolebinding -all-namespaces”来研究集群角色。快速检查谁被授予特殊的“集群管理员”角色；在这个例子中，它只是“masters”：
如果你的应用程序需要访问Kubernetes API，请单独创建服务账户，并在每个使用站点为它们提供所需的最小权限集。这比为命名空间的默认账户授予不受限制的权限要好。大多数应用程序根本不需要访问API；’ automountServiceAccountToken '可以设置为“false”。
3. 使用命名空间来建立安全边界
创建独立的命名空间是隔离组件很重要。我们发现，当不同类型的工作负载部署在不同的命名空间中时，应用安全控制(如网络策略)要容易得多。
你的团队是否在有效地使用命名空间？可以通过检查非默认命名空间来看看情况：
4. 分离的敏感负载
为了减少被盗用的影响，最好在一组专用计算机上运行敏感的工作负载。这种方法降低了共享容器运行时或主机访问安全性较差的应用程序时的风险。例如，一个被破坏的节点的kubelet凭证只有被放到调度节点的pod上，才能访问secret的内容——如果重要的secret被调度到集群中的许多节点上，那么对手将有更多的机会窃取它们。
可以使用节点池(云中或本地)和Kubernetes的命名空间、taint、容忍和其他控件来实现这种分离。
5. 安全的云端元数据访问
敏感的元数据，例如kubelet管理凭证，有时会被窃取或误用来升级集群中的特权。例如，最近Shopify披露的漏洞报告奖励里详细说明了用户如何通过混淆微服务使用特权进而从云提供商的元数据服务里泄露信息。GKE的元数据隐藏特性改变了集群部署机制，我们建议使用它来避免这种暴露，直到永久解决方案出现替代它。在其他环境中可能需要类似的对策。
6. 创建和定义集群网络策略
网络策略允许用户控制对容器化应用程序的网络访问。要使用它们，需要确保有一个支持该资源的网络提供商；对于一些Kubernetes托管商，如谷歌Kubernetes引擎(GKE)，你需要进行选择。(如果集群已经存在，那么在GKE中启用网络策略需要进行简单的滚动升级。)设置好之后，从一些基本的默认网络策略开始，比如默认情况下阻塞来自其他名称空间的流量。
如果在谷歌容器引擎中运行，可以检查集群是否在启用策略支持的情况下运行：
7. 运行集群范围的Pod安全策略
Pod安全策略可以设置集群中工作负载的默认运行方式。考虑定义一个策略并启用Pod安全策略允许控制器——根据云提供商或部署模型的不同，指令也不同。可以要求放弃NET_RAW功能的部署，以防止某些类型的网络欺骗攻击。
8. 强化节点安全
可以按照以下三个步骤改进节点上的安全状态:
-
确保主机安全并正确配置。一种方法是根据CIS基准检查配置；许多产品都有自动检查器，可以自动评估是否符合这些标准。
-
控制对敏感端口的网络访问。确保你的网络阻止了对使用kubelet端口的访问，包括10250和10255。除非来自受信任的网络，否则要考虑限制对Kubernetes API服务器的访问。恶意用户滥用对这些端口的访问，在集群中运行加密币挖矿机，这些集群没有设置成在kubelet API服务器上需要有身份验证和授权。
-
最小化对Kubernetes节点的管理访问。通常应该限制对集群中节点的访问——调试和其他任务通常可以在不直接访问节点的情况下处理。
9. 打开审计日志
确保启用了审计日志，并且正在监视异常或不需要的API调用，特别是任何授权失败——这些日志条目将有一个状态消息“Forbidden”。授权失败可能意味着攻击者试图滥用窃取的凭证。Kubernetes托管商(包括GKE)在其云控制台中提供对这些数据的访问，并允许设置授权失败的警报。
展望未来
按照这些建议创建一个更安全的Kubernetes集群。请记住，即使按照这些提示安全地配置了Kubernetes集群，仍然需要将安全性构建到容器配置及其运行时操作的其他方面。在改进技术堆栈的安全性时，要找到为容器部署提供治理中心点并为容器和云本地应用程序提供持续监视和保护的工具。
原文链接：
https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/