3. 观测标签体系设计原则：标签分类、命名规范、可扩展性要求

在云原生安全运行基线核验场景中，Argo CD 观测标签体系是连接“安全基线定义”与“运行时合规状态”的语义桥梁。设计一套健壮的标签体系，需要遵循三大核心原则：标签分类（维度划分）、命名规范（语法约束）和可扩展性要求（演进能力）。

3.1 标签分类：四维正交模型

为避免标签语义重叠或冲突，我们将观测标签划分为四个正交维度。每个维度独立表达一类元数据，组合后形成完整的观测上下文。

3.2 命名规范：三段式语法与约束

每个标签键（Key）采用三段式结构：维度前缀 + 领域子类 + 具体属性，使用英文句点（.）分隔。标签值（Value）采用小写字母、数字和连字符（-）的组合。

# 命名规范语法
{维度前缀}.{领域子类}.{具体属性} = {小写字母/数字/连字符}

# 合规示例
baseline.category.network-policy = restricted
check.result.compliance = pass
resource.application.name = payment-service

# 不合规示例（禁止）
Baseline_Category = Restricted        # 大小写混用、下划线
check.result.compliance = "PASS"      # 大写值
resource.application/name = pay-svc   # 斜杠分隔符

3.3 可扩展性要求：版本化与预留命名空间

标签体系需要支持安全基线标准的持续演进。我们通过版本化标签和预留命名空间两种机制保障可扩展性。

3.3.1 版本化标签

当基线规则或核验逻辑发生不兼容变更时，通过标签后缀 _v{数字} 区分版本，避免旧数据与新规则冲突。

# 基线维度版本化示例
baseline.category.network-policy_v1 = restricted
baseline.category.network-policy_v2 = default-deny

# 核验维度版本化示例
check.engine.version_v1 = kube-bench-0.6
check.engine.version_v2 = kube-bench-0.7

3.3.2 预留命名空间

在每个维度下预留 custom.* 和 ext.* 两个子命名空间，供团队或插件扩展使用，无需修改核心标签定义。

3.4 标签体系架构总览

下图展示了四维标签模型、命名规范与可扩展性机制的整体关系：

3.5 标签体系设计检查清单

在实际落地过程中，建议对照以下清单进行评审：

1. 正交性检查：任意两个标签维度是否存在语义交叉？例如 baseline.category 是否与 check.result 存在隐含依赖？
2. 命名合规检查：所有标签键是否严格遵循三段式语法？标签值是否全部小写且不含特殊字符？
3. 可枚举性检查：标签值的取值集合是否可穷举？是否可以通过 PromQL 或 SQL 的 IN 子句进行过滤？
4. 版本兼容检查：当基线规则升级时，旧标签是否通过版本后缀保留？是否存在标签键复用导致数据污染的风险？
5. 预留空间检查：是否已为 custom.* 和 ext.* 命名空间配置了独立的采集与存储策略？