作者 |Pavan Belagatti

译者 | 弯月

头图 | CSDN 下载自东方 IC

来源 | CSDN（ID：CSDNnews）

以下为译文：

如果你已经接受了云原生计算的概念和原理，那么代表你已经处于领先地位。在当今先进且竞争激烈的IT环境中，你已经走上了正确的道路。但是，我们需要了解一件事，将开发环境和流程迁移到云原生环境是一项令人望而生畏又充满挑战的工作。任何人都只能建议你从单例应用程序迁移到微服务体系结构，但从哪儿迁移以及如何迁移才是需要分析的关键问题。

对遗留的应用程序进行现代化改造的问题比较棘手。你应该逐步解决问题，首先要对现有的应用程序进行部分或整体的容器化，此时无需采用微服务架构。但接下来，你需要逐步集成现代开发运维和云方法，例如CI/CD、自动化和可观察性等。经过一段时间后，你需要在现有遗留应用程序/服务的基础上添加新的微服务，或者淘汰掉代码库中的单例服务。但这只是迈向云原生的过程中相对比较简单的方面，那么安全性呢？

在本文中，我们将详细地讨论云原生之旅所涉及的安全问题，以及如何解决这些问题。

云原生的起源

大约十年前，Netflix公司首次提出了“云原生”，这是一项关于云和计算的技术。这项技术推动了Netflix的发展，帮助他们从一家邮购公司发展成为了全球最受信任以及最大的消费者按需内容提供商之一。Netflix率先开发了云原生技术，并为所有软件开发的重塑、转型和扩展方面提供了宝贵的经验。

Netflix借助云原生技术，更快地向客户提供更多功能，从那时起，每家与软件打交道的公司都希望借鉴Netflix的云原生技术。云原生能够有效地提高业务速度，并可利用容器、Docker、Kubernetes等云原生技术提供自动化和可扩展性。

云原生之旅

云原生之旅可以归结为三个关键性的决策，而这些决策都可以通过云原生得到解决。

什么是基础设施？

基础设施的基本要求之一是计算机必须具有弹性。此外，基础设施还需要支持其他功能，例如可观察性、可见性、若干托管的服务等。基础设施是一个广泛讨论的话题，我不打算在本文中详细讨论。

选择哪个平台？

云原生平台的选择比较容易，因为基本上Kubernetes已成为运行容器化微服务的默认平台。

如何有效，安全地运行容器化微服务？

这是一个复杂的决定，一般我会推荐Helm。Helm能够帮助你以更简单且可重用的方式安装Kubernetes的服务。以上我推荐的选择都是为了帮助开发人员专注于业务问题，而不必担心平台要求的负担等。

以上就是三个你需要做出的关键决策，而这就是你云原生之旅的起点。

云原生是一段旅程，而不是目的地。

各个公司可以采取多个步骤来推进这段旅程。

云原生的基本原则包括可扩展的应用、弹性架构以及频繁变更的能力。

在这段旅程中，有三个阶段需要注意：

● 第一个阶段：主要面向开发人员、采用容器。

● 第二个阶段：主要面向开发运维、部署应用程序。

● 第三个阶段：主要面向业务（端到端）、智能运营。

Vodafone 在“云原生世界”大会上展示了他们的云原生之旅。

在云原生之旅的中间，Vodafone将“为云做好准备”作为一个中间步骤。

“为云做好准备”的步骤包括向以API为中心转变，自动化应用构建和运行，消除对操作系统的依赖，并通过API实现基础设施即代码（Infrastructure as a Code，即IaaC）。

Vodafone的IT方面似乎比网络方面更成熟。大多数IT功能已经处于“为云做好准备”阶段，但是重新架构VNF以实现容器化，并让它们成为云原生是一项具有挑战性的任务。

云原生之旅面临的共同挑战

保护入口点

保护网络安全是重中之重。拥有一个VPC，使用NAT（NAT用于控制出口，确保没有P地址、节点或对象被泄漏I）。使用RBAC，专用网络等，为了确保每个人都无法访问在Kubernetes集群中运行的API服务器，这些都是必需的。在Kubernetes上运行容器化微服务时，需要使用命名空间。因此，一切都可以归结为监视和控制入口点。

指定机密数据

敏感信息非常重要，因此需要加密，因此我们需要使用机密数据。一个很好模式是在计划或设计Helm Chart时，将机密数据放到外部。然后使用约束，约束是限制集群滥用资源的关键，然后还有安全上下文，它应该是一组指定的策略。最后还有网络策略也是遏制滥用的另一种方式。

掌握微服务

