一、云计算简介

1.1 云计算的基本概念

云计算是一种基于互联网的计算模式，通过虚拟化技术将计算资源（如服务器、存储、网络、软件等）整合成共享资源池，用户可以根据需求随时随地通过网络按需获取和释放这些资源。其核心特点包括弹性扩展（根据业务动态调整资源规模）、按使用付费（仅支付实际消耗的资源）、高可用性（分布式架构保障服务稳定性）以及免运维底层基础设施（由云服务商统一维护）。云计算通过提供基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）等模式，帮助企业和个人降低IT成本、加速创新并实现灵活高效的资源管理。

用通俗易懂的话解释就是：云计算是一种计算模型，它提供了一种通过互联网远程使用共享计算资源的方式。这些计算资源包括计算机处理能力、存储空间、数据库和软件等。这样，用户就可以在需要时随时随地获取这些资源，而不用自己拥有和维护这些硬件和软件。简单来说，**云计算就是在互联网上用别人的电脑来运行自己的程序**。

1.2 云计算的模式

云计算的主要模式可分为服务模式和部署模式两大类：

1.2.1 服务模式（按资源层级划分）

IaaS（基础设施即服务）：提供虚拟化的计算资源（如服务器、存储、网络），用户可自主部署操作系统和应用。示例：AWS EC2、阿里云ECS、腾讯云CVM。
PaaS（平台即服务）：提供应用开发和部署所需的平台环境（如数据库、开发工具、运行环境），用户专注代码编写。示例：Google App Engine、微软Azure App Service。
SaaS（软件即服务）：直接通过互联网使用云端软件，无需安装和维护。示例：Office 365、Salesforce、钉钉。
FaaS（函数即服务/无服务器计算）：以事件驱动方式运行代码片段，按需执行且自动扩缩容。示例：AWS Lambda、阿里云函数计算。
CaaS（容器即服务）：基于容器技术（如Docker、Kubernetes）提供容器化应用的部署与管理平台。示例：Google Kubernetes Engine（GKE）、华为云CCE。

1.2.2 部署模式（按资源归属与管理方式划分）

公有云：资源由第三方云服务商所有并维护，通过互联网开放给公众使用（如阿里云、AWS）。
私有云：资源专供单一组织使用，可部署在本地或第三方数据中心，强调安全可控（如企业自建OpenStack）。
混合云：结合公有云和私有云，实现数据与应用跨云协同（如本地数据库+公有云弹性计算）。
社区云：多个组织共享的云基础设施，服务于特定行业或群体（如政务云、医疗云）。
多云（Multi-Cloud）：同时使用多个公有云服务，避免厂商锁定并优化成本（如AWS+Azure组合）。

核心价值：通过灵活的模式组合，满足不同场景下的成本、安全、性能需求，推动企业数字化转型。

1.3 虚拟化和容器化技术

虚拟化与容器技术是两种主流的资源隔离与部署技术，广泛应用于云计算和现代IT架构中。

公有云和私有云的核心在于最大化利用计算资源，通过虚拟化技术可以将一台物理机转化为多台虚拟服务器。虚拟化技术不可或缺的是虚拟化软件，常见的虚拟化软件包括Vmware和KVM，KVM是一个开源的解决方案，目前在公有云场景中较为常见，并且代表着整个行业的最高水平。

而容器技术是近几年非常热门的一种理念，它代表了兼容性和弹性能力。容器非常轻量级，主要依靠Linux内核的隔离能力。目前有影响力和流行的两个容器产品是Docker和K8S，K8S常常被称为云原生的代名词。

1.3.1 虚拟化技术

1）定义

虚拟化技术通过软件（Hypervisor）在物理服务器上创建多个虚拟机（VM），每个虚拟机拥有独立的操作系统、虚拟硬件（CPU、内存、磁盘等），并能够运行不同的应用程序。物理资源被抽象化后，允许多个虚拟机共享同一台物理机的资源。

2）核心技术

Hypervisor（虚拟机监视器）：

类型1（裸机型）：直接运行在物理硬件上（如VMware ESXi、Microsoft Hyper-V）。

类型2（宿主型）：运行在宿主机操作系统之上（如VirtualBox、VMware Workstation）。

3）优势

资源隔离：每个虚拟机独立运行，避免应用间冲突。

兼容性：支持运行不同操作系统（如Linux和Windows共存）。

硬件利用率：将单台物理机的资源分配给多个虚拟机，降低成本。

4）典型应用

企业数据中心整合服务器资源。开发和测试环境中模拟多系统环境。云计算平台（如AWS EC2、阿里云ECS）的基础设施。

1.3.2 容器化技术

