背景

线上环境使用Kubernetes已经有一段时间，Kubernetes通过提供一个可扩展的声明式平台来管理容器以实现高可用性，弹性和规模。但是Kubernetes是一个大型、复杂的平台；在规模扩大以后，Kubernetes平台自身身的安全问题如何解决？应该采取什么策略来保证应用的安全部署？下面我从四个方面说明如何缓解这些挑战。

Kubernetes安全挑战以及如何应对

强化和合规

使用Kubernetes时，您必须将注意力集中在默认情况下某些配置是否打开？例如，pod安全策略是保护多租户群集的关键，但该功能仍为beta，默认情况下未启用。功能丰富的Kubernetes平台可能会认为默认该功能具有挑战性，但是弄清楚默认功能是必不可少的。

组织可以使用安全性基准来增强Kubernetes的安全性。例如，Internet安全中心提供了配置指南，以加强包括Kubernetes在内的系统以抵抗不断发展的网络威胁。

列举出来Kubernetes集群面临的威胁有哪些？拥有这种清单可以一步一步的解决Kubernetes系统中存在的问题。但是，由于安全性始终与风险管理有关，因此组织需要评估某些设置对性能的影响，并权衡风险与收益。

如果您没有人力或时间独自加强Kubernetes安全性。确保设置和维护集群所需的配置包括确保诸如始终通过HTTPS访问API服务器，使用X.509证书来认证平台组件之间的通信之类的事情、etcd数据存储加密等。

管理好集群上的应用

除了管理集群的配置之外，还需要管理集群上运行的所有应用编排文件。手动编写YAML文件对于大多数人来说并不容易，而且每次手动编写自定义YAML都是不现实的，也可能出现无法预料的问题。在Kubernetes集群中部署应用程序或修改配置设置。Helm图表和Kubernetes Operators通过为管理员提供了一种将应用程序和配置部署到Kubernetes集群中的简便方法。

Helm是Kubernetes的软件包管理系统。使用称为图表(Charts)的打包格式，用户可以将应用程序，比如Kafka或Apache HTTP打包为其他任何人都可以只用几个命令就可以在Kubernetes集群上部署的格式，而几乎不需要手动更改YAML文件。
Operators将应用程序打包为易于部署的格式，但要做的又不止这些。使用Kubernetes自定义资源，管理员还可以在程序包中包含大量复杂的配置。

什么时候应该使用Helm?什么时候使用Kubernetes Operators?其实答案取决于以下几个因素：

如果主要目标是部署应用程序，那么Helm可能是更好的解决方案。另外要考虑定制化，如果正在部署通用应用程序Helm默认设置还可以，那么Helm就足够了。但如果需要特殊配置来实现复杂的自定义配置或部署特殊的应用程序，就可以使用Kubernetes Operators。

多租户方式管理集群

随着Kubernetes集群的扩展，管理部署在集群以及集群本身上的所有的应用变得越来越困难。多租户是处理可能容易变得混乱的最有效方法之一。实际上，Kubernetes对多租户的支持已经走了很长一段路。

关键功能包括以下内容（注意，默认情况下并不总是将其打开）：

命名空间，允许组织与RBAC（以下定义）和网络策略一起使用时，将同一物理集群中的多个团队隔离开来。
基于角色的访问控制（RBAC）确定是否允许用户在集群或名称空间内执行给定的操作。为了帮助简化RBAC的使用，请考虑使用默认角色，这些角色可以绑定到整个群集范围内或每个命名空间本地的用户和组。
Kubernetes中的资源配额限制了每个命名空间的总资源消耗，使系统更不容易受到诸如拒绝服务之类的攻击。默认情况下，Kubernetes集群中的所有资源都是使用无限制的CPU和内存来创建的。
Network policy网络策略指定Pod组之间如何与其他网络端点进行通信。策略是基于命名空间的。默认情况下，如果在命名空间中未设置任何策略，则允许传入和传出该命名空间中的Pod的流量。

安全性和敏捷性的平衡

理想情况下，安全性是内置在DevOps周期中的，但是组织可以通过在DevOps中间显式添加安全操作来受益，说白了就是通过在整个构建过程中减少人为操作，尽可能自动化。

为确保应用开发组织可以实施最佳安全实践，请后退一步并重新访问您的CI/CD管道。他们是否使用自动化的单元测试和功能测试？是否集成了自动安全门限，例如集成的漏洞扫描器？所有人为操作是否添加了审计日志？

通过在开发和生产集群中添加功能，Ops可以为DevSecOps提供帮助，使应用程序开发团队可以轻松地在开发和部署基于微服务的应用程序并以统一的方式监控、告警和日志记录等服务。

此外，向Kubernetes集群添加服务网格似乎增加了复杂性，但目的是使重要的业务逻辑更加可见。以前，开发人员需要在其代码中构建逻辑。现在，这些功能可以作为Kubernetes平台的一部分提供，从而节省了开发人员的工作量并加速了微服务的交付。

服务网格还为开发团队提供了微服务交互的更多可见性，特别是当可观察性和东西集群流量的可视化作为服务网格解决方案的一部分时。

不过实现这个过程也与团对文化及实际使用场景有关。应当严格评估安全性和敏捷性之间的关系并做出折衷。

总结

本文主要介绍了云原生时代安全性挑战，面对这些挑战应该如何解决。另外在做安全性方面的考虑时，应该尽可能使用和参考随时可用的工具和技术，而不是闷头造车；比如Kubernetes社区给我门提供了RBAC、pod安全策略、网络策略、服务网格、operators等安全性方案。欢迎关注公众号、加我微信，一起讨论，谢谢！