如果你在选定的平台和选定的基础设施上运行微服务，那么可以通过Helm Chart来部署应用程序，从而掌握所有的微服务。有些Pod是单独的，你可以在Pod中建立一个主容器和一个初始化容器，还可以运行一个sidercar。你可以为这些Pod建立多个副本，而且也可以具有依赖项。也许你需要运行一个数据库，也许你需要在同一个集群中运行另一个微服务，而且该依赖项可能也有一个主容器和一个sidercar容器。

可观察性

微服务是云原生架构的基础，但是当你拆分单例应用程序时，可能会创建数十个、甚至数百个微应用程序。这些微应用程序中的每一个都需要进行观察和监视，这是一个很大的挑战。

由于许多微服务都涉及构建现代云原生应用程序，因此快速配置、部署、连续交付、严格的开发运维实践以及整体的监视和可观察性都是必要的。

你可以通过可观察性监视微服务的状况，确保它们的性能和行为。通过工具来掌握系统整体的运行状况和功能非常重要。

自从编程问世以来，日志记录一直被当作可观察性和监视指标的常规方法，但这对于云原生应用程序还不够。

重要的是你能够观察到系统的当前状况。你必须拥有现代化的监视工具SLA，并了解服务水平的稳健程度，以及解决问题和警告的平均时间。

GoCenter、ChartCenter等社区中心都建立了许多微服务。所有这些服务都默认在代码中加入了健康检查，并以此作为提高可观察性的良好实践。

如何以可重复的方式在K8S上部署应用程序？

假设我们在Kubernetes集群上安装了Redis，那么问题就是，我是否可以重用我的安装程序，运行100次，仍然可以获得相同的输出？如果答案是否定的，则表明你的系统存在安全隐患。除了安全问题之外，这也是维护的噩梦。对于微服务，可重用性是关键，而且不知道依赖关系来自何处，那么问题就很严重了。

那么，如何解决这个问题呢？答案很简单：使用包管理器，使用Helm。Helm可以提高可重用性以及可重复性。因此，Helm Chart和Helm Chart的各个版本都可以实现可重复性。

但是，这是真的吗？Helm生态系统是否保证可重复性？

上面提到的是一些严重的问题，并且与安全问题有很多的联系。因此，Helm生态系统虽然有其一定优势，同时也存在严重的弊端。

随着Kubernetes成为企业在云原生世界默认的容器编排平台，Helm可以帮助我们更轻松地重复安装和升级应用程序。尽管“ Kubernetes + Helm”组合是云原生的入门方法之一，但是仍然缺乏安全性，而ChartCenter满足了持续保护云原生生态系统的需求。

ChartCenter可以作为一种解决方案，帮助大家以可重复的方式提供公共的Helm Chart，从而确保云原生生态系统的安全，同时可以遏制日益增长的安全隐患。

ChartCenter可以为公开的K8s应用程序的Helm Chart提供安全可靠的来源。目前还没有标准规定生产者如何与云原生生态系统中的消费者共同承担安全隐患，也没有任何咨询说明。为了解决这个问题，我们提出了一个标准，该标准可帮助生产者使用Helm Chart提供安全缓解信息。

下面是一些ChartCenter的独特之处：

1. 中心存储库可以帮助用户轻松地设置客户端，并保持可追溯性。

2. 高可用性和可扩展性服务保障了可靠的生产服务。不可变性可以更进一步确保你放心地使用Chart，即便作者删除了Chart，你依然可以访问。

3. 出色的搜索功能，能够根据命名空间、名称、描述和标签快速找到合适的Chart。

4. 上游依赖：安装Helm Chart会拉取容器镜像以及其他子Chart，其中可能包含关系到安全和许可证的问题，因此我们不建议你使用被弃用或过时的依赖库。生产部署随时可以接收到这些重要的信息，这一点非常关键。

5. 随着Chart快速地发展，了解谁可能会受到更改的影响有助于增进稳定性和信任度。Chart的作者认为在支持向后兼容性和管理重大更改时，该功能非常有帮助性。

6. 安全扫描：ChartCenter会针对存储库中的1.2万个Docker镜像中包含的1.8M个组件进行连续扫描，这些镜像被3万多个Helm Chart版本引用。

现如今，每家公司都希望以高质量和高可靠性来巩固自家的软件产品。云原生之路让各个公司充满信心，相信他们可以快速地发布高质量的产品。Kubernetes和Helm等平台已经发展了很长一段时间，能够帮助软件公司利用云原生原则的力量，例如现代CI/CD、微服务等。希望本文提到的技术能够帮助你克服重重困难，顺利地完成云原生之旅。

原文链接：

https://dzone.com/articles/securing-your-cloud-native-journey