3. 声明式管理基础:Kubernetes声明式配置、GitOps工作流、策略即代码概念

声明式管理是云原生配置管理的核心范式。与传统的命令式(Imperative)操作不同,声明式管理要求用户定义系统的期望状态(Desired State),由控制器持续调和(Reconcile)当前状态,直至与期望状态一致。本章将拆解这一范式的三大支柱:Kubernetes 声明式配置、GitOps 工作流以及策略即代码(Policy as Code)。

3.1 Kubernetes 声明式配置

Kubernetes 原生支持声明式配置。用户通过 YAML 或 JSON 清单文件描述集群的期望状态(如 Deployment 的副本数、Service 的端口映射),然后使用 kubectl apply 或 GitOps 工具将其提交给 API Server。kube-controller-manager 中的对应控制器(如 ReplicaSet Controller)持续监控并确保实际状态与清单一致。

关键对比:命令式 vs 声明式
维度 命令式(Imperative) 声明式(Declarative)
操作方式 kubectl run、kubectl scale kubectl apply -f、GitOps Sync
状态管理 用户手动跟踪变更历史 清单文件作为单一事实来源
可审计性 依赖 Shell 历史或 RBAC 日志 清单版本化,天然可审计
回滚能力 需手动执行逆操作 回退 Git 提交即可自动恢复
适用场景 调试、临时测试 生产环境、合规管控

声明式配置的核心优势在于幂等性:同一份清单文件无论应用多少次,结果始终一致。这为自动化准入控制和策略评审提供了稳定的输入基础。

# 示例:声明式 Deployment 清单
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

3.2 GitOps 工作流

GitOps 将声明式配置与 Git 版本控制深度绑定,使 Git 仓库成为集群状态的唯一事实来源(Single Source of Truth)。所有对集群的变更必须通过 Pull Request(PR)提交到 Git 仓库,由 GitOps Operator(如 Argo CD、Flux)自动同步到目标集群。

核心原则: GitOps 要求系统状态完全由 Git 仓库中的声明式清单定义,任何手动 kubectl 操作都应被视为配置漂移(Drift),并被自动修复。

GitOps 工作流天然适配 Sigstore 的签名与验证机制:

  1. 提交签名:开发者使用 Cosign 对清单文件或容器镜像进行签名,并将签名一同提交至 Git。
  2. PR 评审:在 PR 阶段,CI 流水线验证签名有效性,并执行策略检查(如只允许使用已签名的镜像)。
  3. 自动同步:GitOps Operator 从 Git 拉取清单,比对集群当前状态,执行 kubectl apply 完成部署。
  4. 持续验证:Operator 定期重新校验签名,确保运行时的镜像未被篡改。
GitOps + Sigstore 工作流 开发者 Git 仓库 CI 流水线 GitOps Operator 目标集群 ① 开发者提交签名后的清单 → ② CI 验证签名与策略 → ③ Operator 自动同步至集群

3.3 策略即代码(Policy as Code)

策略即代码将安全、合规与运维规则以代码形式编写、版本化并自动执行。在云原生环境中,策略引擎(如 OPA/Gatekeeper、Kyverno)拦截 Kubernetes API 请求,根据预定义的策略规则决定允许或拒绝。

注意: 策略即代码不是简单的配置文件,它要求策略具备可测试性、可版本化、可审计性。Sigstore 的签名验证可以作为策略规则的一部分,例如:“只允许部署由指定 CI 系统签名的镜像”。

策略即代码在准入控制中的典型应用:

策略类别 示例规则 与 Sigstore 结合点
镜像来源 只允许来自私有 Registry 的镜像 验证镜像签名是否来自受信任的发布者
安全基线 禁止特权容器、禁止 hostNetwork 签名中嵌入 SBOM 信息,策略校验漏洞等级
合规标签 所有 Namespace 必须包含 owner 标签 签名负载中包含标签声明,策略验证一致性
部署审批 生产环境变更必须经过指定审批人 审批人使用 Sigstore 进行身份签名

以下是一个使用 OPA Rego 语言编写的策略示例,要求所有镜像必须携带有效的 Cosign 签名:

package kubernetes.admission

import data.images

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  image := container.image
  not images.has_valid_signature(image)
  msg := sprintf("镜像 %v 缺少有效的 Cosign 签名", [image])
}

3.4 三者协同:声明式管理的安全闭环

Kubernetes 声明式配置、GitOps 工作流与策略即代码三者形成完整的安全配置管理闭环:

  • 声明式配置提供可版本化、可审计的期望状态清单。
  • GitOps 工作流确保所有变更经过 Git 评审与自动同步,杜绝手动漂移。
  • 策略即代码在准入阶段强制执行安全与合规规则,并与 Sigstore 签名验证深度集成。