1）定义

容器化通过操作系统内核的隔离机制（如Linux的cgroups和namespaces）创建轻量级的容器。容器共享宿主机的操作系统内核，但拥有独立的文件系统、网络和进程空间，仅打包应用及其依赖。

2）核心技术

容器引擎：Docker是最流行的容器运行时工具。

容器编排：Kubernetes、Docker Swarm等用于管理大规模容器集群。

镜像（Image）：预定义的只读模板，包含应用代码、库和环境配置。

3）优势

轻量高效：无需虚拟化整个操作系统，启动速度快（秒级），资源占用低。

一致性环境：开发、测试、生产环境使用相同镜像，避免“在我机器上能运行”问题。

快速扩展：结合编排工具可实现自动化部署和弹性伸缩。

4）典型应用

微服务架构（如Spring Cloud、gRPC服务）。

持续集成/持续交付（CI/CD）流水线。

云原生应用（如Kubernetes集群、Serverless场景）。

虚拟化 vs. 容器化：核心区别

1.4 云产品的相关概念

阿里云服务器叫ECS，而我们在腾讯云官网看到的云服务器简称为CVM。阿里云对象存储简称OSS，而腾讯云对象存储称COS，所以每个厂商的叫法不同。下面以阿里云为例介绍：

1.4.1 ECS

云服务器ECS（Elastic Compute Service）
实例：云上的虚拟计算服务器，内含vCPU、内存、操作系统、网络、磁盘等基础组件。

1.4.2 SLB

云负载均衡（Server Load Balancer，简称SLB）是云原生时代应用高可用的基本要素。通过对多台云服务器进行均衡的流量分发调度，消除单点故障提升应用系统的可靠性与吞吐力。

1.4.3 OSS对象存储

对象存储（Object Storage Service），是阿里云对外提供的海量、安全和高可靠的云存储服务。
RESTFul API 的平台无关性，容量和处理能力的弹性扩展，按实际容量付费真正使您专注于核心业务。
Web应用资源、提供数据下载等

1.4.4 安全组

安全组是一种虚拟防火墙，具备状态检测和数据包过滤功能，用于在云端划分安全域。
同一安全组内的ECS实例之间默认内网网络互通。

1.4.5 RDS（云数据库）

关系型数据库服务（Relational Database Service，简称 RDS）是一种稳定可靠、可弹性伸缩的在线数据库服务。
RDS 采用即开即用方式，兼容 MySQL、 SQL Server 两种关系型数据库，并提供数据库在线扩容、备份回滚、性能监测及分析功能。
RDS 与云服务器搭配使用 I/O 性能倍增，内网互通避免网络瓶颈。

1.4.6 VPC

专有网络VPC（Virtual Private Cloud）是用户基于阿里云创建的自定义私有网络, 不同的专有网络之间二层逻辑隔离，用户可以在自己创建的专有网络内创建和管理云产品实例，比如ECS、SLB、RDS等。
https://help.aliyun.com/document_detail/34217.html

1.4.7 RAM

访问控制RAM（Resource Access Management）是阿里云提供的管理用户身份与资源访问权限的服务。
RAM允许在一个阿里云账号下创建并管理多个身份，并允许给单个身份或一组身份分配不同的权限，从而实现不同用户拥有不同资源访问权限的目的。

1.4.8 AccessKey

阿里云用户可以在管理控制台里自行创建 Access Key，Access Key是由AccessKey ID 和 AccessKey Secret 组成。
其中 ID 是公开的，用于标识用户身份，Secret 是秘密的，用于用户鉴别。
当用户向 OSS 发送请求时，需要首先将发送的请求按照 OSS 指定的格式生成签名字符串；
然后使用 AccessKey Secret 对签名字符串进行加密（基于HMAC 算法）产生验证码。
验证码带时间戳，以防止重放攻击。
OSS 收到请求以后，通过 AccessKey ID 找到对应的 AccessKey Secret，以同样的方法提取签名字符串和验证码，如果计算出来的验证码和提供的一样即认为该请求是有效的；否则，OSS 将拒绝处理这次请求，并返回 HTTP 403 错误。

1.5 云原生

云原生（Cloud Native）是一种基于云计算环境设计和运行应用的方法论，旨在充分发挥云计算的弹性、敏捷性和可扩展性，通过现代化技术栈和架构理念，帮助开发者快速构建、高效运维和持续迭代应用。

1.5.1 核心要素

