使用Agent Sandbox安全巡检

扫描范围边界

基线巡检只列举上表中的 9 类资源，不读取 Pod、Deployment、Service、ConfigMap 或 Secret。组件的 ClusterRole 也只授予这 9 类资源的 get 与 list，没有 watch，没有任何写动作。

因此以下内容不在扫描范围内：

• 集群的系统组件（kube-system 下的各类工作负载，包括本组件自身）

• 业务命名空间中的普通 Pod 与 Deployment

• 任何 Secret 的内容

认证与传输

巡检与扫描

集群内直连（推荐）

在集群内以 Job 或 CronJob 调用 Service，凭据从 Secret 注入，不落本地。Service 各端口如下：

kubectl -n kube-system get svc ack-agent-sec-scanner
# api:8443（HTTPS） health:8080（HTTP） console:8444（HTTPS）

Job 示例：

apiVersion: batch/v1
kind: Job
metadata:
  name: asc-scan
  namespace: kube-system
spec:
  ttlSecondsAfterFinished: 3600
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: scan
          # 需支持 TLS 1.3。curl 或任意语言 SDK 均可；
          # busybox 内置的 wget 只支持到 TLS 1.2，无法握手。
          image: <含 curl 的镜像>
          env:
            - name: KEY
              valueFrom:
                secretKeyRef:
                  name: ack-agent-sec-scanner-api-key
                  key: api_keys.yaml
          command:
            - sh
            - -c
            - |
              B=https://ack-agent-sec-scanner.kube-system.svc:8443
              curl -sk -X POST "$B/api/v1/cluster-baseline/scan" \
                -H "X-API-Key: $KEY" -H 'Content-Type: application/json' -d '{}'

注意点：

• /health 在独立的 8080 端口且为明文 HTTP，不需要认证也不需要 TLS，适合做存活探测。业务接口在 8443，必须走 HTTPS。

• 客户端必须支持 TLS 1.3。组件强制 min_version: 1.3，请确认镜像的 TLS 客户端支持 TLS 1.3。

使用 kubectl port-forward 时的注意事项

port-forward 会在本机开一个监听端口，同机其他进程可复用该通道；它也不经过 Pod 网络路径，因此为组件配置的 NetworkPolicy 对它无效。

获取扫描 API 的访问凭据

扫描 API（8443 端口）默认要求 API Key。组件安装时会自动创建 Secret 并生成随机 Key：

kubectl -n kube-system get secret ack-agent-sec-scanner-api-key \
  -o jsonpath='{.data.api_keys\.yaml}' | base64 -d

预期输出：

api_keys:
  - key: "xxxxxxxxxxxxxxxx"
    tenant_id: dev
    roles:
      - admin

后续所有 API 调用需带 X-API-Key 头。本文后续示例假设已通过 port-forward 将扫描 API 映射至本地 8443 端口，并因默认自签证书使用 -k 跳过 TLS 校验：

kubectl -n kube-system port-forward svc/ack-agent-sec-scanner 8443:8443
export ASC_KEY='<YOUR-API-KEY>'
curl -sk -H "X-API-Key: $ASC_KEY" https://127.0.0.1:8443/api/v1/scans

为什么默认要求鉴权：8443 的接口可以发起扫描、读取集群基线巡检结果、更新规则。巡检结果会包含当前集群中沙箱的不当特权配置，不能对集群内任意工作负载开放。健康探针端口（8080）不需要 Key，以免 kubelet 探测失败。

api_keys:
  - key: "<YOUR-CI-KEY>"
    tenant_id: dev
    roles: [admin]
  - key: "<YOUR-READONLY-KEY>"
    tenant_id: dev

kubectl -n kube-system patch secret ack-agent-sec-scanner-api-key \
  --type merge -p "$(cat <<'EOF'
stringData:
  api_keys.yaml: |
    api_keys:
      - key: "<YOUR-NEW-KEY>"
        tenant_id: dev
        roles:
          - admin
