Kubernetes 自主AI智能体安全防护：新型云工作负载的信任边界、密钥管理与可观测性

凌晨两点钟问题

凌晨两点钟。当三百条警报同时涌入网络、数据库、应用和安全各个领域时，监控面板上红光不停地闪烁。值班工程师打开六个仪表盘，关联时间戳、作出排查假设，再调取日志信息验证，结果却发现排查假设是错误的。这样的排查过程一遍遍重复，直到三小时后才锁定根本原因：一次防火墙规则变更引发了连锁反应，造成应用请求超时，继而耗尽了数据库连接池。

想象一下，一个 AI 智能体可以自动完成整套故障排查流程。这个智能体需要拉取网络遥测数据、查询应用日志、检查数据库指标，并对安全事件进行交叉比对。除此之外，智能体还需要完成各个系统的身份认证，并依据当前排查发现动态决定需要额外查询哪些数据源。它必须在你的生产 Kubernetes 集群中执行所有这些操作。

这个智能体既不是微服务，也不是批处理作业。它的依赖图、凭证占用和执行路径都是动态的。我们将在本文中介绍在 Kubernetes 上运行自主诊断智能体系统总结出来的基础设施模式：隔离、密钥管控、渐进式信任和可观测性——针对一种打破大多数 Kubernetes 安全模型假设的工作负载类别。

为什么 AI 智能体会打破现有的 Kubernetes 安全模型

大多数 Kubernetes 安全模型会假设工作负载具有明确定义的依赖集、调用定义好的外部服务列表，并以可预测的方式消耗资源。

因此，在配置基于角色的访问控制（RBAC）、网络策略和资源限制时，目的都是将工作负载约束在既定边界之内。但需要注意的是，自主式 AI 智能体打破了所有这些固有假设。

AI 智能体创建动态外部依赖

自主 AI 智能体不存在固定的 API 调用集合。在运行时，智能体根据生成的假设决定查询哪些数据源。例如，在某一次故障排查中，智能体可能只需要调用日志聚合服务即可结束流程，但在另一次排查中可能需要将网络遥测、应用程序性能指标、安全事件日志或拓扑图的数据串联起来。因此，不可能提前制定一套网络策略来覆盖智能体后续可能需要访问的所有资源。

AI 智能体需要多域凭证

跨域诊断智能体在运行时需要的凭证包括：网络监控、应用性能工具、日志聚合、安全事件流、拓扑服务以及 LLM 推理 API，这就需要将大量密钥统一存储在单个容器中。

AI 智能体的资源利用率具有不可预测性

排查连接问题的诊断智能体可能只占用 200MB 的内存，并可在 90 秒内完成。对于跨越四个领域的级联故障，智能体可能需要占用 4GB 内存来处理 20 万条或更多的日志条目，耗时长达 15 分钟。这种动态变化的资源消耗导致无法设置静态资源限制。

AI 智能体的执行流程具有不确定性

它们的执行流程依赖中间推理，包括形成假设、检索证据、评估证据并完善或拒绝假设。因此，两次排查可能具有相同的初始问题描述，但智能体的执行路径可能完全不同，完全取决于数据所揭示的信息。这种不确定性导致无法为异常检测划定正常行为或基准基线。

如果你用与正常服务相同的假设来部署自主智能体，隐患通常不会在设计评审阶段出现，只会在第一次突发故障事故中暴露出来。

图 1. Kubernetes 上的智能体安全区域。

Kubernetes 的作业模式：默认隔离

将每次智能体排查视为独立的 Kubernetes 作业，而不是长期运行的部署，这会带来至关重要的影响。

最初，我们创建了一个部署，设置副本数，并让调度器管理部署。然而，这种方法没有持续多久。某一次内存消耗超出预期的排查任务会影响同一 Pod 内正在运行的其他排查任务。一个导致长时间推理循环的病理案例会占用其他排查任务所需的资源。一个因等待 LLM API 响应而超时的排查任务需要重启整个引擎进程。将每次排查都作为单个 Kubernetes 作业运行具备四个特性：资源隔离、故障隔离、干净的状态和排查范围的审计追踪。

资源隔离

