上个月，全球最受欢迎的容器编排引擎Kubernetes，被爆出首个严重的安全漏洞，使得整个Kubernetes生态发生震荡。该漏洞（CVE-2018-1002105）使***者能够通过Kubernetes API服务器破坏集群，允许他们运行代码来执行一些恶意活动，比如安装恶意软件等。
今年年初，由于Kubernetes控制台中的配置错误，特斯拉被一个恶意挖掘加密货币的软件所感染。***者利用了特定Kubernetes控制台没有密码保护的这一漏洞，访问其中一个包含特斯拉大型AWS环境访问凭据的pod。
随着越来越多的企业开始使用容器以及容器编排引擎，他们需要采取必要的措施来保护计算机基础架构中的这一关键部分。为了帮助您完成这项工作，本文将为您介绍9项Kubernetes安全最佳实践。
01 升级到最新版本
每一季度的更新都会添加新的安全相关功能，而不仅仅是修复bug，为了充分利用这些安全特性，我们建议您始终保持运行最新的稳定版本。
02 启用基于角色的访问控制（RBAC）
控制谁可以访问Kubernetes API以及他们对基于角色的访问控制（RBAC）的权限。默认情况下，RBAC通常在Kubernetes 1.6及更高版本中启用，但如果您从那时起进行了升级并且没有更改配置，则需要仔细检查您的设置。由于Kubernetes授权控制器的组合方式，您必须同时启用RBAC并禁用传统的基于属性的访问控制（ABAC）。
启用RBAC之后，您还需要有效地使用它。为了特定命名空间的许可，您通常需要避免集群范围的权限。即便是为了调试，也应避免给予任何集群管理员权限，而是仅在需要的情况下根据具体情况授予访问权限，以提高安全性。
您可以使用kubectl get clusterrolebinding或kubectl get rolebinding -all-namespaces来探索集群角色和角色。同时，快速检查谁被授予了特殊的“cluster-admin”角色，在这个例子中，它是“master”组：
如果您的应用程序需要访问Kubernetes API，请单独创建服务帐户，并为每个使用站点提供所需的最小权限集。这优于为命名空间的默认帐户授予过宽的权限。
大多数应用程序根本不需要访问API， 对于这一情况，可以将automountServiceAccountToken设置为“false”。
03 使用命名空间建立安全边界
创建单独的命名空间是组件之间重要的第一层隔离。当不同类型的工作负载部署在不同的命名空间中时，我们发现应用安全控制（如网络策略）要容易得多。
您的团队有在高效地使用命名空间吗？检查一下那些非默认命名空间，即可确认了：
04 将敏感工作负载彼此分开
为了将潜在的破坏影响力限制在最小值，最好在一组专用计算机上运行敏感工作负载。此方法降低了通过共享容器运行时或主机的安全性较低的应用程序访问敏感应用程序的风险。例如，受损节点的kubelet凭证通常只有在安装到该节点上安排的pod中时才能访问机密内容，如果重要机密被安排到整个集群中的许多节点上，则***者将有更多机会窃取它们。
您可以使用节点池（在云或本地）和Kubernetes命名空间、污点（taints）、容差（tolerations）和其他控件来实现此分离。
05 安全的云元数据访问
敏感元数据（例如kubelet管理员凭据）有时会被盗或被滥用来升级集群中的权限。最近Shopify的赏金细节泄露bug就是一例。这说明了用户能够通过将微服务混淆为云提供商的元数据服务泄露信息来升级权限。GKE的元数据隐藏功能可以更改群集部署机制以避免此暴露，我们建议您在找到另一个永久的替代解决方案之前，一直使用这一功能。在其他环境中可能也需要类似的对策。
06 创建和定义集群网络策略
网络策略允许您控制进出容器化应用程序的网络访问。要使用它们，您需要确保拥有支持此资源的网络提供程序，对于一些托管的Kubernetes提供商，例如Google Kubernetes Engine（GKE），您需要选择加入。（如果您的集群已存在，则在GKE中启用网络策略需要进行简短的滚动升级。）一旦到位，请从一些基本的默认网络策略开始，例如默认阻止来自其他命名空间的流量。
如果您在GKE中运行，则可以检查集群是否在启用了策略支持的情况下运行：
07 运行集群范围的Pod安全策略
Pod安全策略设置了允许在集群中运行工作负载的默认值。考虑定义策略并启用Pod安全策略许可控制器，说明因云提供商或部署模型而异。首先，您可以要求部署放弃NET_RAW功能以抵御某些类型的网络欺骗***。
08 加强节点安全
您可以按照以下三个步骤来改进节点上的安全状态：
- 确保主机安全且配置正确。其中一种方法是根据CIS基准来检查您的配置，许多产品都有自动检查功能，可以自动评估配置是否与这些标准一致。
- 控制对敏感端口的网络访问。确保您的网络阻止访问kubelet使用的端口，包括10250和10255。此外，还需限制对可信网络以外的Kubernetes API服务器的访问。因为恶意用户很有可能会滥用对这些端口的访问权限，以便在未配置并需要在kubelet API服务器上进行身份验证和授权的集群中运行加密货币挖掘程序。
- 最小化对Kubernetes节点的管理访问。通常应该限制对集群中节点的访问，因为调试和执行其他任务可以在不直接访问节点的情况下进行。
09 启用审核日志（Audit Logging）
请确保您已经启用审核日志，并监视他们是否存在异常或不需要的API调用，尤其是任何失败授权——这些日志条目将显示状态“Forbidden”。授权失败可能意味着***者试图滥用被盗凭据。托管Kubernetes提供程序（包括GKE）可在其云控制台中访问此数据，并允许您设置授权失败警报。
遵循上文的9项建议，您可以获得更安全的Kubernetes集群。请记住，即便您已经完全按照以上步骤安全地配置了您的Kubernetes集群，您依然需要将安全性构建到容器配置的其他方面及其运行时操作中。当您提高技术堆栈的安全性时，需要寻找能够为容器部署提供中心治理点的工具，并为容器和云原生应用程序提供持续监控和保护。
原文地址：http://blog.51cto.com/12462495/2346831