作者：Todd Morneau是Threat Stack公司的产品管理总监，曾供职于EMC和EMC的安全部门RSA。

容器的采用率在急剧上升。知名调研公司Gartner估计，到2020年，50%的公司将使用容器技术，而2017年不到20%。不难看出原因所在：容器提供了更大的开发运维（DevOps）灵活性和经过优化的构建/部署管道。

容器采用率激增导致开发者圈子出现了一个新的现象，我们称之为“Kubernetes FOMO”（生怕错过Kubernetes）。众多企业组织纷纷跳上了Kubernetes这趟彩车，不想错过市面上这种最受欢迎的编排平台。

为何不呢？毕竟，Kubernetes加快了容器部署，还让用户能够管理大规模的多容器集群。它便于持续集成和持续交付，处理网络、服务发现和存储，还能够在多云环境中执行所有这些任务。

一些人会因此称Kubernetes是容器部署和管理领域的“银弹”，但这并不意味着它就没有安全问题。我们在本文中将探讨如果你考虑改用Kubernetes需要注意的几个方面，并介绍了确保你的基础设施在转型期间保持安全的几个提示。

配置错误

我们已经知道，配置错误在云环境司空见惯：我们最近的研究发现，73%的公司至少存在一处关键的AWS安全配置错误。由于容器是软件部署领域一种比较新的技术，因缺乏经验而导致错误配置的风险完全成倍增加。许多企业组织还没有真正了解技术，就采用了像Kubernetes这样的容器编排平台。它们缺乏经验，因而部署时特别容易出现配置方面的错误。

与今天的大多数软件一样，容器面对的是你不想硬编码的私密信息，包括服务密码和API密钥。虽然Docker secrets和HashiCorp Vault等第三方工具能够加密这种敏感信息，但许多Kubernetes用户将依赖Kubernetes自己的机制来执行这项功能。这没有任何问题，只不过任何配置错误可能使你的私密信息暴露无遗。Kubernetes有详细的说明文档，需要仔细阅读、认真遵循，才能避免这类错误。

部署Kubernetes时出现的另一个常见的配置错误是，默认情况下，配置了许多集群，验证令牌自动提供了访问Kubernetes API的机制。配置基于角色的访问控制（RBAC）可以帮助降低风险，但如果该令牌拥有集群管理员权限，可访问单个容器的攻击者就能轻松提升这些权限，从而接管整个集群。这引出了下一个问题……

爆炸半径

在Kubernetes控制的环境中最备受关注的攻击场景之一是爆炸半径（blast radius，即影响范围）这个概念。就像核弹的爆炸半径指遭到破坏的范围那样，Kubernetes控制的部署环境的爆炸半径是指恶意分子能访问的目标离最初的攻击点有多远。

由于一旦容器受到危及，攻击者可以提升权限，从而掌控集群中的其他容器，这个爆炸半径常常有所扩大。因此，部署的任何安全的Kubernetes环境格外重视尽量缩小爆炸半径这项必要任务。

过去的攻击向我们表明，集群的某些部分可能比其他部分更易受到攻击。比如说，黑客找到未受保护的Kubernetes后端数据库（etcd）可能比较容易，只需要搜索Shodan之类的网络爬虫工具。另外，据Kubernetes安全说明文档显示，“对API的etcd后端拥有写访问权相当于获得整个集群的root权限，读取访问权可用来很快提升权限。”非常可怕！

Kubernetes确实拥有调控容器访问权的内置控制机制，有助于限制受危及的容器带来的影响。通过充分利用Kubernetes的隔离机制，比如命名空间和网络分段，可以进一步加强这种隔离。另外建议限制可以在特权模式下运行的容器数量。毕竟，受危及的特权容器造成的破坏程度比受危及的普通容器大得多。

为转型中的基础设施确保安全

除了认真遵循Kubernetes安全文档外，确保Kubernetes安装部署的最佳方法是，尽早将安全纳入到你部署的环境中。（实际上，这是我们在进行各种基础设施转型时给出的建议！）通过正确配置主动保护你的环境比数据泄密发生后试图应对要简单得多，也省钱得多。另外，通过积极主动的监控来充分利用高级的安全运维（SecOps）实践，为你提供了保护日益Serverless的环境所需要的那种可见性。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。