每个排查任务都有自己的容器，有自己的 CPU 和内存分配。需要处理 20 万行日志信息的复杂排查任务不会挤占其他排查任务的资源。你可以根据排查复杂度为每个作业设置资源限制。

故障隔离

如果一个作业因内存溢出错误或 API 超时失败，只有当前作业会受到影响，不需要重启其他排查任务。一旦作业运行失败，Kubernetes 会记录失败状态并继续执行其他任务。

干净的状态

每个作业都从新的容器镜像启动，规避了排查任务之间状态泄露的风险。因此不会存在过时上下文、累积内存碎片或是残留临时文件这类问题。

审计追踪

每个作业都有自己的日志流，包含开始和结束时间戳，以及自己的资源消耗指标。因此，如果你想调试某个返回错误结果的排查任务，可以拉取这个作业的日志，无需在共享进程的混杂输出中筛选。

在实践中，编排流程如下：

• 用户通过 API 启动排查。

• 后端验证每个传入的请求，分配唯一的排查 ID，并存储相关元数据。

• 通过验证后，后端通过直接 API 调用为每次排查创建一个 Kubernetes 作业。在开始集成时，我们选择了简单的基于 API 的模式，而不是自定义控制器，因为我们的执行模型是每个排查任务一个作业，不需要队列或协调逻辑。

• 每个作业都包含特定的元数据、HashiCorp Vault 注入的凭证和特定的资源限制。

• 智能体连接到相关数据源，执行排查任务，并通过消息总线流式推送中间结果。

• 最终结果写入数据库并在 UI 上展示。

• 完成后，作业终止。Kubernetes 在清理资源前会保留作业状态用于审计和调试。

下面是一个精简的作业规范示例：

apiVersion: batch/v1kind: Jobmetadata:  name: investigation-{{ investigation_id }}  labels:    app: autonomous-diagnostics    investigation-id: "{{ investigation_id }}"    trust-phase: "{{ phase }}"spec:  backoffLimit: 0  activeDeadlineSeconds: 900  ttlSecondsAfterFinished: 3600  template:    spec:      serviceAccountName: agent-phase-{{ phase }}      restartPolicy: Never      containers:      - name: agent        image: "{{ ecr_image }}"        env:        - name: INVESTIGATION_ID          value: "{{ investigation_id }}"        resources:          requests:            cpu: "500m"            memory: "1Gi"          limits:            cpu: "2"            memory: "4Gi"

重要的不在于具体的 YAML 配置，而在于将作业边界作为调度、超时、重试、可审计性及资源清理的基本单元。当需要重试时，我们使用作业级别的失败策略，而不是不透明的应用程序重试机制，以便在 Kubernetes 层面区分终端失败和可重试失败。只有当准入、优先级或队列反压需要进入集群控制平面时才有必要引入自定义控制器。

创建新作业的开销（通常需要 2 到 5 秒的调度和容器启动时间）与整体排查时间（从 90 秒到 15 分钟不等）相比微不足道。作业隔离的优势远超过启动成本。

图 2. 排查生命周期：每次排查对应一个 Kubernetes 作业

密钥管理：多域环境下的爆炸半径控制

自主 AI 智能体的密钥管理与传统微服务存在本质差异，因为被入侵容器的影响波及范围在设计层面本身就要大得多。

跨域诊断智能体在运行时需要的凭证包括：LLM 推理 API 密钥、日志聚合凭证、网络监控认证令牌、云存储访问密钥，以及可能用到的拓扑图数据库和安全事件流凭证。在我们的系统中，单个智能体容器会横跨四到五个不同的基础设施领域。

如果容器被入侵，攻击者将获得对整个运营栈的访问权限。这种情况并不是假设性场景。运行 LLM 驱动的工作负载并向多个第三方 API 发起出站 HTTPS 调用的容器具有高度网络连接性。我们使用 HashiCorp Vault 来应对这一风险。

动态、短期凭证

智能体作业在启动时会使用 Kubernetes 服务账户令牌向 Vault 完成身份认证，获取仅在排查期间有效的凭证。一旦作业执行完毕，凭证便即刻失效。由此，排查任务的运行时长限制了被入侵容器可被利用的时间窗口。

域独立密钥路径

