/* 示例 1：Kyverno 安全基线策略集——Pod Security Standards restricted 的平台化 */
/* 平台为所有业务 namespace 强制 restricted 基线，mutate 优先于 deny */
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: platform-pod-security
  annotations:
    policies.kyverno.io/title: 平台 Pod 安全基线
    policies.kyverno.io/description: >
      实施 K8s Pod Security Standards 的 restricted 级别。
      优先自动修正（mutate），无法修正时拒绝（validate）。
spec:
  background: true
  rules:
    /* 规则 1 (mutate): 自动注入缺失的安全上下文——修正优先于拒绝 */
    - name: inject-security-context
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces:
                selector:
                  matchLabels:
                    platform.acme.com/security-baseline: "restricted"
      mutate:
        patchStrategicMerge:
          spec:
            securityContext:
              runAsNonRoot: true
              seccompProfile:
                type: RuntimeDefault
            containers:
              - (name): "*"
                securityContext:
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop: ["ALL"]
    /* 规则 2 (validate): 禁止特权容器与 host 命名空间——不可修正的硬红线 */
    - name: deny-privileged
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: >
          特权容器与 host 命名空间被组织安全基线禁止（容器逃逸风险）。
          如确有需求（如监控 agent），请使用平台专用 namespace 与
          审批流程: https://platform.acme.internal/docs/security-exceptions
        pattern:
          spec:
            =(hostNetwork): false
            =(hostPID): false
            containers:
              - =(securityContext):
                  =(privileged): false
    /* 规则 3 (validate): 镜像必须来自受信任仓库且带 digest */
    - name: require-trusted-signed-images
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: >
          镜像必须来自 registry.acme.com 且使用 digest 引用
          （tag 可变，digest 不可变——供应链完整性要求）。
        pattern:
          spec:
            containers:
              - image: "registry.acme.com/*@sha256:*"
---
/* 规则 4: 镜像签名验证（verifyImages）——供应链的最后防线 */
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces:
                selector:
                  matchLabels:
                    platform.acme.com/tier: production
      verifyImages:
        - imageReferences: ["registry.acme.com/*"]
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----
          verifyDigest: true
          required: true

解释：这份策略集展示了平台安全基线的「修正优先、拒绝兜底、签名断后」三层设计。规则 1 的 mutate 策略是体验设计的精髓：开发者提交缺失安全上下文的 Pod（老应用的清单、手写的测试 YAML），Kyverno 自动注入 runAsNonRoot、seccomp、drop ALL capabilities——用户甚至不知道违规发生过，产出物已经合规。mutate 优先于 validate 的理由：拒绝产生挫败与工单，修正产生零摩擦的合规；只有无法自动修正的违规（用户显式声明了冲突配置）才进入拒绝路径。namespace selector 把策略范围限定在打了 security-baseline: restricted 标签的 namespace——平台创建的业务 namespace 自动带此标签（黄金路径的结构性保证），系统 namespace 与特殊审批的 namespace 不受影响，策略作用域的精确控制避免误伤。规则 2 是不可修正的硬红线：privileged 与 host 命名空间是容器逃逸的直接通道，没有任何业务场景应该在业务 namespace 中使用（监控 agent 类需求走平台专用 namespace 与审批）；message 中的例外流程链接把「被拒绝」导向「合法的例外路径」而非「绕过平台」。规则 3 强制 digest 引用：tag 是可变的（latest 今天指向 v1 明天指向 v2），digest 是内容寻址不可变的——「部署的就是扫描过签名过的那个镜像」的信任链依赖 digest 固定；这个要求由平台的部署通道自动满足（流水线部署时用 digest 而非 tag），策略拦截的是绕过通道的部署。规则 4 的 verifyImages 是供应链防线：生产 namespace 的每个镜像必须验证 cosign 签名（组织公钥），verifyDigest 确保签名绑定到具体 digest——攻击者即使推送了恶意镜像到 Registry（凭证泄漏场景），没有组织私钥签名就无法通过验证。四层规则的组合效果：常规违规被静默修正，恶意绕过被硬性拦截，供应链攻击被签名验证阻断——纵深防御在准入层的完整体现。

/* 示例 2：External Secrets Operator——平台密钥系统的标准接入 */
/* 密钥存储在 Vault，K8s Secret 只是同步缓存，应用零感知接入 */
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: platform-vault
  namespace: team-payments
