云计算相关概念

发表于 2025-06-08 分类于 Cloud Security

0x01. 前言

对云计算相关基础概念进行介绍，内容整理自互联网公开资料或 LLM 生成内容。

0x02. 云计算概念

2.1 微服务

与微服务（Micro services）相对应的概念是单体软件（Monolithic software）。单体架构的所有组件紧密耦合，存在更新缓慢、扩展困难、维护困难等诸多问题。

微服务就是采用容器技术的面向服务的架构。它依然使用“服务”作为功能单元，但是变成了轻量级实现，不需要新增服务器，只需要新建容器（一个进程），所以才叫做“微服务”。

一个微服务就是一个独立的进程。 这个进程可以运行在本机，也可以运行在别的服务器，或者在云端（比如云服务和云函数 FaaS）。

它的特点与面向服务架构是一样的，但因为更轻量级，所以功能的解耦和服务化可以做得更彻底。而且，它可以标准化，同样的容器不管在哪里运行，结果都是一样的，所以市场上有很多 SaaS 产品，提供标准化的微服务。

正是由于微服务这些突出的优点，这几年才会变得如此流行。它和容器技术、云服务一起，一定会在未来的软件开发中，扮演越来越重要的角色。

微服务是伴随着容器技术兴起的，服务之间通过 API 进行通信，容器和 API 是微服务的基石。

2.2 虚拟机 & 容器

Hypervisor 分为 Type 1 和 Type 2 两种，前者也称之为裸金属虚拟机（Bare Metal Hypervisor）。

虚拟机 vs 容器

2.3 安全容器

常见的安全容器有 Kata 和 gVisor，其中 Kata 和传统容器的区别如下图所示：

Kata 容器 vs 传统容器

2.4 Docker

Docker 的核心组件包括三个部分：Client、Daemon、Registry，其中 Client 和 Daemon 进程之间基于 REST API 进行通信。

Docker 核心组件

2.5 RESTful API

RESTful API 是当前非常常见的一种数据交换方式，通常以 JSON 来传递数据。

关于 RESTful API 的设计，可以参考文章：RESTful API 最佳实践 - 阮一峰的网络日志。

2.6 容器运行时

容器运行时（Container Runtime）是负责创建、运行和管理容器的软件组件。它是容器化技术的核心，确保容器能够在宿主系统上正确执行。

容器运行时的主要功能

拉取镜像：从容器镜像仓库（如 Docker Hub）下载容器镜像。
创建容器：根据镜像启动容器，并分配必要的资源。
管理生命周期：支持容器的启动、暂停、停止和删除。
资源隔离：利用 Linux 内核的 cgroups 和 namespaces 进行 CPU、内存和网络隔离。
安全控制：提供访问控制、权限管理和安全策略，如 seccomp 和 AppArmor。

常见的容器运行时

Containerd：Docker 的核心组件，专注于稳定性和性能优化。
CRI-O：专为 Kubernetes 设计的轻量级运行时，符合 CRI（Container Runtime Interface）。
runc：底层运行时，负责执行 OCI（Open Container Initiative）标准的容器。
LXC：较早的容器技术，提供完整的 Linux 运行环境。

2.7 容器镜像

容器镜像是不可变的（immutable）。容器镜像是分层的，可以基于其他容器镜像构建新的容器镜像。

容器镜像

可以看出，Docker 容器镜像自下而上的分层结构为：

bootfs，即 Linux Kernel
Dockerfile 的每一条命令都对应一层
- FROM 对应 Base Image
- WORKDIR
- COPY
- RUN
- CMD
最上层的容器层是可写的（R/W），对容器的修改保存在这里，当容器被删除时该层数据也会丢失

2.8 容器镜像扫描

我们需要使用特定的工具对容器镜像进行定期扫描，以发现其中可能存在的漏洞并及时修复。

Trivy 就是这么一款工具，其支持扫描如下问题：

OS packages and software dependencies in use (SBOM)
Known vulnerabilities (CVEs)
IaC issues and misconfigurations
Sensitive information and secrets
Software licenses

