📚 课程目录第4章云工作负载与资产建模

4. 云工作负载与资产建模

微隔离策略的本质，是"谁可以和谁通信"的规则集合。而"谁"在云环境中并不是一个稳定的概念——同一台业务主机，可能以虚拟机、容器、Pod、Serverless 函数四种形态存在，每种形态的标识方式、生命周期和元数据来源都不同。如果资产建模做不扎实，后续的标签策略、微分段规则、流量基线都会建立在流沙之上。本节要解决的核心问题是：如何为这四类工作负载建立统一、可追溯、可自动维护的资产标识与标签体系。

四类工作负载的标识与元数据差异

先看标识。虚拟机通常以实例 ID（如 AWS 的 i-0a1b2c3d、阿里云的 i-bp1xxxx）作为唯一标识，辅以私网 IP、MAC、主机名。容器在单机层面以容器 ID（64 位十六进制）标识，但容器 ID 每次重建都会变化，真正稳定的是镜像摘要（image digest，如 sha256:9f86d0…）与容器名。Kubernetes Pod 的标识更复杂：Pod 名（如 payment-api-7d9f8c6b5-x2k4m）由 ReplicaSet 哈希与随机后缀组成，Pod IP 随重建漂移，真正稳定的是工作负载身份——即 namespace + Deployment/StatefulSet 名 + label selector 所确定的逻辑集合。Serverless 实例（如 Lambda 的 execution environment）生命周期极短，单次调用可能复用也可能新建执行环境，稳定标识应落在函数名 + 版本/别名（如 payment-handler:prod）上，而非执行环境 ID。

再看元数据来源。虚拟机的元数据来自云厂商 API（标签、安全组、VPC、子网、可用区）与实例内 agent（OS、进程、监听端口）。容器的元数据来自容器运行时（Docker/containerd）与编排平台。Pod 的元数据最丰富：namespace、labels、annotations、ownerReferences、Service、Ingress、NetworkPolicy 都可作为建模输入。Serverless 的元数据主要来自函数配置（运行时、内存、超时、VPC 配置、环境变量）与调用日志。这四类元数据的采集频率、可信度和更新时机差异很大，建模时必须区分"声明式元数据"（如 K8s labels，由用户定义）与"观测式元数据"（如实际监听端口，由 agent 探测）。

标签体系设计：四维模型

标签不是越多越好，而是要覆盖微隔离策略真正需要的决策维度。实践中推荐四维标签模型：身份维（env、app、role、owner）回答"这是什么业务、属于谁"；位置维（region、vpc、subnet、zone）回答"它在哪里"；安全维（tier、sensitivity、compliance）回答"它有多重要、受什么合规约束"；运维维（version、lifecycle、backup）回答"它处于什么状态"。四维标签组合后，一条微隔离规则可以写成"env=prod 且 app=payment 且 tier=web 的资产，允许被 env=prod 且 tier=gateway 的资产访问 443 端口"，而不是依赖易变的 IP 地址。

标签设计有三条硬约束。第一，键名统一：同一含义的标签在不同工作负载上必须用同一个键，例如统一用 app 而不是有的用 app、有的用 application、有的用 service。第二，值域受控：env 只允许 prod/staging/dev/test 四个值，tier 只允许 web/app/data/mgmt 四个值，避免出现 "production"、"prod"、"PROD" 三种写法。第三，必填与选填分离：身份维和位置维为必填，缺失即告警；安全维和运维维可按业务逐步补齐。

自动化打标：从元数据到标签的映射规则

手工打标在云环境中不可持续——Pod 每天重建数百次，Serverless 实例每分钟都在变化。自动化打标的核心是建立"元数据 → 标签"的确定性映射规则。以下是一组可直接参考的规则示例（示例参数，非实测结果）：

规则 R1（K8s Pod 身份维）：
  条件：namespace 匹配 ^(prod|staging|dev)-
  动作：env = 从 namespace 前缀提取
        app = labels["app.kubernetes.io/name"]
        owner = annotations["owner/team"]
  优先级：100

规则 R2（K8s Pod 安全维）：
  条件：labels["app.kubernetes.io/name"] 在 [payment, order, user]
  动作：tier = app（应用层）
        sensitivity = high
  优先级：90

规则 R3（VM 位置维）：
  条件：云 API 返回 VPC ID 与子网 ID
  动作：vpc = vpc_name 映射表查询
        subnet = subnet_name 映射表查询
        zone = 可用区字段
  优先级：80

规则 R4（Serverless 运维维）：
  条件：函数配置存在 Alias = prod
  动作：env = prod
        version = 函数版本号
        lifecycle = active
  优先级：70

规则引擎执行时按优先级从高到低匹配，同一标签键被多条规则命中时，高优先级覆盖低优先级，并在审计日志中记录冲突。打标完成后必须做校验：必填标签缺失率超过 2% 即触发告警；env 值不在白名单内直接拒绝写入；同一 Pod 的 app 标签与 Deployment 名不一致时标记为"待人工确认"。

标签体系上线初期，建议先对存量资产做一次全量扫描，统计各标签的覆盖率与值分布。常见问题是 owner 标签覆盖率不足 30%，此时应先推动业务团队补齐，而不是急于下发微隔离策略——没有 owner 的资产，策略冲突时无人可协调。

标识漂移与生命周期处理

四类工作负载中，Pod 和 Serverless 的标识漂移最严重。Pod 重建后 IP 变化、名称变化，但工作负载身份（namespace + Deployment + selector）不变，因此微隔离策略必须绑定工作负载身份而非 Pod 名或 Pod IP。Serverless 实例的执行环境可能被复用，同一环境先后处理不同函数的调用，因此不能以执行环境 ID 作为策略锚点，必须以函数名 + 版本/别名为准。虚拟机相对稳定，但弹性伸缩组新建的实例需要自动继承伸缩组标签，否则新实例会成为策略盲区。

生命周期处理的关键是"标签随资产走"。资产创建时由 webhook 或事件触发器自动打标，资产销毁时标签记录保留在 CMDB 中并标记为 lifecycle=terminated，用于事后审计。对于长期未更新标签的资产（如超过 90 天未变更 version），应标记为"标签陈旧"并纳入治理清单。

落地检查清单

四类工作负载是否都有明确的稳定标识锚点（VM 实例 ID、容器镜像摘要、Pod 工作负载身份、Serverless 函数名+版本）？
标签键名是否全局统一，值域是否受控，必填标签是否明确？
自动化打标规则是否覆盖身份、位置、安全、运维四个维度，优先级与冲突处理是否定义？
打标结果是否有校验机制（缺失率、值白名单、一致性检查）？
资产销毁后标签记录是否保留，是否支持审计追溯？
是否存在标签陈旧资产，是否有定期治理流程？

资产建模不是一次性工程，而是持续运行的数据管道。只有标识稳定、标签准确、更新及时，微隔离策略才能真正做到"按身份放行、按标签隔离"，而不是退化成另一套难以维护的 IP 白名单。