AI Agent 如何安全访问 Kubernetes：9 种认证方式、用法与选型

瀛川
16 阅读8分钟

如果把 Kubernetes (K8s) 集群 比作一座高安全性的写字楼，那么运行在其中的各种 AI Agent、自动化 Bot 就是进出写字楼的“AI 员工”或“外卖员”。

核心安全痛点： 如果直接把能刷开写字楼所有大门的**“物业万能钥匙（管理员 kubeconfig）”**丢给 AI Agent，一旦这个 AI 遇到了“提示词诱导”、“恶意伪造指令”或者“系统被劫持”，整座大楼的所有办公室（集群资源）都会暴露在危险之中。

那么，应该如何给“AI 员工”发入场凭证？本文用生活中的常见场景，带你看懂 K8s 的 9 种认证机制。

选型速查表：AI Agent 应该领哪种“入场券”？

部署场景 (你在哪)生活场景类比推荐认证方案核心机制安全推荐度
集群内 Agent / Operator办公楼内部员工ServiceAccount Token内部工牌，定期自动刷新🟢 强烈推荐
托管云外部 Agent (EKS/AKS/GKE)合作方的驻场代表Workload Identity / 云 IAM凭第三方身份刷脸获取临时入场券🟢 强烈推荐
集群外 Agent / 跨云平台持有统一集团工牌的员工OIDC / JWT总部统一发放的短期电子通行证🔵 推荐
网关型 / 代表多用户操作前台接待处统一验证并登记Authenticating Proxy网关统一核验，核实后领临时访客贴纸🔵 推荐
节点侧 / 低级 Agent驻楼设备维修工X.509 客户端证书盖有物业红章的短期纸质入场许可证🟡 有条件推荐
自定义 / 遗留身份平台门卫打电话给 HR 确认身份Authentication Webhook实时向外部身份库打电话校验🟡 有条件推荐
集群初始化 / 极简探针新楼盘交房时的临时施工证Bootstrap / Anonymous临时凭证 / 仅允许看大楼外观🔴 不适合普通 Agent
硬编码 / 遗留系统门口地毯下埋一把大门钥匙Static Token File永远不换的固定密码，极其危险🚫 严禁使用

一、 先区分认证、授权与准入

在写字楼里，AI 想要去 8 楼的电脑上取一份文件，需要通过三道关卡：

  AI Agent 发起请求
       │
       ▼
1. Authentication (认证)  ───► “你是谁？” (出示工牌/身份证，确认身份合法)
       │
       ▼
2. Authorization (授权)   ───► “你能进这间办公室吗？” (查看门禁权限，RBAC 校验)
       │
       ▼
3. Admission Control (准入) ──► “你带的东西合规吗？” (安检扫描，检查请求是否违规)

💡 生活小常识：

  • 认证成功只代表“你是公司员工”，不代表你能进财务室（授权）。

  • Kubernetes 内部没有“普通用户”这个实体对象，所有外部用户都像是“持外部有效证件的访客”。

二、 核心认证方式与实践（含场景拆解）

1. ServiceAccount Token —— 办公楼内部员工工牌 (集群内首选)

🏢 生活场景

这是 K8s 为“楼内原生员工（Pod）”准备的电子工牌。员工入职时（ Pod 启动），公司会自动在办公桌上放一张动态刷新的电子工牌。如果员工离职（Pod 销毁），这张工牌立即失效。

💻 实践

第一步：给 Agent 办理电子工牌（创建账号）

apiVersion: v1
kind: ServiceAccount
metadata:
  name: reader-agent
  namespace: agents

第二步：配发门禁权限（RBAC：只允许看 Pod，不能删）

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: agents
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: reader-agent-binding
  namespace: agents
subjects:
  - kind: ServiceAccount
    name: reader-agent
    namespace: agents
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

第三步：Agent 挂载工牌上岗

apiVersion: apps/v1
kind: Deployment
metadata:
  name: reader-agent
  namespace: agents
spec:
  replicas: 1
  selector:
    matchLabels:
      app: reader-agent
  template:
    metadata:
      labels:
        app: reader-agent
    spec:
      serviceAccountName: reader-agent # 指定戴哪张工牌
      containers:
        - name: agent
          image: ghcr.io/example/reader-agent:1.0

🔒 安全提醒：如果你的 Agent 只是在内部算算数据，根本不需要找“写字楼管家（K8s API）”办事，请直接关掉领卡功能：automountServiceAccountToken: false。

2. OIDC / JWT —— 集团总部发的动态扫码通行证 (集群外首选)

🏢 生活场景

Agent 在集群外面（比如跨国公司的分支机构）。大楼保安不认识你，但认识集团总部身份系统（如 Keycloak、飞书、微软 Entra ID）。你只需出示总部 App 上的 动态二维码（短期 JWT），大楼闸机扫码确认无误后即可放行。

💻 客户端配置（使用 exec 插件自动刷新）

不要把固定的二维码贴在文件里！在客户端 kubeconfig 中配置“动态生成器”，每次失效自动重新生成：