所谓 IaC，即 Infrastructure as Code，基础设施即代码。通俗理解：传统的基础设施配置都是认为操作的，现在我们可以使用代码来配置，比如使用 YAML 定义的 K8s 配置文件，不需要人工参与进来，可以实现自动化、版本控制、一致性、安全检查等相关目标。IaC 配置文件可能也存在安全问题，这正是 Trivy 扫描需要关注的问题。

所谓 SBOM，即软件物料清单。通过 SBOM，我们可以知道项目具体使用了哪些软件、组件，以及对应的版本信息等，SBOM 是开源管理、漏洞管理、合规管理、许可管理、供应链安全管理等相关活动的基础输入数据。

与 SBOM 紧密相关的概念是 SCA（Software Composition Analysis），即软件成分分析，两者的区别是：

SBOM is the foundation; SCA is the action.
- SBOM lists all components, but SCA evaluates their security and compliance risks.
SBOM is static; SCA is dynamic.
- SBOM is like an inventory, while SCA continuously scans and alerts on new vulnerabilities.
They complement each other.
- Having an SBOM improves visibility, but using SCA ensures vulnerabilities don’t go unnoticed.

2.9 Namespaces

关于 Namespace 可以阅读如下文章：Docker基础技术：Linux Namespace（上）、Docker基础技术：Linux Namespace（下）。