EOF
)"
kubectl -n kube-system rollout restart deploy/ack-agent-sec-scanner

扫描 Agent 组件

tar czf my-skill.tar.gz my-skill/

curl -sk -X POST https://127.0.0.1:8443/api/v1/skills/scan \
  -H "X-API-Key: $ASC_KEY" \
  -H 'Content-Type: application/octet-stream' \
  --data-binary @my-skill.tar.gz

{"id":"b124351d-2db0-49c1-b9ab-a6a3f735f94b","status":"pending"}

curl -sk -H "X-API-Key: $ASC_KEY" \
  https://127.0.0.1:8443/api/v1/scans/b124351d-2db0-49c1-b9ab-a6a3f735f94b

{
  "status": "succeeded",
  "result": {
    "summary": {
      "total_findings": 38,
      "security_score": 0,
      "by_severity": {"critical": 10, "high": 22, "medium": 5, "info": 1}
    },
    "findings": [
      {
        "rule_id": "MCP-POISON-001",
        "severity": "critical",
        "title": "Tool Description Poisoning",
        "location": {"file": "my-skill/skill.yaml", "line": 11},
        "remediation": "Remove hidden instructions from tool descriptions...",
        "metadata": {"owasp_asi": "ASI01", "owasp_asi_label": "Agent Goal Hijack"}
      }
    ]
  }
}

curl -sk -X POST https://127.0.0.1:8443/api/v1/mcp/scan \
  -H "X-API-Key: $ASC_KEY" \
  -H 'Content-Type: application/octet-stream' \
  --data-binary @mcp.json

curl -sk -H "X-API-Key: $ASC_KEY" \
  "https://127.0.0.1:8443/api/v1/scans/<YOUR-TASK-ID>/reports?format=sarif" -o report.sarif

查看集群安全基线巡检

基线巡检默认开启，按 baseline.interval（默认 30 分钟）周期执行。也可手动触发：

curl -sk -X POST -H "X-API-Key: $ASC_KEY" \
  https://127.0.0.1:8443/api/v1/cluster-baseline/scan

查看巡检历史：

curl -sk -H "X-API-Key: $ASC_KEY" \
  https://127.0.0.1:8443/api/v1/cluster-baseline/sweeps

巡检结果中的 rule_coverage 字段给出逐规则的判定状态，共三态：

not_applicable 的常见原因：

not_applicable 不等于通过。例如 SANDBOX-CRED-005（凭据 Secret 明文长期密钥检查）在巡检模式下恒为 not_applicable / kind_absent，因为组件的 ClusterRole 刻意不申请 Secret 读权限。要覆盖该规则，需通过上传 manifest 的方式扫描（POST /api/v1/baseline/scan）。

baseline.namespaces 决定默认范围。若只想临时查看某几个命名空间，在触发请求里带上 namespaces：

curl -sk -X POST https://127.0.0.1:8443/api/v1/cluster-baseline/scan \
  -H "X-API-Key: $ASC_KEY" -H 'Content-Type: application/json' \
  -d '{"namespaces":["team-a","team-b"]}'

• 省略该字段或传空数组，均按 baseline.namespaces 的配置执行。

• 名称按 Kubernetes 命名空间规则校验，非法值返回 422，不会被送往 API Server。

• 单次最多 64 个命名空间（每个命名空间都会成倍增加 List 调用）。

• 返回的 sweep 对象带 namespaces 字段，记录本次实际范围。

内置基线规则

共 22 条，分四组：

威胁分类标准

组件采用 OWASP Top 10 for Agentic Applications 2026（ASI）作为唯一的威胁分类标准。每条 finding 携带两个字段：

• metadata.owasp_asi：类目编码，如 ASI05

• metadata.owasp_asi_label：可读标签，如 Unexpected Code Execution

可据此按 ASI 类目聚合结果，接入更大的合规流程。

