如何应对Kubernetes的安全挑战？

导读：Kubernetes的广泛使用证明了企业的信念，即他们不仅具有处理现代应用程序开发和现代化计划的复杂性的能力，而且具有大规模处理能力。

根据CNCF对各种规模的公司中1340位技术专家的最新调查，有78％的受访者在生产中使用开源容器编排工具。这比去年的58％有所增加。

但是，尽管Kubernetes是GitHub上最受欢迎的项目之一，但许多组织仍对其复杂性感到震惊。

组织已经看到了构建微服务的价值-将应用程序作为离散的功能部分交付，每个部分都可以作为容器交付并单独管理。但是对于每个应用程序，都有更多的部分需要管理，尤其是在规模方面。

Kubernetes通过提供一个可扩展的声明性平台来解决该问题，该平台可自动化容器管理以实现高可用性，弹性和规模。但是，Kubernetes是一个庞大，复杂，快速发展，有时令人困惑的平台，需要用户开发新技能。Kubernetes项目本身最近完成了安全审核。

制定云原生策略（包括应使用哪些平台和工具来确保云原生应用安全部署）的公司可能会从了解Kubernetes的安全挑战中受益，这主要归结为四个方面。

以下是您将面临的挑战，以及缓解这些挑战的建议。

1.强化和合规

使用Kubernetes时，您必须将注意力集中在默认情况下处于打开状态和未打开状态的内容上。例如，pod安全策略是保护多租户群集的关键，但该功能仍为beta，默认情况下未启用。功能丰富的Kubernetes平台可能使理解默认功能具有挑战性，但是弄清楚默认功能是必不可少的。

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

拥有这种类型的分步清单可以大大确保保护像Kubernetes这样复杂的系统。但是，由于安全性始终与风险管理有关，因此组织需要评估某些设置对性能的影响，并权衡风险与收益。

一些组织没有技能或时间独自加强Kubernetes。确保设置和维护集群所需的配置以包括诸如确保始终通过HTTPS始终访问API服务器，使用X.509证书来认证平台组件之间的通信之类的工作，可能是一项艰巨的工作。etcd数据存储已加密。

甚至这个相对较短的清单也不堪重负的组织可能希望考虑已经进行了强化的Kubernetes的商业实现。

2.管理集群上部署的所有工作负载的配置

除了管理群集的配置之外，组织还需要管理群集上运行的所有工作负载的配置。您可以使用开源工具头盔图表来自动执行应用程序供应和配置，以及部署简单或几个独立的服务由复杂的应用程序Kubernetes。

但是，虽然Helm对于管理第1天的操作非常有用，但它并没有扩展到第2天的操作，这正是Kubernetes运营商的亮点。

运营商是打包，部署和管理旨在在Kubernetes上运行的复杂应用程序的一种方式。运营商获取人类操作知识，并将其编码为与应用程序打包在一起并共享的软件。

它们使应用程序开发人员更容易为在Kubernetes上运行的服务提供自动化的生命周期管理。Helm Charts也可以包装在Kubernetes运算符中并一起使用。

在安全性方面，运营商确保在Kubernetes上部署的服务保持受支持的配置。如果对已部署的服务进行了不受支持的配置，则操作员可以将服务重置为其原始的声明配置。

真正有趣的是，您可以使用Kubernetes运营商来管理Kubernetes本身，从而使交付和自动化安全部署变得更加容易。

3.管理多租户集群

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

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

命名空间，当与RBAC（定义如下）和网络策略一起使用时，允许组织隔离同一物理群集中的多个团队。

基于角色的访问控制（RBAC）确定是否允许用户在集群或名称空间内执行给定的操作。为了帮助简化RBAC的使用，请考虑使用默认角色，这些角色可以绑定到整个群集范围内或每个命名空间本地的用户和组。

Kubernetes中的资源配额限制了每个名称空间的总资源消耗，使系统更不容易受到诸如拒绝服务之类的攻击。默认情况下，Kubernetes集群中的所有资源都是使用无限制的CPU和内存请求/限制创建的。

微分段的网络策略指定Pod组之间如何相互通信以及与其他网络端点通信。策略是基于名称空间的。默认情况下，如果在命名空间中未设置任何策略，则允许传入和传出该命名空间中的Pod的流量。

4.平衡安全性和敏捷性

组织不断创新的压力越来越大，这使得将安全性作为事后考虑变得容易。理想情况下，安全性是内置在DevOps周期中的，但是组织可以通过在DevOps中间显式添加“ sec”，或者通过在流水线中构建尽可能多的安全自动化来受益。

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

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

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

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

但这不仅仅是工具。这也与文化和过程有关。理想情况下，这种自我评估工作以及对CI / CD管道的更改是与组织的安全团队协作完成的，从而为开发人员提供了一个学习更多有关安全性的机会，反之亦然。毕竟，安全专业人员短缺，所以让我们共同努力，分散财富。

在您的软件中构建安全功能，可以使您的组织尽可能轻松地实现其安全目标，而不必依赖大量可能协同工作或协同工作的点产品。

看到Kubernetes社区不仅投资于传统的安全评估（例如Kubernetes安全审核），而且还投资于增强安全性的全部功能，这真是太棒了，这些功能包括强化指南，RBAC，pod安全策略，网络策略，服务网格，和运营商。