Namespace 用于空间隔离，支持的类型如下：(这里 UTS 是 Unix Time-Sharing，字面上不是很直观，可以看成是一个过气名词）

分类	系统调用参数	隔离说明
Mount namespaces	CLONE_NEWNS	文件系统挂载点
UTS namespaces	CLONE_NEWUTS	主机名、域名
IPC namespaces	CLONE_NEWIPC	进程间通信
PID namespaces	CLONE_NEWPID	进程 ID
Network namespaces	CLONE_NEWNET	网络
User namespaces	CLONE_NEWUSER	用户、用户组

主要是三个系统调用

clone – 实现线程的系统调用，用来创建一个新的进程，并可以通过设计上述参数达到隔离。
unshare – 使某进程脱离某个namespace
setns – 把某进程加入到某个namespace

2.10 Control Groups (Cgroups)

Cgroups 可以用来限制进程组的的 CPU、内存、磁盘 I/O 等资源，关于 Cgroups 可以阅读如下文章：Docker基础技术：Linux CGroup。

2.11 Capabilities

Capabilities 机制是在 Linux 2.2 之后引入的，用于将之前与超级用户 root(UID=0) 关联的特权细分为不同的功能组，Capabilites 作为线程的属性存在，每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类，具有相似功能的内核调用被分到同一组中。

这样一来，权限检查的过程就变成了：在执行特权操作时，如果线程的有效身份不是 root，就去检查其是否具有该特权操作所对应的 capabilities，并以此为依据，决定是否可以执行特权操作。

Capabilities 可以在进程执行时赋予，也可以直接从父进程继承。

不当的 Capabilities 配置可能导致容器逃逸，比如 CAP_SYS_ADMIN，可以参考 Docker SYS_ADMIN 容器逃逸原理解析。

查看 Capabilities 的工具：

查看进程 cat /proc/<pid>/status
查看进程 getpcaps <pid>
查看文件 getcap <path>

2.12 SELinux

常见的访问控制可以分为两类：

Discretionary access control (DAC)，自主访问控制
- Owner 决定谁可以访问资源，是最常见的访问控制模式
Mandatory access control (MAC)，强制访问控制
- 是一种严格的访问控制模型，主要用于高安全性环境，如政府、军队和金融机构
- MAC 由操作系统或安全策略强制执行，用户无法随意修改权限

Linux 下采用 MAC 机制最主要的案例有：SELinux 和 AppArmor。

The SELinux architecture can be split into four main components.

Firstly, a Subject must request access to take an action. In most cases, the subject is a process that is requesting access to a resource. Access can be controlled via Access Vector Rules, whose details will be presented shortly.

Second, an Object Manager (OM) that controls the access of the subject. It will query the Security Server in order to allow or deny actions.

Security Server—the security server makes decisions based on the Security Policy and returns an answer.

**Access Vector Cache (AVC)**—this is a cache that stores the decisions of the security server in order to speed up performance.

SELinux MAC 架构

2.13 AppArmor

AppArmor 和 SELinux 都是 Linux 内核中的 强制访问控制（MAC） 安全模块，但它们在设计理念和实现方式上有所不同。

AppArmor

基于路径（Path-based）：AppArmor 使用文件路径来定义访问控制策略，而不是文件的元数据。
易于配置：相比 SELinux，AppArmor 的规则更简单，适合普通用户管理。
灵活性：支持“学习模式”（Complain Mode），可以记录违规行为而不阻止执行，方便调试。

SELinux

基于标签（Label-based）：SELinux 使用安全上下文（Security Context）来标记文件和进程，并通过策略强制执行访问控制。
更严格的安全性：SELinux 提供更细粒度的安全控制，适用于高安全性环境（如政府、金融机构）。
复杂性较高：SELinux 需要额外的配置和学习成本，通常由专业管理员维护。

2.14 seccomp

Seccomp（Secure Computing Mode）是 Linux 内核 提供的一种安全机制，用于限制进程可用的系统调用，从而减少攻击面，提高系统安全性。它最初在 Linux 2.6.12 版本中引入，主要用于沙盒化（Sandboxing），防止恶意代码执行未经授权的系统调用。

Seccomp 通过 过滤系统调用 来限制进程的行为，主要有两种模式：

严格模式（Strict Mode）：
- 仅允许进程使用 read、write、exit、sigreturn 这四个系统调用。
- 任何其他系统调用都会导致进程被终止（SIGKILL）。
- 适用于极端受限的环境，如高安全性应用。
过滤模式（Filter Mode，Seccomp-BPF）：
- 允许开发者定义自定义规则，决定哪些系统调用可以执行，哪些需要被拦截。
- 通过 Berkeley Packet Filter（BPF） 进行系统调用过滤。
- 适用于现代应用，如 Docker、Chromium、systemd 等。

Seccomp 的应用场景

容器安全：Docker 和 Kubernetes 使用 Seccomp 限制容器内的系统调用，防止恶意代码影响宿主机。
浏览器沙盒：Chromium 和 Firefox 使用 Seccomp 限制网页进程的系统调用，提高浏览器安全性。
系统服务保护：systemd 使用 Seccomp 限制服务进程的权限，减少攻击面。

2.15 云安全责任共担模型

与传统数据中心相比，云服务商与云服务客户对云及云上资产的可见性不同，云安全工作无法仅由某一方承担完成，云安全责任共担模式成为行业共识。

云安全责任共担模型

2.16 云原生

“云原生”（Cloud Native）是一个专门用于描述软件架构和开发模式的概念，而“云计算”（Cloud Computing）则是一种更广泛的计算资源交付方式。两者关系密切，但关注点不同。

云计算

云计算是通过互联网提供计算资源（如服务器、存储、数据库、网络等）的方式，通常可以分为：

IaaS（基础设施即服务）：提供虚拟机、存储、网络等基础设施（如 AWS EC2、Google Compute Engine）。
PaaS（平台即服务）：提供完整的开发、运行环境，让开发者无需管理底层基础设施（如 AWS Elastic Beanstalk、Google App Engine）。
SaaS（软件即服务）：直接提供可使用的软件应用（如 Google Docs、Dropbox）。

云原生

云原生强调的是如何在云计算环境中构建和运行应用，它包含了一些关键特性：

容器化（Containerization）：通过容器（如 Docker、containerd）确保应用一致性，并提高可移植性。
微服务架构（Microservices）：将应用拆分为多个独立可部署的服务，方便扩展和维护。
动态管理（Dynamic Orchestration）：使用 Kubernetes 或其他编排工具自动管理容器化应用的生命周期。
声明式基础设施（Declarative Infrastructure）：使用 YAML、Terraform 等工具以代码方式管理云资源。

核心区别

类别	云计算	云原生
本质	计算资源交付方式	应用开发和运行方式
范围	包括 IaaS、PaaS、SaaS	主要涉及应用架构设计
技术栈	虚拟机、存储、网络等	容器、微服务、Kubernetes
目标	提供弹性计算资源	让应用具备云环境最佳实践

云原生架构基于以下五个核心要素：

微服务：几乎所有云架构都基于微服务，微服务的关键优势在于可组合性，即将应用分解为一组更小的轻量级服务，而这些服务可通过应用编程接口 (API) 轻松组合并相互连接。例如，一个电子商务应用可能由购物车专用服务、付款服务以及用于与库存管理后端通信的服务组合而成。可组合性还使团队能够切换和重组组件，以满足新的业务要求，而不会中断应用的其他部分。

容器和编排：容器是轻量级的可执行组件，包含在任何环境中运行代码所需的所有元素（包括应用源代码和依赖项）。容器提供工作负载可移植性，支持“一次构建、随处运行”的代码，使开发和部署过程大大简化。由于它们可以独立部署，因此还有助于避免各种语言、库和框架之间的磨合。这种可移植性和灵活性使得容器成为构建微服务架构的理想选择。

此外，随着微服务数量的增加，容器编排也非常重要，可以帮助管理容器，使它们能够作为应用平稳运行。诸如 Kubernetes 之类的容器编排平台可以对容器的运行位置和运行方式进行监督和控制、修复任何故障，以及在各容器之间实现负载均衡。

DevOps：云原生应用的开发需要改为采用像 DevOps 这样的敏捷交付方法，这样，开发者和 IT 运维团队就可以密切协作，自动执行基础设施和软件交付流程。DevOps 使开发和运营团队可以更密切地沟通和协作，实现共同的目标，从而打造出可以更快地构建、测试和发布应用的文化和环境。

**持续集成和持续交付 (CI/CD)**：通过该自动化流程，可以更快地修复、扩缩和部署系统。通过 CI/CD 流水线，可以自动构建、测试和部署应用更改，而无需安排停机时间或等待维护窗口。持续交付可确保软件发布更可靠、风险更低，从而使得团队可以更快速、更频繁地提供新的服务和功能。

2.17 CNCF

CNCF（Cloud Native Computing Foundation，云原生计算基金会）是一个开源、供应商中立的组织，致力于推动云原生技术的发展。它是Linux Foundation的子基金会，成立于2015年，最初由Google捐赠 Kubernetes作为种子项目。

CNCF 的目标：

The Foundation’s mission is to make cloud native computing ubiquitous. The CNCF Cloud Native Definition v1.0 says:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

2.18 Service Mesh

服务网格是一个软件层，用于处理应用程序中服务之间的所有通信。该层由容器化微服务组成。随着应用程序的扩展和微服务数量的增加，监控服务的性能变得越来越困难。为了管理服务之间的连接，服务网格提供了监控、记录、跟踪和流量控制等新功能。它独立于每项服务的代码，这使它能够跨网络边界和多个服务管理系统工作。

服务网格从单个服务中移除控制服务间通信的逻辑，并将通信抽象到自己的基础设施层。它使用多个网络代理来路由和跟踪服务之间的通信。

代理充当组织网络和微服务之间的中间网关。所有进出该服务的流量都通过代理服务器路由。单个代理有时被称为 sidecar，因为它们是分开运行的，但在逻辑上位于每个服务旁边。这些代理一起构成了服务网格层。

K8s Sidecar Pod

服务网格（Service Mesh），作为服务间通信的基础设施层。是轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。

服务网格的演进历程

Sidecar 是容器应用模式的一种，也是在 Service Mesh 中发扬光大的一种模式。使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Sidecar 部署方式中，每个应用的容器旁都会部署一个伴生容器，这个容器称之为 Sidecar 容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源，可以广义的将这个包含了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。

关于 Sidecar 的案例，可以参考：聊聊 K8S 中的 Sidecar 设计模式·第 1 篇。

Sidecar 来源

2.19 声明式 API

命令式：不仅说明要做什么（What），还要说明怎么做（How），机器完全根据指令来操作。

声明式：只需要说明要做什么（What），重点关注结果，就像领导只负责对齐目标，对于员工怎么做理论上不会太过关心。

声明式 API 关注的是“描述目标状态”，而不是具体的操作步骤。例如：

你告诉系统“我要一个 3 节点的 Kubernetes 集群”，而不是手动创建每个节点。
你定义“应用应该运行在 5 个容器实例上”，而不是手动启动 5 个容器。

声明式 API 主要用于基础设施管理（如 Kubernetes、Terraform），它的核心思想是：

状态驱动：用户定义目标状态，系统自动调整以匹配该状态。
幂等性：无论调用多少次，最终状态都是一致的。
自动化：系统会持续检查并修正偏差。

2.20 工作负载

在云计算环境中，工作负载（Workload）指的是运行在云上的应用、服务或计算任务，它们消耗云资源（如计算、存储、网络等）。云计算中的工作负载可以分为多个模式，每种模式都有不同的特征和应用场景。

2.21 DevOps & DevSecOps

DevOps，即开发运维，概述了软件开发过程和组织文化的转变，这种转变促进了开发和 IT 运营团队之间的协调与协作；这两个团队传统上是分开作业，或者各自为战的。

在实践中，最好的 DevOps 开发运维流程和文化超越了开发实践和运营，将所有应用程序利益相关者的意见纳入软件开发生命周期。这包括平台和基础架构工程师、安全、合规、治理、风险管理和业务线团队、用户和客户。

DevOps 开发运维原则代表了过去 20 多年来软件交付流程发展的现状。交付过程已从每隔几个月甚至几年发布一次大型应用程序范围的代码，发展到每天或每天数次发布迭代式较小特性或功能更新。

归根结底，DevOps 开发运维旨在满足软件用户对频繁创新的新功能以及不间断的性能和可用性不断增长的需求。

DevOps 源于敏捷。它增加了新的流程和工具，将 CI/CD 的持续迭代和自动化扩展到软件交付生命周期的剩余部分。整个过程的每一步，开发部门和运营部门都进行了密切协作。

DevOps 循环

DevSecOps 是在软件开发过程的每个阶段集成安全测试的实践。它包括鼓励开发人员、安全专家和运营团队之间协作的工具和流程，以构建既高效又安全的软件。DevSecOps 带来了文化转型，使安全成为开发软件的每个人的共同责任。

The DevSecOps Toolchain

2.22 公有云 / 私有云 / 混合云

在采用云架构时，有三种不同类型的云部署模式可帮助提供云计算服务：公有云、私有云和混合云。

公有云

公有云通过互联网提供计算、存储、网络、开发和部署环境以及应用等资源。它们由 Google Cloud 等第三方云服务提供商拥有和运营。

私有云

私有云由一个组织（通常位于本地）构建、运行和使用。它们可提供更强的控制力度、自定义和数据安全，但也存在与传统 IT 环境类似的成本和资源限制。

混合云

将至少一个私有计算环境（传统 IT 基础设施或私有云，包括边缘）与一个或多个公有云进行混合的环境称为混合云。混合环境可让您利用不同计算环境中的资源和服务，并选择最适合工作负载的资源和服务。

谈到云部署的类型时，您可能也会听到“多云环境”这个词。事实上，行业研究显示，近 90% 的企业现在被视为多云环境，这意味着他们会将来自至少两个不同云服务提供商（无论公有还是私有）的云服务加以结合。采用多云方法可让您更灵活地选择最适合自己特定业务需求的解决方案，同时降低受制于特定供应商的风险。

多云和混合云有时可以互换使用，但混合云方法可被视为多云方法，而前提是它使用了来自多个公有云提供商的服务。