spec:
  provider:
    vault:
      server: "https://vault.platform.svc:8200"
      path: "secret"
      version: v2
      auth:
        /* 工作负载身份认证: ServiceAccount token 换 Vault 角色，无静态凭证 */
        kubernetes:
          mountPath: kubernetes
          role: payments-external-secrets
          serviceAccountRef:
            name: external-secrets-sa
            namespace: team-payments
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payments-db-credentials
  namespace: team-payments
  annotations:
    platform.acme.com/rotation-policy: "90d"
    platform.acme.com/security-owner: security-team
spec:
  refreshInterval: 1h          /* 每小时同步: 轮换后 1 小时内应用获得新密钥 */
  secretStoreRef:
    name: platform-vault
    kind: SecretStore
  target:
    name: db-credentials       /* 生成的 K8s Secret 名，应用按常规方式消费 */
    template:
      metadata:
        labels:
          platform.acme.com/managed-secret: "true"
  data:
    - secretKey: username
      remoteRef:
        key: payments/prod/db
        property: username
    - secretKey: password
      remoteRef:
        key: payments/prod/db
        property: password
---
/* Vault 侧的动态数据库凭证配置（平台团队管理） */
/* vault write database/config/payments-prod */
/*   plugin_name=postgresql-database-plugin */
/*   allowed_roles="payments-app" */
/*   connection_url="postgresql://{{username}}:{{password}}@payments-db:5432/prod" */
/*   root_rotation_statements="ALTER USER {{username}} WITH PASSWORD '{{password}}'" */
/* vault write database/roles/payments-app */
/*   db_name=payments-prod */
/*   creation_statements="CREATE ROLE ... LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'" */
/*   default_ttl="1h" max_ttl="24h" */

解释：这份配置展示了平台密钥管理的完整链路：Vault 作为唯一密钥源、External Secrets Operator（ESO）作为同步机制、工作负载身份作为认证方式、动态凭证作为高级形态。ESO 的架构价值：应用消费的是普通的 K8s Secret（db-credentials），代码与配置零改动——密钥管理的复杂性被平台组件吸收；SecretStore 定义「从哪里取」（Vault 地址与认证方式），ExternalSecret 定义「取什么、放到哪」（remoteRef 到 target 的映射）。认证链路的安全设计：ESO 用 Kubernetes ServiceAccount token 向 Vault 的 kubernetes auth 方法认证，Vault 验证 token 的真实性（调用 K8s TokenReview API）并检查 ServiceAccount 是否绑定到 payments-external-secrets 角色——全链路无静态凭证（对比传统方式：Vault token 写在 K8s Secret 里，而那个 Secret 本身又要保护——鸡生蛋问题；工作负载身份认证彻底消灭了这个循环）。refreshInterval: 1h 与 rotation-policy 注解的配合实现自动轮换的体验：Vault 侧轮换密钥后，ESO 在 1 小时内同步新值到 K8s Secret，应用通过 Secret volume 的自动更新（kubelet 同步周期）或重启获得新密钥——开发者对轮换零感知。注释中的 Vault 动态凭证配置是更高级的形态：数据库凭证不再静态存储，而是按需生成——应用（或 ESO 的 push 模式）向 Vault 请求凭证时，Vault 实时在 PostgreSQL 中创建一个 VALID UNTIL 1 小时的专用账号；凭证泄漏的爆炸半径从「永久有效的共享账号」压缩为「1 小时有效的专用账号」，且 Vault 审计日志精确记录每次凭证签发（谁、何时、什么角色）——泄漏溯源从「不可能」变成「查日志」。平台化的接入体验：黄金路径模板自动为每个服务生成 SecretStore 引用与标准 ExternalSecret（数据库、API 密钥的命名约定），开发者在门户申请密钥（自动在 Vault 创建路径 + 配置权限 + 生成 ExternalSecret YAML 的 PR）——「密钥管理」从安全专家的领域变成 5 分钟的自助操作。

/* 示例 3：Falco 运行时安全规则——「假设突破」的检测层 */
/* 准入控制防「不安全的配置」，运行时检测防「已部署负载的异常行为」 */
apiVersion: falcosecurity.k8s.io/v1alpha1
kind: FalcoRule
metadata:
  name: platform-runtime-baseline