每个域均设有独立的访问路径，网络监控凭证、日志聚合令牌、LLM API 密钥等都各自具备审计追踪能力。这种隔离方式能够清晰追溯：各种域凭证在何时、被哪项排查任务访问。

不将静态密钥存入 Git 或环境变量

Vault 智能体注入器统一处理身份认证、检索、注入和撤销操作。即使有人拉取 ECR 镜像或搜索 Git 历史也不会找到任何有效的敏感信息。

无需重新部署即可轮换凭证

如果你要轮换 LLM API 密钥或监控服务令牌，只需更新 Vault。下次启动作业时，它会获取到新的凭证。不需要进行 Helm 升级、ArgoCD 同步或部署滚动重启。当你管理超过多个外部服务的凭证时，这些优势远比想象中更为关键。

我们曾讨论过是为每次排查任务分配唯一的 Vault 身份，还是统一使用同一个智能体身份。我们最终选择采用带有分域策略的单一智能体角色，因为为每次排查单独管理唯一 Vault 身份所带来的运维复杂度远高于其带来的边际安全收益。作业隔离模式已经限制了时间爆炸半径，Vault 则限制了凭证爆炸半径。两者结合，为第一阶段的生产环境提供了足够的安全性。短期凭证减少了暴露时间，而按排查独立身份则有助于优化溯源归因能力。这两种手段彼此关联但定位不同，随着排查流程融入事后复盘工作流，二者的差异会体现得更加明显。我们将在“我们本可以做出的改进”章节重新审视这一决策。

在实践中，阶段性 Vault 策略看起来像这样：

# Phase 1 (Shadow): read-only data source credentialspath "agent/data/datasources/*" {  capabilities = ["read"]}path "agent/data/llm/inference" {  capabilities = ["read"]}# Phase 3 (Limited Remediation): adds scoped write credentialspath "agent/data/remediation/pod-restart" {  capabilities = ["read"]}path "agent/data/remediation/cache-clear" {  capabilities = ["read"]}

智能体代码库在各个阶段都请求相同的 Vault 路径，真正发生变化的是 Vault 对这些请求的授予或拒绝权限。阶段晋升是 Vault 策略的更新和 Helm 配置值的变更，而不是代码部署。

四阶段信任模型：渐进式访问框架

在一开始就给自主智能体凭证无异于让企业自陷风险。运营基础设施的人员需要循序渐进建立信任。我们创建了一个四阶段信任模型，为平台团队提供了一条清晰、可观察的路径，从零信任基线逐步过渡至全自主运行状态。

第一阶段：影子模式

智能体在生产数据上运行，但生成的输出不会流转出去。诊断结果由人工事后审核，并与已知结论进行比对。智能体对各类数据源仅拥有只读权限，无法执行任何操作。第一阶段的核心问题在于：智能体是否能够生成有价值的分析结果？

第二阶段：只读辅助

智能体以推荐引擎的形式提供给运维团队。当故障发生时，智能体自动运行，向值班工程师展示假设树与证据链。值班工程师可以采纳、驳回或修正智能体给出的诊断结论。智能体依旧不具备任何写入权限。第二阶段需要验证的问题是：运维团队是否会信任智能体的推理逻辑？

第三阶段：有限修复

这一阶段允许智能体在获得运维人员明确批准后执行低风险修复操作（例如重启 Pod）。在这个阶段，智能体的写入权限由专属的 Kubernetes RBAC 角色进行限定，仅允许在指定资源上执行特定 API 操作。第三阶段的核心问题是：智能体能否安全执行相关操作？

第四阶段：自主 L1

智能体可自主解决所有常规故障，无需运维人员介入。当智能体置信度低于设定阈值或请求执行超出授权范围的修复操作时，便会自动上报升级。智能体的所有行为均会记录到审计日志中。第四阶段的核心问题是：我们是否能够依靠智能体承担夜间值班工作？

阶段之间的转换以运维实际成效为依据，而不是由时间线或路线图压力决定。在我们的实现中，各阶段的晋升标准如下：

