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/v1 kind: Job metadata: 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智能体