📚 课程目录第3章声明式安全基线概念

3. 声明式管理基础：Kubernetes声明式配置模型、CRD与Operator模式、安全策略即代码（Policy as Code）理念

在云原生安全基线管理中，声明式管理是核心范式。本章将解析Kubernetes声明式配置模型、CRD与Operator模式，以及安全策略即代码（Policy as Code）理念，为后续使用Sigstore实现安全基线冷启动与削峰发布奠定理论基础。

3.1 Kubernetes声明式配置模型

声明式配置（Declarative Configuration）强调用户定义“期望状态”（Desired State），系统持续协调（Reconcile）至该状态。与命令式（Imperative）配置相比，声明式具有幂等性、可审计、版本可控等优势。

特性	命令式配置	声明式配置
操作方式	执行具体命令（kubectl run, create）	定义YAML/JSON清单（kubectl apply -f）
状态管理	用户跟踪当前状态	控制器自动协调期望状态
幂等性	非幂等，重复执行可能出错	幂等，重复apply结果一致
审计与回滚	困难，依赖操作日志	天然支持GitOps版本控制
适用场景	调试、临时操作	生产环境、CI/CD、安全基线

  关键实践： 安全基线声明式管理要求所有策略、准入规则、签名验证配置均以YAML清单形式定义，存储在Git仓库中，通过GitOps流程自动同步至集群。

3.2 CRD与Operator模式

Kubernetes的可扩展性核心在于自定义资源定义（CRD）与Operator模式。CRD允许用户定义新的资源类型，Operator则通过自定义控制器实现业务逻辑的自动化协调。

3.2.1 CRD：扩展API资源

CRD（Custom Resource Definition）是Kubernetes API的扩展机制。通过声明CRD，用户可以像管理原生资源（Pod、Service）一样管理自定义资源。例如，Sigstore的ClusterImagePolicy就是一种CRD，用于定义镜像签名验证策略。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: clusterimagepolicies.sigstore.dev
spec:
  group: sigstore.dev
  names:
    kind: ClusterImagePolicy
    listKind: ClusterImagePolicyList
    plural: clusterimagepolicies
    singular: clusterimagepolicy
  scope: Cluster
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              images:
                type: array
                items:
                  type: object
                  properties:
                    glob:
                      type: string
              authorities:
                type: array
                items:
                  type: object
                  properties:
                    keyless:
                      type: object
                      properties:
                        url:
                          type: string
                        identities:
                          type: array
                          items:
                            type: object
                            properties:
                              issuer:
                                type: string
                              subject:
                                type: string

3.2.2 Operator模式：自动化协调

Operator由CRD和自定义控制器组成。控制器通过Reconcile循环监听资源变化，确保实际状态与CRD中定义的期望状态一致。在Sigstore生态中，Operator负责自动部署、更新和修复签名验证组件。

推荐实践： 使用Operator管理Sigstore组件（如fulcio、rekor、cosign）的生命周期，实现安全基线的自动化部署与版本管理。

3.3 安全策略即代码（Policy as Code）理念

Policy as Code（PaC）将安全策略以代码形式管理，实现策略的版本控制、自动化测试、持续集成与部署。在云原生环境中，PaC与声明式配置天然契合，通过CRD定义策略，由Operator或准入控制器执行。

3.3.1 PaC核心原则

可读性： 策略使用声明式语言（如Rego、CUE）或YAML定义，非技术人员可理解。
可测试： 策略可编写单元测试，确保逻辑正确性。
可版本化： 策略存储在Git仓库中，支持分支、合并、回滚。
自动化执行： 策略在CI/CD流水线或集群准入阶段自动评估。

3.3.2 Sigstore中的PaC实践

Sigstore通过ClusterImagePolicy CRD实现镜像签名验证策略即代码。以下示例定义了一条策略：要求所有来自registry.example.com/*的镜像必须经过Sigstore签名，且签发者必须为https://accounts.example.com。

apiVersion: sigstore.dev/v1
kind: ClusterImagePolicy
metadata:
  name: require-sigstore-signature
spec:
  images:
  - glob: registry.example.com/*
  authorities:
  - keyless:
      url: https://fulcio.sigstore.dev
      identities:
      - issuer: https://accounts.example.com
        subject: https://github.com/example-org/*/.github/workflows/*.yml

注意： 策略即代码需要配合准入控制器（如cosign-webhook或kyverno）才能生效。仅定义CRD不会自动阻止未签名镜像运行。

3.3.3 PaC与声明式安全基线

将PaC与声明式管理结合，可实现安全基线的冷启动与削峰发布：

阶段	操作	声明式资源
冷启动	集群初始化时自动应用安全策略	ClusterImagePolicy, PodSecurityStandard
持续合规	通过GitOps持续同步策略变更	Git仓库中的YAML清单
削峰发布	发布前自动验证镜像签名与策略	CI/CD流水线中的策略评估
审计追溯	策略变更历史与合规报告	Git提交记录与策略版本

3.4 声明式管理在Sigstore安全基线中的价值

声明式管理、CRD/Operator模式与Policy as Code三者结合，为Sigstore安全基线管理提供了以下核心能力：

一致性： 所有安全策略以代码形式统一管理，消除环境差异。
自动化： Operator自动协调策略状态，减少人工干预。
可审计： 策略变更通过Git历史追溯，满足合规要求。
弹性： 冷启动时自动应用基线，削峰发布时动态调整策略。

实践建议： 在实施Sigstore安全基线时，优先将ClusterImagePolicy、PodSecurityStandard等策略定义为CRD，并通过GitOps工具（如ArgoCD、Flux）自动同步至集群，实现真正的声明式安全治理。