ASI07、ASI08、ASI10 当前无规则覆盖：这三类分别需要跨 Agent 的通信拓扑、运行时失效序列与行为偏离基线，都不是静态配置或单个制品扫描能判定的问题，属于运行时安全产品的范畴。7 条 INFRA-CFG-* 规则不带 ASI 标注，它们检查的是推理服务端点的通用暴露面问题，映射到 ASI 会牵强。

Skill 技能扫描（6 条）

代码扫描（8 条）

CODE-BEHAV-001 与 CODE-BEHAV-002 检的是行为链而非单点模式——单看任一半都不构成风险，组合起来才是。

MCP 扫描（4 条静态 + 运行时检查）

静态规则作用于 MCP 配置：

运行时扫描对活体 MCP Server 发起 tools/list 枚举，额外检查：

隐藏控制字符这类问题只能靠扫描发现——它的设计目的就是躲过人工审查。

AI 基础设施扫描（7 条配置 + 33 条 CVE）

配置暴露面检查：

CVE 库共 33 条，全部带 source_url，按组件分布：

匹配流程是先指纹识别组件与版本（7 条指纹探测），命中后再比对 CVE。CVE 库不作用于制品依赖清单，只用于 AI 基础设施端点探测。

Agent 黑盒红队（7 条）

对运行中的 Agent 端点发起对抗性探测，需显式开启 agent.enabled 并配置目标白名单。

该扫描会对目标发起真实调用并驱动 LLM 红队循环，因此默认关闭。

内置的过程性规则

除风险规则外，组件还会输出说明扫描过程本身的 finding，用于区分“检查通过”与“没能检查”：

这类 finding 严重度为 info，不影响评分，但会出现在报告中。它们的存在是为了让“未检查”可见。

LLM 语义增强

组件可选接入大模型，对 Skill 与代码扫描追加语义分析层，识别规则难以覆盖的逻辑类风险（例如“这段代码的意图是外传凭据”）。该能力默认关闭。

{
  "id": "SKILL-LLM-INFO",
  "rule_id": "llm-degraded",
  "severity": "info",
  "title": "LLM semantic analysis was skipped",
  "metadata": {
    "reason": "api_error: api error: status 401: Incorrect API key provided...",
    "source": "llm"
  }
}

获取初始口令

组件安装时会自动创建 Secret 并生成随机初始口令。读取：

kubectl -n kube-system get secret ack-agent-sec-scanner-console-auth \
  -o jsonpath='{.data.password}' | base64 -d; echo

组件不预置固定默认口令。初始口令为本次安装专属的随机值，不同集群不同。系统仅保存该口令，不提供找回入口；遗忘后按轮换口令重设。

访问

kubectl -n kube-system port-forward svc/ack-agent-sec-scanner 8444:8444

浏览器打开 https://127.0.0.1:8444，用户名 admin，口令为上一步读取的值。

必须使用 HTTPS。控制台的会话 Cookie 带 Secure 属性，通过 HTTP 访问时浏览器不会回传 Cookie，登录无法完成。

默认使用组件自签的证书，浏览器会提示证书不受信——这是预期行为：自签证书保护传输，不提供身份证明。需要受信证书时，将 kubernetes.io/tls 类型的 Secret 名填入 console.tls.existingSecret。

控制台包含五个页面：

轮换口令

方式一：直接更换明文

kubectl -n kube-system patch secret ack-agent-sec-scanner-console-auth \
  -p '{"stringData":{"password":"<YOUR-NEW-PASSWORD>"}}'
kubectl -n kube-system rollout restart deploy/ack-agent-sec-scanner

方式二：只保存哈希（静态数据中不留明文）

H=$(kubectl -n kube-system exec -i deploy/ack-agent-sec-scanner -- \
     agent-sec-scanner hash-password <<< '<YOUR-NEW-PASSWORD>')

kubectl -n kube-system patch secret ack-agent-sec-scanner-console-auth \
  -p "{\"stringData\":{\"hash\":\"$H\"},\"data\":{\"password\":null}}"
