1. 供应层（provisioning）

供给层是云原生全景图中的第一层。它包含一系列的工具，这些工具用于创建和强化构建云原生应用的基础设施。它涵盖了基础设施的从自动化配置，创建和管理到扫描，签名和存储容器镜像的所有内容。该层还通过支持策略设置和强制、嵌入式身份验证和授权以及处理密钥分发的工具来扩展安全性。这太拗口了，我们来逐一讨论一下。

1.1. 自动化与配置（Automation & Configuration）

1.1.1. 是什么？

自动化和配置工具可以加快计算资源(虚拟机、网络、防火墙规则、负载均衡等)的创建和配置。这类工具要么处理配置过程的不同部分，要么试图控制端到端的一切。大多数都提供与该领域的其他项目和产品集成的能力。

1.1.2. 解决什么问题？

传统情况下，IT 流程依赖于漫长且劳动密集型的手工发布，周期通常在三到六个月之间。这些周期伴随着大量的人工流程和控制，减缓了对生产环境的变更。这些缓慢的发布周期和静态环境不符合云原生开发理念。为了实现缩减开发周期快速交付，基础设施必须动态地提供，并且不需要人工干预。

1.1.3. 有什么作用？

这类工具允许工程师在没有人为干预的情况下构建计算环境。通过编辑环境设置，它变得可复制，只需点击一个按钮。虽然手动设置很容易出错，但一旦进行编码，环境创建就会匹配所需的状态 -- 这是一个巨大的优势。

虽然工具可能采取不同的方法，但它们都旨在通过自动化减少提供资源所需的工作。

1.1.4. 技术101

当我们从老式的由人驱动的供应转向由云驱动的新的按需伸缩模型时，我们以前使用的模式和工具就不再满足我们的需求。大多数组织无法负担大量的 7x24 员工来创建、配置和管理服务器。像 Terraform 这样的自动化工具减少了使用数百个防火墙规则来扩展数十个服务器和网络所需的工作量。像 Puppet、Chef 和 Ansible 这样的工具在这些新服务器和应用程序启动时以编程的方式提供和/或配置它们，并允许开发人员使用它们。

一些工具直接与 AWS 或 vSphere 等平台提供的基础设施 API 交互，而其他工具则专注于配置单个机器，使它们成为 Kubernetes 集群的一部分。像 Chef 和 Terraform 一样，许多工具都可以通过互操作来提供和配置环境。其他工具，如 OpenStack，提供了其他工具可以使用的基础设施即服务(IaaS)环境。基本上，您需要在这个领域中使用一个或多个工具，为 Kubernetes 集群准备计算环境、CPU、内存、存储和网络。您还需要其中的一个子集来创建和管理 Kubernetes 集群本身。

现在在这个领域有超过 5 个 CNCF 项目，如果你算上像 Cluster API 这样没有出现的项目，那会更多。还有一系列非常健壮的其他开源和供应商提供的工具。

1.2. 镜像仓库（Container Registry）

1.2.1. 是什么？

在深入研究镜像仓库之前，我们需要定义三个紧密相关的概念:

• 容器（Container） 是 “计算机操作系统管理的具有资源和能力约束的运行进程”(云原生术语)。
• 镜像（Image） 是运行容器及其进程所需的一组存档文件。您可以将其视为一种模板形式，您可以在其上创建无限数量的容器。
• 镜像仓库（Repository，或者简称为repo） 是存储镜像的空间。它是一个专门分类和存储镜像的 web 应用，

让我们快速回顾一下: 镜像包含程序执行所需的全部信息(在容器中)，并存储在镜像仓库中，而镜像仓库又在中央镜像仓库中进行分类和分组。构建、运行和管理容器的工具需要通过引用中央镜像仓库(访问镜像的路径)提供访问信息访问这些镜像。

[!TIP|style:flat] 中央仓库（Registry）：集中存放镜像仓库（Repository）的仓库，对镜像仓库进行分类和分组。