云优先设计：
- 应用从设计阶段就围绕云平台特性（如弹性资源、分布式架构）构建，而非简单迁移传统应用到云上。
核心技术栈：
- 容器化：用Docker等工具打包应用及依赖，确保环境一致性。
- 容器编排：通过Kubernetes自动管理容器集群的部署、扩缩容和故障恢复。
- 微服务：将单体应用拆解为独立的小型服务，提升灵活性和可维护性。
- 服务网格（Service Mesh）：用Istio等工具管理服务间通信，增强安全性和可观测性。
- 无服务器（Serverless）：按需运行代码（如AWS Lambda），无需管理服务器。

云原生是云计算时代的“最佳实践”，通过容器化、微服务、自动化等技术，帮助企业构建弹性、可扩展、高可用的现代应用体系，加速数字化转型。其核心不仅是技术升级，更是组织流程和文化向敏捷、协作的转变。

二、什么是云安全

云安全是为保护云计算环境中的数据、应用和基础设施而采取的综合防护措施，涵盖技术、策略与管理流程，其核心在于共享责任模型 ——云服务商负责底层物理安全，用户则需保障自身数据、访问权限及应用安全。通过数据加密（静态与传输中）、身份认证（如多因素验证）、网络隔离（VPC、防火墙）以及持续监控（日志审计、入侵检测）等手段，云安全旨在防御数据泄露、DDoS攻击、账户劫持等威胁，同时确保符合GDPR、HIPAA等合规要求。面对配置错误、新兴技术风险等挑战，企业需结合自动化工具（如CSPM）、零信任架构和容灾备份，构建动态防护体系，将安全嵌入云架构的每一环节，以保障业务连续性与数字资产可信。

2.1 云安全与传统安全的区别

云安全与传统安全的核心区别主要体现在以下几个方面，涵盖责任模型、技术架构、威胁场景及防御策略等关键维度：

2.1.1 责任模型：从「全权负责」到「共享责任」

传统安全：企业需独立承担所有安全责任，包括物理服务器、网络设备、操作系统、应用和数据等全层级防护（如自建机房防火墙、入侵检测系统）。
云安全：遵循共享责任模型（Shared Responsibility Model）：

云服务商（如AWS、阿里云）负责底层基础设施安全（物理硬件、虚拟化层、网络骨干等）。

用户负责自身数据、应用、访问权限及云资源配置安全（如管理虚拟机防火墙、加密敏感数据）。

典型案例：在AWS EC2中，AWS保障Hypervisor和物理服务器的安全，用户需自行配置安全组规则和IAM权限。

2.1.2 防护边界：从「固定边界」到「动态无边界」

传统安全：依赖物理网络边界（如企业内网），通过防火墙、VPN等设备构建静态防御体系，默认信任内部流量。
云安全：无固定边界，需应对动态、分布式环境：
- 多租户资源共享：防范跨租户攻击（如侧信道攻击、容器逃逸）。
- 微服务与API驱动：保护API网关、Serverless函数等无服务器组件的安全。
- 零信任架构：基于身份和最小权限原则的动态访问控制，替代传统网络信任机制。

2.1.3 技术手段：从「硬件依赖」到「云原生工具」

传统安全工具：以硬件设备为核心（如物理防火墙、入侵检测硬件），手动配置策略，更新周期长。
云安全技术：
- 自动化合规检查：利用CSPM（云安全态势管理）工具（如Prisma Cloud）实时扫描云资源配置风险（如公开的S3存储桶）。
- 原生加密服务：集成云平台的密钥管理服务（如AWS KMS、Azure Key Vault），替代本地HSM硬件。
- 容器与Serverless安全：扫描容器镜像漏洞（如Docker镜像中的CVE漏洞），限制Lambda函数的执行权限。

2.1.4 威胁场景：从「本地攻击」到「云原生风险」

传统威胁：物理设备入侵、内网渗透、DDoS攻击本地服务器等。
云特有风险：
- 配置错误：如公有云存储桶（如AWS S3、阿里云OSS）误设为公开访问，导致数据泄露（如Capital One事件）。
- 跨云攻击：攻击者利用多云环境的复杂性横向移动（如通过泄露的Access Key跨区域攻击）。
- 虚拟化逃逸：利用Hypervisor漏洞（如CVE-2021-2832）突破虚拟机隔离，影响宿主机。
- 供应链攻击：通过第三方镜像市场或开源库（如Log4j漏洞）污染云环境。

2.1.5 合规与弹性：从「静态合规」到「动态适配」

传统合规：聚焦本地基础设施的静态审计（如机房物理安全、内网日志留存），周期长且成本高。
云安全合规：
- 多地域法规适配：需满足数据跨境存储的合规要求（如GDPR对欧盟用户数据的本地化限制）。
- 弹性扩展同步：安全策略需随云资源自动扩缩容动态调整（如Kubernetes集群扩缩时自动更新安全组规则）。
- 自动化审计：依赖云平台提供的日志工具（如AWS CloudTrail、Azure Monitor）实现实时监控。