kubectl -n kube-system rollout restart deploy/ack-agent-sec-scanner

Secret 支持 hash（argon2id 哈希）与 password（明文）两个键，hash 优先。口令最小长度 8 字符。修改后需重启生效（凭据在启动时读入内存，不热加载），重启会登出所有已登录会话。

agent-sec-scanner hash-password 不接受将口令作为命令行参数——argv 对 ps 可见并会进入 shell 历史。交互式输入去掉 <<< 部分即可。

Pod 启动失败，日志出现 rules root does not exist？

镜像内规则目录缺失，此时组件会拒绝启动而不是带着零规则运行。

巡检结果里大量规则是 not_applicable，是否说明配置都合规？

不是。not_applicable 表示无法判定，需查看 reason：crd_missing 说明对应组件未安装、kind_absent 说明集群中无该类资源或组件无权限读取。判定通过的状态是 passed。

控制台端口连不上，日志出现 console is enabled but no credential is configured？

Secret 中 hash 与 password 两个键都为空。按获取初始口令确认 Secret 内容，或按轮换口令设置一个。此时控制台不对外提供服务，但扫描能力不受影响。

登录后立刻跳回登录页？

会话 Cookie 被浏览器丢弃。确认使用的是 https://——HTTP 下带 Secure 属性的 Cookie 不会回传。

一直提示“用户名或口令不正确”，但口令确认无误？

可能已触发锁定。连续失败达 console.loginMaxFails（默认 5 次）后锁定 console.loginLockMinutes（默认 15 分钟），锁定期间即使口令正确也返回同一句提示。可查看认证审计链中是否有 lockout 事件。口令错误、账号不存在、锁定中三种情况返回相同的提示文案，不透露具体原因，以避免泄露账号是否存在。

修改了 Secret 里的口令但登录仍用旧口令？

凭据在进程启动时读入内存，不热加载。执行 kubectl -n kube-system rollout restart deploy/ack-agent-sec-scanner 后生效。

扫描报告中出现 SKILL-LLM-INFO 或审计链中出现 llm:degraded？

LLM 通道调用失败，语义增强未执行，本次扫描仅包含规则与内置检测的结果。metadata.reason 给出具体原因，处置方式参见LLM 语义增强。

该次扫描的 findings 数量与评分不包含语义分析结果，合规评审时需视为扫描覆盖不完整。

报告中的 security_score 为空？

扫描范围内没有任何规则被实际应用（例如巡检时集群内无目标资源）。此时组件不给分，而不是给 100 分——“什么都没检”与“检查通过”必须可区分。

调用 API 返回 401 API key required 或 invalid API key？

扫描 API 默认要求 X-API-Key 头。按获取扫描 API 的访问凭据读取 Key 并加上该请求头。控制台不需要 Key。

Pod 启动失败，日志出现 api_key.enabled is true but no keys were loaded？

启用了 API Key 但 Key 库为空或不可读。此时每个请求都会被拒绝，因此组件拒绝启动而不是带着一个谁都用不了的接口运行。检查 apiKey.existingSecret 指向的 Secret 是否存在、其中是否含格式正确的 api_keys.yaml。

巡检会扫到系统组件或业务 Pod 吗？

不会。基线巡检只列举 Sandbox、SandboxSet、SecurityProfile、TrafficPolicy、GlobalTrafficPolicy、CredentialProvider、AgentRole、AgentRoleBinding 与 PersistentVolume 九类资源，不读取 Pod、Deployment、Service、ConfigMap 或 Secret。kube-system 下的系统组件（含本组件自身）与业务命名空间中的普通工作负载都不在范围内。

一个例外：PersistentVolume 是集群级资源，存储面规则会检查集群中的全部 PV，包括系统用途的 PV。这一项无法通过 baseline.namespaces 收窄。

组件会修改集群资源吗？

不会。组件的 ClusterRole 仅包含 get 与 list，无 watch、无任何写动作，且不申请 Secret 读权限。