一般说的镜像仓库是存储镜像的功能，而中央仓库是管理镜像仓功能，所以 Harbor 的定位是 Registry 而不是 Repository。一般情况下镜像仓库和中央仓库是在一起提供服务的（如 Harbor），因此两者在中文翻译时一般都叫做仓库，而提及仓库时一般指 Registry。

为了便于理解 Registry 和 Repository，添加如下示例

举例理解 1. 如 nginx:v1.16.0 是一个镜像（image），是由具体的名称和版本组成，由这个镜像可以运行一个或多个 nginx 容器（container）提供 web 服务。 2. nginx:v1.16.0 存储在 nginx 仓库中（repositories），在 nginx 仓库中会包含一个或多个不同版本的镜像。 3. 将 nginx 仓库集中存放在仓库中心（registries）中，如 harbor 里面，那这个 harbor 就是一个仓库中心。仓库中心一般还会将仓库进行分类以便于管理，如 library 分类一般表示该分类下的镜像仓库及镜像都是公开的，如 library/nginx:v1.16.0。

1.2.2. 解决什么问题？

云原生应用程序被打包并作为容器运行。容器仓库存储并提供运行这些应用程序所需的容器镜像。

1.2.3. 有什么作用？

通过将所有容器镜像集中存储在一个地方，任何开发该应用程序的开发人员都可以很容易地访问它们。

1.2.4. 技术 101

容器中央仓库要么存储和分发镜像，要么以某种方式增强现有中央仓库。从根本上说，一个中央仓库是一个 web API，它允许容器运行时存储和查找镜像。许多中央仓库提供了允许容器扫描或签名工具的接口，以增强它们所存储镜像的安全性。有些专门以一种特别有效的方式分发或复制镜像。任何使用容器的环境都需要使用一个或多个中央仓库。

该空间中的工具提供了扫描、签名和检查所存储镜像的集成。Dragonfly 和 Harbor 是 CNCF 的项目，Harbor 最近获得了第一个符合 OCI 标准的的中央仓库的荣誉。每个主要的云提供商都提供自己的托管中央仓库，许多其他的中央仓库可以独立部署，也可以通过 Helm 等工具直接部署到您的 Kubernetes 集群中。

1.3. 安全与合规性（Security & Compliance ）

1.3.1. 是什么？

云原生应用程序被设计为可以快速迭代。想想你的手机应用程序的持续更新——它们每天都在进化，可能会变得更好。为了定期发布代码，您必须确保代码和操作环境是安全的，并且只有经过授权的工程师才能访问。本节中的工具和项目提供了安全构建和运行现代应用程序所需的一些能力。

1.3.2. 解决什么问题？

安全与合规性工具有助于加强、监视和实施平台及应用程序的安全性。从容器到 Kubernetes 环境，这些工具允许您设置策略(为了合规性)，深入了解现有的漏洞，捕获错误配置，并加强容器和集群安全。

1.3.3. 有什么作用？

为了安全地运行容器，必须扫描容器是否存在已知的漏洞，并对其进行签名，以确保它们没有被篡改。Kubernetes的默认访问控制设置非常宽松，不适合生产使用。其结果是:Kubernetes集群对于任何想要攻击您的系统的人来说都是一个有吸引力的目标。该空间中的工具和项目有助于加强集群安全，并在系统行为异常时进行检测。

1.3.4. 技术介绍

• 审计和合规性

• 生产环境的流程：

  • 代码扫描
  • 漏洞扫描
  • 镜像签名校验

• 策略的创建和执行

• 网络层安全

您会发现许多成熟的供应商在这一领域提供解决方案，以及专门为将 Kubernetes 原生框架推向市场而成立的初创公司。在撰写本文时，Falco、 Notary/TUF 和 OPA 都是 CNCF 在这一领域的项目。

1.4. 密钥管理（Key Management）

1.4.1. 是什么？

在深入研究密钥管理之前，让我们先定义加密密钥。密钥是一串用于加密或数据签名的字符。就像物理密钥一样，它锁定(加密)数据，只有拥有正确密钥的人才能解锁(解密)数据。

