镜像标签管理需与堡垒机协同实现“身份—操作—溯源”闭环，强制使用语义化+签名标签（如prod-v2.4.1-20261009-8a3f7c），部署须经堡垒机审批与代理执行，并确保标签、会话、审计日志全链路对齐。
镜像标签管理本身不直接接入堡垒机，但它和堡垒机共同构成CI/CD流水线的“身份—操作—溯源”闭环。关键不在标签本身，而在标签如何绑定可信来源、限制部署权限、并被审计系统捕获。
标签必须携带可验证的构建上下文
单纯用 v1.2.3 或 latest 标签无法支撑安全管控。应强制使用语义化+签名标签，例如：
-
prod-v2.4.1-20261009-8a3f7c：含环境、版本、日期、Git短哈希 -
staging-signed-20261009T1422Z：带时间戳和“signed”标识，由CI系统调用密钥签名后写入镜像元数据
堡垒机不解析标签，但CI流水线在触发部署前，需通过API将该标签及签名摘要提交至堡垒机审批接口——只有经审批的标签才被允许拉取到生产环境服务器。
部署动作必须经堡垒机代理执行
禁止CI Agent直连目标服务器执行 docker pull && docker run。正确路径是：
- CI流水线生成带签名的镜像标签，并上传至私有镜像仓库（如ACR/ECR）
- 流水线调用堡垒机开放API，发起“部署申请”，附带镜像URL、标签、目标主机资产ID、申请人账号
- 堡垒机校验申请人权限、标签签名有效性、目标主机是否在授权范围内；通过后生成一次性会话令牌
- CI Agent持令牌连接堡垒机Koko/JSOC组件，在受控会话中执行部署命令——全程录播、命令级审计
标签生命周期需与堡垒机审计日志对齐
每次成功部署产生的会话ID、操作用户、源IP、执行命令、镜像标签、启动时间，必须统一落库，并支持交叉查询。例如：
- 运维人员在堡垒机回放某次部署录像，能直接看到当时拉取的是
prod-v2.4.1-20261009-8a3f7c - 安全团队从镜像仓库查出该标签被部署过3次，反向检索堡垒机会话日志，确认每次均由不同审批人+双因子认证通过
- 发现某标签被未授权账号尝试拉取，堡垒机自动阻断并告警，同时镜像仓库同步标记该标签为“可疑”
避免三个典型断点
常见疏漏不是技术做不到，而是流程没串起来：
- CI用
root账号直连服务器部署 → 应切换为堡垒机托管的专用部署账号，密码/密钥由堡垒机动态分发 - 镜像打标签阶段未集成签名工具（如cosign、notary）→ 导致标签可被篡改，堡垒机审批失去意义
- 堡垒机只记录“用户A执行了shell命令”，但未提取命令中的镜像标签字段 → 审计时无法关联到具体镜像版本，失去追溯价值