2.2 公有云平台介绍

阿里云、腾讯云、京东云、青云、华为云
Amazon-AWS（Amazon Web Services (AWS) ）
Azure

2.3 ATT&CK更新了有关云攻击的TTP

应用程序访问令牌 - T1527
云实例元数据API - T1522
云服务仪表板 - T1538
云服务发现 - T1526
云存储对象 - T1530
配置不当泄漏
S3权限配置不当
安全组配置不当
IAM权限配置不当
等等

三、公有云攻防

3.1 弹性计算服务攻防

阅读产品文档、阅读架构文档、了解相关操作手册，了解产品功能模块。

常规渗透一样子域名查找、端口扫描、目录扫描、指纹识别等，在查找的过程中留意AccessKey等密钥（APK文件、Github关键词、Web页面、JS文件、常规配置文件）。

云主机的应用漏洞（SSRF、RCE、本地文件读取等常规漏洞）。

云产品的默认配置：

OSS文件存储服务，默认设置为开放，导致文件任意下载
端口默认对外0.0.0.0/0公网开放

3.1.1 AccessKey泄漏利用

渗透场景：

APK文件中存放Access Key；
Web页面/JS文件/phpinfo中包含Access Key等;
Github查找目标关键字发现AccessKey与AccessKey Secret；
拥有WebShell低权限的情况下搜集阿里云Access Key利用；

获取到AccessKey之后使用行云管家直接导入，获取OSS数据。可直接获取阿里云主机进行重置密码等操作。

。。。。【未完待续】

四、云原生攻防

4.1 什么是云原生

云原生是一套技术体系和方法论。

云：表示应用程序位于云中
原生：表示应用程序从设计之初就考虑到云的环境，原生为云而设计，在云上以最佳状态运行，分利用和发挥云平台的弹性和分布式优势。

云原生代表的技术包括：容器、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施和声明式API。

CNCF（Cloud Native Compute Foundation）是 Linux 基金会旗下的一个组织，主要作用是在推动以容器为中心的云原生系统。

上图是一张云原生的全景图，共分为六层：

4.1.1 供应层

为云原生应用准备标准基础环境所涉及的工具，包括了基础设施的创建、管理、配置流程的自动化、容器镜像扫描、签名和存储等。
提供设置和实施策略，在应用程序和平台中构建身份验证、授权、处理密钥分发等。

4.1.2 运行层

在CNCF全景图中，运行时是保障了容器化应用程序组件的运行和通信，云原生存储、提供隔离、资源和安全、云网络。

4.1.3 编排和管理层

为云原生应用提供自动化和弹性能力，使云原生应用天然具有可扩展性。
提供编排和调度、协调和服务发现、远程进程调用（RPC）、服务代理、API网关、

4.1.4 应用程序定义和开发层

提供数据库、流和消息传递、应用程序定义和镜像构建、持续集成和持续交付（CI/CD）

4.1.5 平台层

将不同工具捆绑解决问题

4.1.6 贯穿所有层

云原生全景右侧贯穿所有层的两列，可观察性和分析是监控各层的工具。
日志工具、监控方案、追踪工具、混沌工程

最底层提供了构建云原生基础设施的工具，越往上的每一层都更接近实际的应用程序。

而Kubernetes是整个云原生技术栈的核心

4.2 什么是云原生安全

4.2.1 云原生安全架构

云原生安全自底向上，分别由硬件安全（可信环境）、宿主机安全、容器编排技术安全（Kubernetes等）【可以看作是云上的“操作系统”，它负责自动化部署、扩缩容、管理应用等】，再由微服务安全、Service Mesh安全、容器安全（Docker等）、容器镜像（仓库）安全组成。以这些技术为基础构建出云原生安全。

4.2.2 CNCF的云原生安全体系—4”C”

代码级安全、容器级安全、集群级安全、站点级安全。

4.3 Kubernetes基础

Kubernetes 是 Google 基于 Borg 开源的容器编排调度引擎，作为 CNCF最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes 可以帮你将系统自动得达到和维持在这个状态。Kubernetes 一词来自希腊语，意思是“飞行员”或“舵手”。这个名字很贴切，Kubernetes 可以帮助你在波涛汹涌的容器海洋中航行。

Kubernetes 提供了一种自动化部署、扩展、和管理容器化应用的机制，使开发者能够高效地构建、和运行分布式系统。K8S的核心作用：是对容器进行编排，确保容器化应用，比如：Docker…..等容器，能够在集群中高效运行。下面是使用k8s部署容器的用法示例：