随着应用程序和操作适应新的云原生世界，安全工具也在不断发展，以满足新的安全需求。这类工具和项目涵盖了从如何安全地存储密码和其他秘密(如API密钥、加密密钥等敏感数据)到如何安全地从您的数据库中删除密码和秘密的所有内容

1.4.2. 解决什么问题？

云原生环境是高度动态的，需要按需分发密钥。这意味着它必须是完全程序化的(没有人参与到过程中)和自动化的。

此外，应用程序需要知道给定的请求是否来自有效的源(身份验证)，以及该请求是否有权执行它试图执行的任何操作(鉴权)。这通常被称为 AuthN 和 AuthZ。

1.4.3. 有什么作用？

每个工具或项目采用不同的方法，但它们都提供了一种方法，可以安全地分发密文（secrets）和 密钥（keys），或者提供与身份验证、授权相关的服务或规范，或者两者都提供。

1.4.4. 技术101

这类工具可以分为两组: 1)密钥生成、存储、管理和轮转，2)单点登录和身份管理。例如，Vault 是一个相当通用的密钥管理工具，允许您管理不同类型的密钥。另一方面，Keycloak 是一种身份代理，可用于管理不同服务的访问密钥。

1.5. 总结：供应层

正如我们所看到的，供应层专注于构建云原生平台和应用程序的基础，使用工具处理从基础设施供应到容器注册到安全的所有事情。接下来，我们将讨论包含云本机存储、容器运行时和网络的运行时层。

1.6. 经验推荐

结合 CNCF 项目的成熟度和实际用户使用场景，在技术选型时可以考虑做如下考虑：

自动化与配置是运维提升效率的核心策略，可以考虑使用 Puppet、Chef、Saltstack 、Rundeck 和 Ansible 这样的工具基于代码版本的方式管理和配置部署（基础设施即代码 IaC），以达到高效和高质量的自动化策略管理的目的，当然也有很多用户直接使用 Shell 来编写自动化工具。其中 Ansible 由于其轻巧便捷无需客户端，可以直接基于 ssh 进行自动化管理，在很多中小规模的项目中得到良好实践效果。此外，KubeEdge 是基于 Kubernetes 对边缘物联网终端等设备进行应用的自动化交付工具。

容器镜像库根据网络环境可以分为公开中央仓库和私有中央仓库，公开有的容器镜像库包括 Docker 官方的 Hub，AWS 的 Elastic Container Registry，Google 的 Container Registry 等。在私有镜像库中，Harbor 得到了广泛的应用，大量的容器平台目前都基于 Harbor 构建其镜像仓库；Dragonfly 也是不错的选择；也有些用户或场景直接使用 Docker 原生的 registry 服务。除此之外，非 CNCF 的开源项目 Nexus 和 JFROG Artifactory 由于其统一的解决方案也得到了不少用户的青睐。

对于安全与合规的技术选型，推荐基于 Notary、Open Policy Agent 与 TUF 进行安全和合规的检查。Notary 和 TUF 是这个领域两个主要的项目，其中 TUF 是一个开源的安全标准，Notary 是其中一个实现。Notary 软件除了确保软件的出处外，它还能保证在未经容器镜像提供者批准的情况下，不会在镜像供应链的任何地方修改镜像内的内容，从而确保从开发到运营的过程中，安全都被无缝统一地嵌入到整个工作流中。 OPA 是一个全场景通用的轻量策略引擎（Policy Engine），它提供了声明式表达的 Rego 语言来描述策略，并将策略的决策 offload 到 OPA，从而将策略的决策过程从策略的执行中解耦。

对于密钥管理的技术选型推荐是 SPIFFE 和 SPIRE 。此部分功能往往作为辅助的定制化内容在其他的自动化和配置中进行了管控，SPIFFE 规范定义了一种标准，通过使用平台无感的加密标识，在云原生环境中对软件服务进行身份验证；SPIRE 是在各种平台上实现 SPIFFE 规范的代码，并对发布身份实施多因素认证。