spec:
  rules: |
    /* 规则 1: 容器内启动交互式 shell——入侵后的典型第一动作 */
    - rule: Terminal shell in container
      desc: 检测到容器内 spawn 了交互式 shell（bash/sh/zsh + tty）
      condition: >
        spawned_process and container
        and proc.name in (bash, sh, zsh, ksh)
        and proc.tty
        and not container.image.repository in (platform.acme.com/debug-toolbox)
      output: >
        容器内交互式 shell (user=%user.name user_loginuid=%user.loginuid
        container=%container.name image=%container.image.repository
        shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline
        namespace=%k8s.ns.name pod=%k8s.pod.name)
      priority: WARNING
      tags: [mitre_execution]

    /* 规则 2: 意外外连——数据渗出与 C2 通信的信号 */
    - rule: Outbound connection to non-allowlisted endpoint
      desc: 业务容器连接到平台白名单外的外部地址
      condition: >
        outbound and container
        and not k8s.ns.name in (platform-system, observability)
        and not fd.sip in (allowed_internal_ranges)
        and not fd.sname in (allowed_external_services)
      output: >
        意外外连 (dest=%fd.rip:%fd.rport container=%container.name
        image=%container.image.repository cmdline=%proc.cmdline)
      priority: CRITICAL
      tags: [mitre_exfiltration, mitre_command_and_control]

    /* 规则 3: 敏感文件访问——凭证窃取行为 */
    - rule: Read sensitive file in container
      desc: 容器进程读取 /etc/shadow、私钥或非常规位置的凭证文件
      condition: >
        open_read and container
        and (fd.name in (/etc/shadow, /etc/sudoers)
             or fd.name glob /root/.ssh/*
             or fd.name glob /tmp/*.pem)
      output: >
        敏感文件访问 (file=%fd.name container=%container.name
        user=%user.name cmdline=%proc.cmdline)
      priority: CRITICAL
      tags: [mitre_credential_access]
---
/* Falco 告警的平台集成: Falcosidekick 把事件路由到 */
/* Slack(#security-alerts) + 事故系统(P2 自动建案) + Loki(长期检索) */

解释：Falco 规则是纵深防御的第四层——前三层（模板默认、流水线门禁、准入控制）都作用于「部署时」，防的是已知模式的违规配置；Falco 作用于「运行时」，检测的是「配置合规但行为异常」的入侵信号，对应零信任的「假设已突破」原则。三条规则映射 MITRE ATT&CK 攻击链的三个阶段（tags 中的 mitre_* 标注让安全团队可以按攻击战术聚合分析）。规则 1（容器内 shell）的检测逻辑：正常业务容器不需要交互式 shell——它的存在几乎总是意味着「有人进来了」（kubectl exec 入侵、webshell、供应链后门的行为）；condition 中的 proc.tty 判定交互式（排除脚本中的非交互 sh -c 调用，避免误报），not 子句豁免平台的 debug-toolbox 镜像（显式批准的排障工具容器）——白名单豁免的精确性是 Falco 规则质量的关键：过宽漏报，过窄误报淹没安全团队。规则 2（意外外连）是数据渗出与 C2（命令控制）通信的核心检测：业务容器的合法外连目标应该是可枚举的（内部服务网段 + 显式登记的外部 API），白名单外的外连（尤其是非常规端口）高度可疑；allowed_external_services 列表由平台维护——服务目录的 dependsOn 中登记的外部依赖自动进入白名单，「未声明的外连」同时是安全风险与架构债务的信号。规则 3（敏感文件访问）检测凭证窃取：/root/.ssh、/tmp/*.pem 等位置的读取在正常业务逻辑中不应出现。output 字段的上下文富化是事件响应效率的决定因素：user、container、image、cmdline、namespace、pod 全部内联在告警中——安全工程师收到告警时不需要再查询多个系统拼凑上下文，30 秒内可以判断「这是哪个团队的哪个服务的什么行为」并决定响应动作（隔离 Pod、吊销凭证、升级事故）。Falcosidekick 的路由集成让 Falco 事件进入平台的标准告警管道（分级路由、审计留存、事故关联）——运行时安全不是孤立的工具，而是平台可观测性与事故管理体系的一部分。

/* 示例 4：供应链响应的自助查询——「CVE 影响面分析」平台 API */
/* Log4Shell 式危机的分钟级响应：SBOM 索引 + 一键影响面查询 */
from fastapi import FastAPI
from pydantic import BaseModel
import httpx

app = FastAPI(title="Platform Supply Chain Response API")

class ImpactQuery(BaseModel):
    cve_id: str                      /* 如 CVE-2021-44228 */
    package_pattern: str | None      /* 如 log4j-core，可选精确匹配 */
    version_range: str | None        /* 如 ">=2.0,<2.15"，可选 */

@app.post("/v1/supply-chain/impact")
async def analyze_impact(query: ImpactQuery) -> dict:
    """跨全组织 SBOM 索引查询受影响制品，关联目录与部署数据。"""
    /* 步骤 1: 在 SBOM 索引（Dependency-Track 或自建 CycloneDX 库）中 */
    /*         匹配包含目标包与版本的制品（镜像 digest 级） */
    async with httpx.AsyncClient() as client:
        sbom_hits = (await client.post(
            "http://dependency-track.platform.svc:8081/api/v1/finding/search",
            json={"cve": query.cve_id, "package": query.package_pattern},
        )).json()
    /* 步骤 2: 制品 digest -> 服务目录实体（部署时登记的 digest 映射） */
    affected_services = []
    for hit in sbom_hits:
        digest = hit["component"]["purl"]
        entity = await catalog_lookup_by_digest(digest)
        if entity:
            affected_services.append({
                "service": entity["metadata"]["name"],
                "owner": entity["spec"]["owner"],
                "environments": await deployments_by_digest(digest),
                "fix_available": hit.get("fix_version"),
            })
    /* 步骤 3: 聚合输出——按 owner 分组，附修复版本与部署环境 */
    return {
        "cve": query.cve_id,
        "affected_service_count": len(affected_services),
        "affected_production_count": sum(
            1 for s in affected_services if "production" in s["environments"]),
        "services": affected_services,
        "suggested_actions": [
            "1. 平台机器人将向全部受影响仓库提交依赖升级 PR",
            "2. 生产环境服务优先: 按 owner 分组的修复工单已自动创建",
            "3. 无法立即修复的: 申请 WAF 虚拟补丁缓解 (链接见工单)",
        ],
    }

/* 配套的自动化响应工作流（平台工作流引擎触发）: */
/* 1. Renovate 批量 PR: 受影响仓库的依赖升级（附 CVE 说明与测试结果） */
/* 2. 工单自动创建: 按 owner 分组，CRITICAL 级 SLA 48h */
/* 3. 修复进度看板: 受影响服务的修复状态实时追踪（已修复/PR 待合并/未响应） */
/* 4. 升级机制: SLA 到期未修复 -> 安全委员会 + 自动缓解（WAF/网络策略） */

解释：这个 API 是「SBOM 投资在危机时刻兑现」的具象化——2021 年 12 月 Log4Shell 爆发时，业界的响应速度差异是数量级的：有 SBOM 索引的组织在数小时内产出完整影响面清单，没有的组织花了数周用 grep 扫描全部代码库（还漏掉了二进制依赖与传递依赖）。实现链路分三步，每步依赖一项平台基础设施。步骤 1 依赖 SBOM 的持续采集与索引：流水线为每个镜像生成 CycloneDX SBOM 并上传到 Dependency-Track（开源的 SBOM 管理与漏洞关联平台），它持续把 SBOM 中的组件与新披露的 CVE（NVD 数据源）匹配——漏洞披露的瞬间，受影响制品清单已经就绪，查询是「读预计算结果」而非「现场扫描」。步骤 2 依赖部署时的 digest 登记：平台部署通道在部署事件中记录「服务 X 的环境 Y 正在运行 digest sha256:abc...」——这个映射让「受影响制品」翻译为「受影响的生产服务」，没有它 SBOM 查询只能到镜像级，无法回答「哪些线上服务需要立即修复」。步骤 3 依赖服务目录的 owner 数据：修复责任自动路由到 owning 团队，工单按团队分组——危机响应的组织动员自动化。suggested_actions 的设计体现「响应即产品」：查询结果不只给数据，还给行动方案（机器人 PR、工单、缓解选项）——安全团队在危机中的角色从「人肉协调 200 个团队」变为「启动自动化响应工作流并监督进度」。修复进度看板与升级机制完成闭环：未响应团队在 SLA 到期后自动升级（安全委员会介入 + 平台自动施加缓解——WAF 虚拟补丁或网络策略限制出站），「修复或缓解」的强制保证让组织级风险在可控时间内收敛。这套能力的平时价值：每周的新披露 CVE 自动匹配（无需危机也持续运行），团队收到的不是「恐慌通知」而是「带 PR 的修复建议」——供应链安全从应急模式进入常态运营模式。

/* 示例 5：NetworkPolicy 的目录驱动生成——从依赖关系自动推导网络隔离 */
/* 平台工作流: 读取服务目录的 dependsOn，生成默认拒绝 + 精确允许的策略 */
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-api-ingress
  namespace: team-payments
  annotations:
    platform.acme.com/generated-from: "catalog:component/payments-api"
    platform.acme.com/generated-at: "2024-09-15T08:00:00Z"
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: payments-api
  policyTypes: ["Ingress"]
  ingress:
    /* 允许来源 1: 目录中声明的上游——checkout-frontend dependsOn payments-api */
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-checkout
          podSelector:
            matchLabels:
              app.kubernetes.io/name: checkout-frontend
      ports: [{ protocol: TCP, port: 8080 }]
    /* 允许来源 2: 服务网格 sidecar 与健康检查（平台基础设施） */
    - from:
        - namespaceSelector:
            matchLabels:
              platform.acme.com/role: infrastructure
      ports: [{ protocol: TCP, port: 15020 }]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-api-egress
  namespace: team-payments
  annotations:
    platform.acme.com/generated-from: "catalog:component/payments-api"
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: payments-api
  policyTypes: ["Egress"]
  egress:
    /* 目录声明的下游依赖: fraud-detection 服务与 payments-postgres */
    - to:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: fraud-detection
      ports: [{ protocol: TCP, port: 8080 }]
    - to:
        - podSelector:
            matchLabels:
              platform.acme.com/resource: payments-postgres
      ports: [{ protocol: TCP, port: 5432 }]
    /* 平台基础设施: DNS 与可观测性采集 */
    - to:
        - namespaceSelector:
            matchLabels:
              kube-system: "true"
      ports: [{ protocol: UDP, port: 53 }]
    - to:
        - namespaceSelector:
            matchLabels:
              platform.acme.com/role: observability
      ports: [{ protocol: TCP, port: 4317 }]
---
/* 生成器逻辑（平台工作流引擎中的伪代码）: */
/* entity = catalog.get("component/payments-api") */
/* ingress_from = [e for e in catalog.query( */
/*   "dependsOn == payments-api")]        /* 谁依赖我 -> 我的 ingress */ */
/* egress_to = entity.spec.dependsOn      /* 我依赖谁 -> 我的 egress */ */
/* policy = render_template(ingress_from, egress_to, platform_defaults) */
/* kubectl apply + 记录审计（生成时间、源目录版本） */

解释：这个示例展示平台独有的安全自动化能力——「目录驱动的网络微隔离」，它是零信任第三支柱（网络隔离）与第 2 章服务目录的深度结合。传统 NetworkPolicy 的困境：手写网络策略需要工程师准确知道服务的全部通信关系（遗漏一条就断流量），而通信关系随架构演进持续变化——结果是大多数组织的 NetworkPolicy 要么不写（全通），要么写「宽松版」（允许整个 namespace 互访，隔离名存实亡）。平台化解法的数据基础是服务目录的 dependsOn 关系：这些关系由脚手架自动登记（新服务的依赖在创建时声明）、由开发者维护（依赖变更时更新目录）、并被可观测性数据验证（第 8 个关键要点提到的「影子依赖」检测：实际流量与目录声明的 diff）。生成器逻辑把目录数据翻译为最小权限的网络策略：ingress 规则来自「谁声明依赖我」（反向查询），egress 规则来自「我声明依赖谁」，加上平台基础设施的固定允许（DNS、可观测性采集、网格 sidecar）——每条允许规则都可追溯到目录中的一个声明关系。annotations 的溯源设计（generated-from、generated-at）让策略的「为什么」可审计：安全审查时任何一条允许规则都能回答「基于哪个目录声明生成」；策略与目录的同步由平台工作流保证（目录 dependsOn 变更触发策略重新生成，PR 形式提交给服务 owner 确认——网络变更可能导致断流，人在回路是必要的安全阀）。「影子依赖」的治理闭环尤其精妙：Falco/网格遥测发现未声明的通信（A 实际调用 B 但目录无声明）→ 平台生成「依赖申报」工单 → 团队确认后目录更新 → 策略自动放行；未确认的未声明通信在宽限期后被策略阻断——网络策略成为倒逼目录数据质量的机制，目录质量又反过来提升策略精度，两个平台能力相互强化。安全收益的量化：横向移动阻断（攻击者拿下 checkout-frontend 后无法扫描/访问与它无声明关系的 200 个服务）、攻击面收敛（每个服务的可达集合从「全集群」缩小到「个位数声明依赖」）、合规证据（PCI 的网络隔离要求由生成策略 + 目录溯源自动证明）。