K8S提供智能的容器调度功能，能根据资源需求、策略和约束条件将容器调度到合适的节点上运行。
K8S还能够自动管理和协调多个容器的生命周期，使得应用能够平稳运行、扩展、和升级。

K8S的这些功能，使其成为现代云原生应用开发和部署的核心工具，应用于大规模的企业、和开发团队。

4.3.1 k8s架构

K8S的架构和它的原型项目Borg非常类似，都由 Master 和 Node 两种节点组成，这两种角色分别对应着：控制节点和计算节点。

Master节点负责：全局管理和调度，Node 节点负责具体的容器运行和资源管理。

Kubernetes的核心组件部署在Master管理节点上，主要作用是作为Kubernetes的大脑，控制整个分布式集群的运转，Node节点作为四肢，执行Master的操作指令。

4.3.1.1 master节点

Master 节点是 K8S集群的控制中心，负责管理、和调度集群中的所有资源。Master类似人的大脑，负责指挥Node节点来调度。主要负责，如下内容：

1、集群管理

首先，管理集群的状态、配置和生命周期。

其次，维护集群的元数据，确保集群的整体健康状态。

2、API 服务

提供集群的 API 接口，处理来自用户和内部组件的请求。

3、资源调度

根据资源需求和调度策略，将工作负载（Pod），分配到适当的节点上运行。

4、监控集群

监控集群状态，确保实际状态与期望状态一致。以及处理自动化任务，如：副本管理、故障恢复…等。

Master节点的整体架构，如下图(黄框)所示：

Master 节点在 K8S集群中起着至关重要的作用，它通过 kube-apiserver 提供集群的 API 服务，通过 kube-scheduler 进行资源调度，通过 kube-controller-manager 进行控制管理，并使用 etcd 来存储集群的配置数据、和状态信息。

从上图左侧黄框的Kubernetes主节点可以看出，Master 节点由4个独立的组件组成，它们分别是：

1）apiserver：负责整个集群通信的 API 服务

API Server的主要负责整个集群通信的 API 服务，API Server是Kubernetes控制程序的前端，也是用户唯一可以直接进行交互的Kubernetes组件。作为集群管理的API入口，为资源对象（比如：Pod、Service、Deployment）提供创建、认证、数据校验、状态变更等操作。

大致工作流程，如下:

Client --> [kube-apiserver] --> [etcd]

首先，apiserver ，负责接收请求，比如刚才提到的：创建、更新、删除 Pod……..等等操作。