users:
  - name: external-agent
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1
        command: agent-token-helper # 相当于动态二维码生成脚本
        args:
          - get-token
          - --audience=kubernetes
        interactiveMode: Never

3. Workload Identity 与云 IAM —— 驻场代表的“刷脸互通” (托管云首选)

🏢 生活场景

你在腾讯大厦（AWS/GCP/Azure）办公，要进阿里园区（托管 K8s）办事。两边公司建立了“身份互信协议”。你刷腾讯的脸，阿里门禁系统认出来后，自动给你打印一张临时的阿里访客贴纸。

不用给 Agent 存任何长期密码（如 AWS AccessKey），全程无感且免密。

外部 Agent (如 GitHub Actions)
       │ 1. 出示“腾讯/GitHub”官方身份证明
       ▼
云厂商 IAM 体系 (AWS / Azure / GCP)
       │ 2. 认可身份，自动兑换为 K8s 临时通行证
       ▼
Kubernetes API Server (顺利放行)

4. X.509 客户端证书 —— 盖有物业红章的纸质许可证

🏢 生活场景

类似于物业给“维修工人”签发的一张带公章的纸质证明。上面写着：“持证人：Agent小王，所属部门：维修组，有效期：1小时”。

⚠️ 致命缺陷

写字楼没有办法“作废”已经发出去的纸质证明（K8s 原生不支持证书吊销列表 CRL）。如果纸质证明被偷了，只能等它自己过期。因此，给 Agent 办证书，有效期必须设得极短（如 1 小时）。

5. Authenticating Proxy —— 办公楼前台统一登记处

🏢 生活场景

Agent 不直接和写字楼门禁打交道，必须先经过写字楼大堂前台（网关）。 前台核验完 Agent 的身份后，在前台电脑上敲上一行小字（请求头 X-Remote-User: agent-001），然后开小门把 Agent 带进大楼。

[ Agent ] ──(出示外部凭证)──► [ 前台大堂网关 ] ──(贴上 X-Remote-User 标签)──► [ K8s 门禁 ]

❗️ 安全防范：前台（网关）必须绝对可靠。否则如果有坏人绕过前台，自己手写一张 X-Remote-User: 董事长 的贴纸，就能把大楼搬空！

6. 不推荐或禁止给 Agent 使用的方式

  • Bootstrap Token（临时施工证）：就像建造大楼时给建筑工人用的临时通道密码，仅用于新节点加入集群，普通 Agent 不要凑热闹。
  • Static Token File（钥匙藏在地毯下）：把永久密码硬编码写在服务器文件里。钥匙丢了都不知道，现代 K8s 架构强烈严禁使用。
  • Anonymous（大楼公用卫生间）：未认证身份（system:anonymous），只应该开放给 /livez 这种检查大楼有没有断水断电的公开健康探针。

三、 AI Agent 安全防护“七不原则”

无论你用哪种方式发入场券，给 AI Agent 配置安全策略时，请牢记以下生活常识类比规矩：

  1. 一人一卡，严禁混用 (One Agent, One Identity)：
  • ❌ 清洁工、保安、总经理共用一张卡。
  • ✅ 保洁 Agent 拿保洁卡，巡检 Agent 拿巡检卡。出事能精准追责。
  1. 只给刚好够用的权限 (最小权限原则)：
  • ❌ 为了省事，直接给“写字楼大门到董事长办公室的全套钥匙”。
  • ✅ 巡检 Agent 只要“走廊查看权”，不需要“财务室开锁权”。
  1. 防范“间接提权”高危动作：
  • 在 K8s 里，拿到 secrets（保险箱）、pods/exec（直接进入房间指挥）的权限，就等于拿到了钥匙复制机，必须严加管控。
  1. 拒绝“终身通行证”：
  • 必须使用短期凭据（几分钟至几小时到期），随时失效，随时自动重领。
  1. 绝不把钥匙交给“大脑（LLM）”：
  • ❌ 把门禁卡密码直接写入 Prompt：“你的密码是 123456，去帮我查数据”。（大模型可能会在对话中被套话泄密！）
  • ✅ 大模型只负责下达逻辑指令“请帮我查数据”，由具体的自动化工具 (Tool) 隐式持卡去办。
  1. 高危动作必须“人工盖章” (Human-in-the-Loop)：
  • 当 AI Agent 想要执行“拆除办公室（删除 Namespace）”、“清空档案库（删数据库）”等不可逆操作时，系统必须强制弹窗，让真正的人类管理员点击确认。

四、 极简选型决策树

最后，用一句话帮你选出最适合你家 AI Agent 的方案：

你的 AI Agent 部署在哪？
 ├── 1. 就在 K8s 集群里面运行 ─────────────► 【ServiceAccount 电子工牌】
 ├── 2. 在 AWS / 阿里云 / 腾讯云等外部服务上 ──► 【Workload Identity 刷脸互通】
 ├── 3. 在公司自建的机房服务器上 ────────────► 【OIDC 集团扫码通行证】
 └── 4. 需要代表不同的外部真实用户去干活 ──────► 【Authenticating Proxy 前台统一登记】
avatar
文章
阅读
粉丝