人工信任指标侧重运维实际表现，而非单纯依靠统计数据。“最少编辑”指运维人员不改动原始根本原因分类及建议修复分类，仅调整表述措辞、流程顺序或佐证依据。从第三阶段晋升至第四阶段需要经过运维负责人与平台负责人共同审批同意，因为二者承担着不同维度的故障风险。

晋升标准应与降级标准相结合。满足以下任一条件时，系统将退回至上一阶段，并需要在审查后方可重新晋升：

• 近 30 天诊断准确率低于 92%。

• 故障回滚率超过 2%。

• 智能体出现超出授权范围的操作行为。

没有回滚规则的框架是不完善的。

每个团队的指标数值都会有所差异。需根据自身的事故数量、严重程度以及组织可承受的风险水平自行校准设定。

图 3. 渐进式信任模型：按阶段划分的基础设施权限。

这个模型在基础设施层面的意义在于你需要对 Kubernetes RBAC、Vault 策略和网络策略按阶段做参数化配置。智能体代码库在四个阶段保持统一，真正变化的是基础设施赋予智能体的权限等级。每个阶段都有独立的 Helm 配置文件、Vault 策略与网络策略。这正是 GitOps 体现价值的地方：所有权限变更均在 Git 提交中完成记录、评审与审计。

非确定性工作负载的可观测性

标准的可观测性方法并不适用自主智能体工作负载，因为其基本工作单元是迭代式的假设、评估与完善循环。

我们采用 Prometheus 采集指标、Grafana 展示看板、Loki 聚合日志，搭建起标准的云原生可观测性技术栈。但我们所创建的监控看板和传统服务的监控看板非常不同。

排查级指标，而非请求级指标

我们追踪已启动、已完成和已失败的故障排查。我们收集完成排查的平均时间作为域复杂度的函数。我们收集每次排查执行的假设评估循环次数。我们不收集此类工作负载的 p99 延迟，因为排查可能短则 90 秒、长可达 15 分钟。

将 LLM API 调用消耗量列为一级运维指标

智能体的推理依赖对外部 LLM 推理 API 的调用，因此 LLM 供应商的速率限制和延迟直接影响着你的关键路径。我们追踪每次排查的 LLM API 调用总数、每次调用的平均完成时间、每次调用消耗的词元数、每次调用的错误率和每次调用的成本。这些指标中任意一项出现陡增都是智能体出现故障前可供问题排查的征兆。

排查级成本归因

排查的总成本包括 LLM 推理、Kubernetes 计算、检索和工具调用，以及存储或出站流量。参照 2026 年年中前沿推理模型的定价标准，单域的简单排查通常需要 4 至 8 次 LLM API 调用，约消耗 1.5 万至 2.5 万输入词元、3 千至 5 千输出词元，对应推理成本为 15 至 40 美分。而复杂的跨域排查需要进行 15 至 30 次 LLM API 调用，消耗 8 万至 15 万输入词元、1 万至 2 万输出词元，预估推理成本在 1.5 至 4 美元之间。

如果再计入 Kubernetes 作业容器的计算成本，复杂排查的总成本区间为 2 至 6 美元。因此，每天进行 50 次排查的运营团队每月的预估成本可能达到 3 千至 9 千美元。前 10%的复杂排查占总支出的 60%以上。如果没有按单次排查做成本归因，这类开销会被隐藏，混杂在聚合的云账单和 LLM API 费用账单中。需要注意的是，行业数据表明，同等模型性能下的推理成本每年约下降十倍，因此具体金额会随之变动，但不同排查类型之间的相对成本占比结构会长期保持稳定。

推理深度作为健康信号

我们统计每次排查所需的假设和评估迭代次数。如果排查迭代超出指定次数仍未收敛，智能体就有可能陷入推理循环。这为卡住的智能体提供了一种“熔断”机制，与对确定性服务所做的熔断逻辑一样。例如，对于简单的单领域排查，我们设置 8 次循环上限，或取该层级常态 P95 循环数的两倍，以先达到的条件为准进行熔断。对于跨多领域排查，上限则设为 15 次循环或 P95 值的两倍。触发熔断后，智能体将带着完整证据链进行升级处理，而非继续在低概率检索路径中无谓消耗词元。

作业日志隔离