其次，kube-apiserver 将接收到的请求验证和授权后，将数据写入 etcd(Key-Value）存储。

然后，其他组件，如：kube-scheduler 和 kube-controller-manager，通过监听 API Server 来获取最新的集群状态。

2）键值存储etcd

Etcd是一种K-V存储仓库，Etcd是Kubernetes集群中的一个十分重要的组件。Etcd主要用于保存集群所有的网络配置和对象的状态信息，无论是创建Deployment，还是创建Service，各种资源对象信息都会写入Etcd。

[kube-apiserver] <--> [etcd Cluster]

提供数据的一致性和高可用性。

比如：数据一致性，使用 Raft 共识算法，来保证数据一致性。

再比如：高可用性，etcd 的高可用性通过部署多个副本实现，通常是奇数个节点，来保证高可用性。

3）ControllerManager

kube-controller-manager 是 Kubernetes 集群管理的最核心组件，通过运行多个控制器来维持集群的期望状态。

负责管理 K8S集群中的控制器，这些控制器通过监控集群状态并进行相应的调整，确保集群处于预期的状态。

Controller Manager是Kubernetes的大脑，由一系列控制器组成，如下图所示：

Controller Manager主要包含以下8大组件：

Replication Controller：主要是保证集群中一个Replication Controller (RC) ，所关联的 Pod 副本数始终保持为与预设值一致；

确保指定数量的 Pod 副本始终运行，比如：如果有 Pod 异常终止、或被删除，ReplicaSet 控制器会创建新的 Pod 来补充。

Node Controller：Node Controller 通过 API Server 实时获取 Node 的相关信息，实现管理和监控集群中的各个 Node 节点；

负责：监控节点的健康状态，并在节点失效时执行恢复操作。

比如：标记节点为不可调度或不可用，并重新调度受影响的 Pod。

ResourceQuota Controller：资源配额管理控制器，用于确保指定的资源对象在任何时候都不会超量占用系统上物理资源；

管理 Deployment 对象，支持滚动更新、和回滚操作。

Namespace Controller：用户通过 API Server 可以创建新的 Namespace 并保存在 Etcd 中；
Service Account Controller：服务账号控制器，主要在命名空间内管理 ServiceAccount，以保证名为 default 的 ServiceAccount 在每个命名空间中存在；
Token Controller：令牌控制器主要用作：监听 serviceAccount 的创建和删除动作，以及监听 secret 的添加删除动作；
Service Controller：服务控制器主要用作：监听 Service 的变化；

管理 Service 对象，确保服务的 IP 地址、和端点正确配置。

比如：处理服务发现和负载均衡，确保客户端请求能够正确路由到对应的 Pod。

总之，这些控制器负责：管理集群中的各种资源。

从 Pod 副本的管理，到节点健康状态的监控，再到服务发现、和负载均衡。

从而，确保 Kubernetes 集群能够高效、稳定地运行。

Endpoint Controller：负责生成和维护所有 Endpoints 对象的控制器；

Controller Manager主要用于：实现 Kubernetes 集群故障检测，监控整个集群的状态，以及恢复的自动化工作。

4）scheduler：负责容器调度

Scheduler是Kubernetes的调度器，Scheduler 是负责整个集群的资源调度的。Scheduler：根据资源需求和调度策略，将新创建的 Pod 分配到适合的节点上运行。

Scheduler调度程序会监视来自API Server的新请求，并将其分配给运行状况良好的节点，比如：对节点的质量进行排名，并将Pod部署到最适合的节点。

[kube-scheduler] <--> [kube-apiserver] --> [Node]

4.3.1.2 worker节点

上图右侧的绿框就是Kubernetes工作节点，包含如下组件：

1）Kubelet

kubelet 是负责容器真正运行的核心组件，kubelet 是 Master 和 Node 之间的桥梁，接收 API Server 分配给它的任务并执行。

Kubelet 是运行在每个 Node 上的主要组件，负责：管理和维护 Node 上的 Pod。

它确保 Pod 根据 Kubernetes API Server 的定义正确地启动和运行。

2）Container Runtime

Container Runtime基于gRPC协议，定义了RuntimeService和ImageService两个gRPC服务，分别用于管理容器运行和镜像。

Container Runtime，也就是容器运行时，负责：容器的实际启动和管理。

比如，提供容器化的运行环境，如 Docker。

gRPC协议
gRPC（ gRPC Remote Procedure Call ）是一种高性能、开源的远程过程调用（RPC）框架，由Google开发并基于HTTP/2协议实现。它默认使用 Protocol Buffers （Protobuf）作为接口定义语言（IDL）和数据序列化工具，通过预定义服务接口和消息格式，实现跨语言、跨平台的高效通信。gRPC支持四种通信模式（单一请求-响应、服务端流、客户端流、双向流），利用HTTP/2的多路复用、头部压缩等特性降低延迟，适用于微服务间的高吞吐、低延迟交互（如内部API、实时数据传输），并原生提供身份验证、负载均衡和超时控制等能力，是云原生场景中替代传统REST API的流行方案。

CRI
CRI（Container Runtime Interface）

定义：CRI是Kubernetes定义的一个插件接口（基于gRPC协议），用于解耦Kubernetes组件（如kubelet）与底层容器运行时。它允许不同的容器运行时无缝集成到Kubernetes中。

功能：定义了一组标准API，用于管理容器的生命周期（创建/启动/停止容器）和镜像管理（拉取/删除镜像）。支持多种容器运行时实现（如containerd、CRI-O、Docker Engine等），赋予用户灵活选择的能力。

优势：通过抽象化接口，Kubernetes无需依赖特定运行时（如早期的Docker），推动了容器生态的多样化和标准化。

3）Kube-proxy

kube-proxy 是为了解决外部网络能够访问集群中容器提供的应用服务而设计的，Proxy 运行在每个Node 上。

kube-proxy确保每个节点都获得其IP地址，实现本地iptables和规则以处理路由和流量负载均衡。

Kube-Proxy 是每个Node上运行的网络代理，负责维护网络规则。

主要解决，如下4点：

负载均衡：

Kube-Proxy 在每个 Node 上，配置网络规则，将流量负载均衡到多个 Pod 上；

例如，当请求到达 Service 的 Cluster IP 时，Kube-Proxy 会将请求转发到后端 Pod。

网络规则管理：

Kube-Proxy 在 Node 上设置 IP 规则和路由规则，以实现服务发现和负载均衡。

服务发现：

Kube-Proxy 处理 Service 的 IP 地址和端点更新，确保流量能够正确路由到 Pod。

集群网络：

Kube-Proxy 支持多种网络模式（如：iptables、ipvs。。。），管理 Node 上的网络流量，并保持网络规则的同步。

4）Pod

Pod是Kubernetes中一个抽象化概念，由一个或多个容器组合在一起得共享资源，如下图所示：

Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

在Kubernetes中，Pod是调度的最小元素，没有它容器就不能成为集群的一部分，主节点会把Pod调度到特定工作节点上，并与容器运行时协调以启动容器。

Pod是Kubernetes最重要也是最基本的概念，一个Pod是一组共享网络和存储（可以是一个或多个）的容器。Pod中的容器都是统一进行调度，并且运行在共享上下文中。一个Pod被定义为一个逻辑的host，它包括一个或多个相对耦合的容器。Pod的共享上下文，实际上是一组由namespace、cgroups, 其他资源的隔离的集合，意味着Pod中的资源已经是被隔离过了的，而在Pod中的每一个独立的container又对Pod中的资源进行了二次隔离。

4.3.2 工作流程

K8S工作流程：

1.集群初始化

首先，安装和配置Master和Node节点。

2.应用部署

使用kubectl命令行工具或其他工具（如Helm）部署应用。

定义Deployment、Service等资源对象，并通过API Server提交到集群。

3.调度和运行

Scheduler根据调度策略，将Pod分配到合适的Node节点。

Kubelet在Node节点上创建和管理Pod，确保容器按照定义运行。

4.服务发现和负载均衡

Kube-proxy设置网络规则，确保服务能正确访问和负载均衡；

Service对象提供统一的访问入口、和负载均衡。

5.监控和自动化

Controller Manager持续监控集群状态，进行自动扩展和恢复操作。

使用Prometheus、Grafana等工具监控集群和应用状态。

4.3.3 核心概念

集群（Cluster）

Kubernetes集群由一组节点（Node）组成，包含一个Master节点（控制平面）和多个Worker节点（工作节点），共同协作运行容器化应用。

节点（Node）

Master节点：负责集群管理，包含API Server、Scheduler、Controller Manager、etcd等组件。

Worker节点：运行容器，包含kubelet（管理Pod）、kube-proxy（网络代理）和容器运行时（如Docker）。

Kubernetes的最小调度单元，包含一个或多个共享存储/网络的容器。适用于需要紧密协作的应用（如主容器+Sidecar）。

控制器（Controller）

Deployment ：管理无状态应用，支持滚动更新、回滚和副本数维持。

StatefulSet ：适用于有状态应用（如数据库），提供稳定的网络标识（Pod名称、IP）和持久化存储。

DaemonSet ：确保每个节点运行指定Pod（如日志收集Agent）。

Job/CronJob ：执行一次性任务或定时任务。

服务（Service）与Ingress Service ：

通过标签选择器关联Pod，提供稳定的IP和DNS，支持负载均衡。

Ingress：管理外部访问（HTTP/HTTPS路由），需配合Ingress控制器（如Nginx、Traefik）使用。

配置与存储 ConfigMap/Secret ：

分别存储配置信息和敏感数据（如密码），通过卷或环境变量注入Pod。

PersistentVolume（PV）：集群级存储资源。

PersistentVolumeClaim（PVC）：用户对存储的请求，与PV动态或静态绑定。

4.3.4 架构组件

Master组件

API Server ：集群操作入口，处理REST请求。

Scheduler ：调度Pod到合适的节点。

Controller Manager ：运行控制器（如Deployment控制器）确保期望状态。

etcd ：分布式键值存储，保存集群状态。

Worker组件

kubelet ：与API Server通信，管理节点上的Pod。

kube-proxy ：维护节点网络规则，实现Service的负载均衡。

容器运行时：如Docker、containerd，负责运行容器。

组件图示

API Server：资源操作唯一入口，提供认证、授权、访问控制、API注册等机制。
etcd：保存集群状态信息。
Controller Manager：维护集群状态，故障检测、自动扩展、滚动更新。
Scheduler：资源调度，按照调度策略将Pod调度相应机器上。
kubelet：维护容器生命周期，Volume、网络的管理
Container runtime：镜像管理以及Podcast容器运行
kube-proxy：为Service提供cluster内部服务发现、负载均衡
kube-dns：为集群提供DNS服务
Ingress Controller：提供外网入口
Heapster：资源监控
Dashboard：GUI操作界面
Federation：跨可用区的集群
Fluentd-elasticsearch：集群日志采集、存储与查询

4.3.5 k8s的资源类型

在 Kubernetes（k8s）中，资源类型（Resource Types） 是集群中可管理的对象，用于定义应用、服务、存储、网络等不同维度的配置和状态。

1）核心工作负载型资源

Pod
- 最小部署单元，包含一个或多个容器（如应用容器、Sidecar）。
- 生命周期短暂，通常由控制器（如 Deployment）管理。
Deployment
- 管理无状态应用的副本（Replica），支持滚动更新和回滚。
- 通过 ReplicaSet 控制 Pod 的副本数量。
StatefulSet
- 管理有状态应用（如数据库），提供稳定的网络标识（Pod 名称、DNS）和持久化存储。
DaemonSet
- 确保每个节点（Node）运行一个 Pod 的副本（如日志收集、监控 Agent）。
Job
- 运行一次性任务（如批处理作业），任务完成后 Pod 终止。
CronJob
- 定时执行 Job（如每天备份数据库）。
Pod 是 Kubernetes 中最小的运行单元，用于托管一个或多个容器，适用于临时任务或长期服务，但自身不保证任务成功，需配合控制器管理；Job 是专为一次性任务设计的控制器，确保 Pod 运行到任务成功完成（自动重试失败任务），适合批处理作业或需状态跟踪的场景，任务结束后保留记录供查询。

2）服务与网络资源

Service
- 为 Pod 提供稳定的访问入口（ClusterIP、NodePort、LoadBalancer）。
- 通过标签（Label）选择后端 Pod。
Ingress
- 管理外部 HTTP/HTTPS 流量的路由规则（如域名、路径转发）。
- 需配合 Ingress Controller（如 Nginx、Traefik）使用。
EndpointSlice
- 记录 Service 后端 Pod 的 IP 地址和端口。
NetworkPolicy
- 定义 Pod 之间的网络通信规则（白名单）。
。。。

4.4 k8s的攻击面

Pod开放到互联网
Pod对其它Pod或服务开放
从Pod向Node逃逸
从Pod攻击Master Node组件
从Pod攻击API Server
从API Server攻击其它Pods/Nodes
从K8s集群攻击云内的其它服务

4.5 k8s云原生攻防攻击路径

4.6 k8s常见端口

4.5 CRI-O引擎逃逸（CVE-2022-0811）

【Kubernetes CRI-O引擎逃逸CVE-2022-0811】

4.5.1 CRI-O 概述

定义：

CRI-O 是一个专为 Kubernetes 设计的轻量级容器运行时，遵循 Kubernetes 容器运行时接口（CRI）规范。它由 Red Hat 主导开发，旨在仅支持 Kubernetes 所需的容器管理功能，简化了传统容器运行时（如 Docker）的复杂性。

目标：

仅实现 CRI 规范，专注于 Kubernetes 的容器生命周期管理。兼容 OCI（Open Container Initiative）标准和 Docker 镜像格式。支持多种文件系统（overlay、aufs、Btrfs）和 CNI 网络插件。

4.5.2 CRI-O 的架构与工作原理

1）核心组件

CRI-O Daemon

接收来自 Kubernetes（通过 kubelet）的容器操作请求（如创建、删除容器）。

使用 containers/image 库拉取镜像，并通过 containers/storage 存储镜像层。

OCI 运行时工具

生成符合 OCI 标准的容器配置文件（ config.json ）。

默认使用 runc 作为底层运行时启动容器。

conmon 进程

监控容器进程，处理日志记录和退出代码。

CNI 网络插件

通过容器网络接口（CNI）为容器配置网络。

2）工作流程

Kubernetes 请求启动 Pod → kubelet 通过 CRI 接口转发请求至 CRI-O。

CRI-O 拉取镜像并解压到文件系统 → 生成 OCI 规范文件。

调用 runc 启动容器 → conmon 监控容器进程。

CNI 插件配置容器网络。

Kubernetes 通知 kubelet 启动一个 pod。
kubelet 通过 CRI(Container runtime interface) 将请求转发给 CRI-O daemon。
CRI-O 利用 containers/image 库从镜像仓库拉取镜像。
下载好的镜像被解压到容器的根文件系统中，并通过 containers/storage 库存储到 COW 文件系统中。
在为容器创建 rootfs 之后，CRI-O 通过 oci-runtime-tool 生成一个 OCI 运行时规范 json 文件，描述如何使用 OCI Generate tools 运行容器。
然后 CRI-O 使用规范启动一个兼容 CRI 的运行时来运行容器进程。默认的运行时是 runc。
每个容器都由一个独立的 conmon 进程监控，conmon 为容器中 pid 为 1 的进程提供一个 pty。同时它还负责处理容器的日志记录并记录容器进程的退出代码。
网络是通过 CNI 接口设置的，所以任何 CNI 插件都可以与 CRI-O 一起使用。