# 通过 Kyverno CRD 实现 Kubernetes 策略准入控制：动态生成网络策略 > 利用 Kyverno 的 CRD 机制，通过 validate、mutate 和 generate 规则实现资源变异、配置验证以及无代理动态网络策略生成，确保 Kubernetes 集群安全合规。 ## 元数据 - 路径: /posts/2025/09/13/kyverno-policy-admission-control-dynamic-network-policies/ - 发布时间: 2025-09-13T20:46:50+08:00 - 分类: [ai-security](/categories/ai-security/) - 站点: https://blog.hotdry.top ## 正文 Kyverno 作为 Kubernetes 原生策略引擎，通过自定义资源定义 (CRD) 实现准入控制 (Admission Control)，无需代理或 sidecar 即可强制执行安全策略。它支持 validate、mutate 和 generate 三类规则，分别用于验证配置、修改资源以及动态生成辅助资源，如 NetworkPolicy，从而简化集群治理并提升安全性。 在 Kubernetes 环境中，准入控制是防止违规资源进入集群的关键机制。Kyverno 通过部署动态准入 webhook 与 kube-apiserver 集成，当资源创建或更新请求到达时，Kyverno 会拦截 AdmissionReview 对象，进行规则匹配和执行。相比传统 Pod Security Policy (PSP)，Kyverno 的 CRD 模型更灵活，支持 YAML 风格的策略定义，无需学习新语言。根据官方文档，Kyverno 可验证资源是否符合 Pod Security Standards (PSS)，如 baseline 级别要求禁止特权容器。 validate 规则用于检查资源配置合规性。例如，定义一个 ClusterPolicy CRD 来确保所有 Pod 必须设置 runAsNonRoot: true，避免 root 用户运行容器。规则通过 pattern 或 deny 条件匹配资源字段，如果不符则拒绝请求。该规则的 failureAction 可设为 Enforce（阻塞）或 Audit（报告），适用于生产环境的安全审计。实际部署时，match 块指定资源 kinds 如 Pod，validate 块定义模式：spec.securityContext.runAsNonRoot: true。监控时，可通过 Prometheus 指标 kyverno_policy_results_total 跟踪验证失败率，阈值设为 5% 时触发警报。 mutate 规则允许在准入阶段自动修改资源，实现标准化配置。例如，对于缺少资源限制的 Pod，Kyverno 可注入默认 CPU 和内存 limits。该规则使用 patchStrategicMerge 或 patchesJson6902 格式，针对 spec.containers[*].resources 字段添加 requests.cpu: "100m" 和 limits.memory: "256Mi"。在动态生成场景中，mutate 可结合变量如 {{request.object.metadata.name}}，确保修改基于上下文。生产参数包括使用 anchors 如 +(resources.requests.cpu) 来避免覆盖现有值，防止循环修改。风险在于过度变异可能导致资源不稳定，建议在 audit 模式下先测试，结合 kubectl explain clusterpolicy.spec.rules.mutate 验证 schema。 generate 规则是 Kyverno 的独特优势，支持基于事件动态创建资源，如为新 Namespace 自动生成 NetworkPolicy，而无需 agents 或 sidecars。该规则通过 clone 或 data 源定义目标资源，synchronize: true 确保后续同步。示例：match Namespace 创建事件，generate 一个 networking.k8s.io/v1 NetworkPolicy，名为 default-deny，spec.podSelector: {} 且 policyTypes: [Ingress, Egress]，隔离命名空间流量。namespace 字段使用 {{request.object.metadata.name}} 动态注入。生成后，Kyverno 创建 UpdateRequest 对象跟踪状态，可通过 kubectl get updaterequests -A 查询 Pending/Failed/Completed。生产清单包括：1) 授予 kyverno-background-controller ServiceAccount 生成 NetworkPolicy 的 RBAC 权限；2) 设置 orphanDownstreamOnPolicyDelete: false 避免策略删除时丢失资源；3) 配置后台扫描间隔 BACKGROUND_SCAN_INTERVAL=1h 以优化性能。监控要点：kyverno_generate_requests_total 指标，异常阈值 10/min 时检查 webhook 延迟。 在实施中，先从 policy library 导入预置策略，如 CIS Benchmark 合规模板，然后自定义 CRD。部署时，使用 Helm chart kyverno/kyverno，replicas: 3 确保高可用，启用 podAntiAffinity 分布节点。回滚策略：结合 GitOps 工具如 Argo CD，ignoreDifferences 配置忽略 Kyverno 变异字段。测试阶段，使用 kyverno CLI 的 test 命令模拟 AdmissionReview，避免生产影响。总体，Kyverno 的无代理设计降低了运维复杂度，但需注意权限最小化原则，仅授予 generate 必要动词如 create/update NetworkPolicy。 通过上述规则，Kyverno 实现零信任网络策略动态生成，例如为 Deployment 事件生成针对性 Egress 规则，spec.ingress.from.pods 引用源 Pod labels。该方法在多租户环境中特别有效，确保隔离无遗漏。最终，结合 PolicyReport CRD 生成审计报告，集成 ELK 或 Grafana 可视化违规趋势，实现闭环治理。 Kyverno 的 generate 规则特别适用于动态网络策略生成场景。假设集群中 Namespace 创建频繁，手动配置 NetworkPolicy 易遗漏。通过 CRD 定义 match: kinds: [Namespace]，generate: kind: NetworkPolicy，data: spec: podSelector: {}，policyTypes: ["Ingress", "Egress"]，可自动隔离流量。synchronize: true 确保 Policy 更新时 NetworkPolicy 同步，避免漂移。实际参数：使用 context 变量从外部数据源如 ConfigMap 拉取 IP 白名单，注入 spec.ingress.from.ipBlocks。回滚策略：如果生成失败，UpdateRequest.status 标记 Failed，管理员可通过 kubectl describe updaterequest 诊断权限或 schema 错误。阈值监控：kyverno_admission_review_latency_seconds > 1s 时，优化 webhook 证书或增加 replicas。 在多模型流式补全场景下，Kyverno 可 mutate Deployment 的 spec.template.spec.containers 注入 sidecar，但 angle_brief 强调无 sidecar，故聚焦 generate NetworkPolicy。观点：动态生成减少运维负担，证据：官方示例显示 Namespace 事件触发生成，落地参数：RBAC ClusterRole 添加 create networking.k8s.io/networkpolicies，namespace: {{request.object.metadata.name}}。风险：过度生成资源耗尽 quota，限制造成 PolicyReport 过滤。 扩展应用：结合 verifyImages 规则，确保生成 NetworkPolicy 仅允许签名镜像访问。Policy library 中 CIS 1.6.1 策略可导入作为 baseline。测试清单：1) kyverno apply test.yaml --dry-run；2) 模拟 Namespace 创建验证生成；3) 负载测试 1000 Namespace/分钟，确保延迟 <500ms。最终，Kyverno CRD 驱动的准入控制实现无代理安全治理，适用于生产级 Kubernetes 集群。 ## 同分类近期文章 ### [诊断 Gemini Antigravity 安全禁令并工程恢复：会话重置、上下文裁剪与 API 头旋转](/posts/2026/03/01/diagnosing-gemini-antigravity-bans-reinstatement/) - 日期: 2026-03-01T04:47:32+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 剖析 Antigravity 禁令触发机制，提供 session reset、context pruning 和 header rotation 等工程策略，确保可靠访问 Gemini 高级模型。 ### [Anthropic 订阅认证禁用第三方工具：工程化迁移与 API Key 管理最佳实践](/posts/2026/02/19/anthropic-subscription-auth-restriction-migration-guide/) - 日期: 2026-02-19T13:32:38+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 解析 Anthropic 2026 年初针对订阅认证的第三方使用限制，提供工程化的 API Key 迁移方案与凭证管理最佳实践。 ### [Copilot邮件摘要漏洞分析：LLM应用中的数据流隔离缺陷与防护机制](/posts/2026/02/18/copilot-email-dlp-bypass-vulnerability-analysis/) - 日期: 2026-02-18T22:16:53+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 深度剖析Microsoft 365 Copilot因代码缺陷导致机密邮件被错误摘要的事件，揭示LLM应用数据流隔离的工程化防护要点。 ### [用 Rust 与 WASM 沙箱隔离 AI 工具链：三层控制与工程参数](/posts/2026/02/14/rust-wasm-sandbox-ai-tool-isolation/) - 日期: 2026-02-14T02:46:01+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 探讨基于 Rust 与 WebAssembly 构建安全沙箱运行时，实现对 AI 工具链的内存、CPU 和系统调用三层细粒度隔离，并提供可落地的配置参数与监控清单。 ### [为AI编码代理构建运行时权限控制沙箱：从能力分离到内核隔离](/posts/2026/02/10/building-runtime-permission-sandbox-for-ai-coding-agents-from-capability-separation-to-kernel-isolation/) - 日期: 2026-02-10T21:16:00+08:00 - 分类: [ai-security](/categories/ai-security/) - 摘要: 本文探讨如何为Claude Code等AI编码代理实现运行时权限控制沙箱，结合Pipelock的能力分离架构与Linux内核的命名空间、seccomp、cgroups隔离技术，提供可落地的配置参数与监控方案。