我们隔离每个作业生成的日志，在排查出现错误结果时可以单独拉取对应作业的日志，查看智能体得出错误结果所使用的推理链路。这种方式既可以用于调试智能体运行行为相关问题，也能够对结论背后的推理过程进行审计。

我们的可观测性工具集用于监控自主智能体的运行健康度和推理质量。要在生产环境中稳定运行自主智能体，需要有两类监控。

部署流水线：面向智能体工作负载的 GitOps

对于智能体工作负载而言，GitOps 的重要性并不在于 Helm 和 ArgoCD 是最佳实践，而在于智能体的风险蕴藏在配置中。一旦信任阶段、RBAC 权限范围、Vault 策略、网络出站规则和资源限制在开发、预发、生产环境中出现差异，就不再拥有统一的部署状态。取而代之的是一套安全状态矩阵。三个阶段分别对应三个环境，共产生 12 种不同的权限配置，每一种都必须纳入版本控制且可审计核查。

# values-production-shadow.yamltrustPhase: shadowagent:  serviceAccountName: agent-phase-shadow  rbac:    verbs: ["get", "list", "watch"]    resources: ["pods", "logs", "events"]  vault:    policy: agent-readonly  networkPolicy:    egressAllowed: ["datasources"]# values-production-limited-remediation.yamltrustPhase: limited-remediationagent:  serviceAccountName: agent-phase-remediation  rbac:    verbs: ["get", "list", "watch", "patch", "delete"]    resources: ["pods", "logs", "events"]  vault:    policy: agent-remediation  networkPolicy:    egressAllowed: ["datasources", "remediation-targets"]

需要注意的是，将智能体从影子模式晋升到生产环境的有限修复只需要一个 Helm 值变更和 Vault 策略更新，通过拉取请求完成审核即可，无需进行代码部署。

在该模型中，漂移检测是必需的安全控制，而不只是方便自动部署的附加功能。如果管理员在故障排查时扩大了智能体的 RBAC 策略，然后忘记恢复，ArgoCD 应该能够主动检测到这类配置漂移并自动完成同步修复，因为对于智能体工作负载类别而言，配置漂移等同于爆炸半径漂移。

我们本可以做出的改进

如果重新来过，我们会从一开始就为每一次排查单独配置 Vault 身份。借助自动化手段，运维复杂度完全可以管控，而能够溯源每一次排查所创建的具体凭证，其事后审计排查的价值完全值得我们的投入。

我们也会更早搭建排查级别的成本归因体系。如可观测性部分所述，每次排查的成本差异很大。将这些成本归因到每一次排查以及对应的事故类别后，运维团队便可判断哪些事故类别适合自动化处理，哪些仍需保留人工排查。

最后，我们会把四阶段信任模型纳入基础设施的初始设计，而非事后再做改造。仅使用环境专属的 Helm 配置并不够，还需要为每个环境单独定义各阶段专属的 Helm 配置。阶段之间的晋升流程和环境之间的晋升流程不一样。

结论

自主 AI 智能体正在进入你的 Kubernetes 集群，无论你的安全模型是否已经做好准备。部署它们的团队会从默认模式开始：一个部署配置、一些带着 API 密钥的环境变量，剩下就是祈祷。这种基础部署模式与生产级安全性之间的差异都建立在相同的云原生构建块之上：用作业做隔离、用 Vault 管理密钥、用 RBAC 实现访问控制、用 GitOps 保障可审计性，再搭配适配非标准指标的常规可观测性工具。

更棘手的问题不在技术层面，而在组织层面。想要让自主智能体访问生产资源，就需要一套信任框架，帮助运维团队逐步建立信心。本文介绍的四阶段模型只是其中一种实现方式，相比具体细节，拥有清晰、可观测的演进节奏更为重要。首先要审计当前 Kubernetes 的安全设定是否符合第二节提出的四项特征：静态依赖、单领域凭证、可预测资源假设与确定性执行。如果现有的 RBAC、故障策略和网络策略是基于以上任一前提设计的，这就是现存的安全短板。先修复边界安全，再以影子模式上线智能体，由数据指标来决定智能体何时晋升至正式生产阶段。

查看英文原文：https://www.infoq.com/articles/securing-autonomous-ai-agents-kubernetes/