镜像供应链信任边界资源模型与RBAC策略整合设计 - 第1节
1.1 镜像供应链安全背景
在云原生与容器化架构快速普及的今天，软件供应链的攻击面已从传统源码、依赖库扩展至容器镜像的全生命周期。镜像作为应用交付的核心载体，其构建、存储、分发、部署环节均可能被植入恶意载荷或配置后门。近年来多起重大安全事件（如 Codecov 供应链投毒、kube-hunter 镜像逃逸）均表明：镜像供应链已成为攻击者最青睐的突破点之一。
关键威胁趋势：
- 基础镜像污染：官方仓库中的基础镜像被篡改，或使用过时含 CVE 的 base image。
- 构建过程劫持：CI/CD 流水线中 Dockerfile 或 build 参数被注入恶意层。
- 镜像仓库漏洞：私有/公有仓库鉴权薄弱，导致镜像被非法拉取或覆盖。
- 运行时镜像逃逸：容器内残留敏感工具或挂载不当，造成宿主机权限泄露。
传统安全防护多聚焦于“边界隔离”与“漏洞扫描”，但缺乏对镜像从构建到运行全链路的信任传递与访问控制的体系化设计。这直接催生了“信任边界资源模型”与 RBAC 策略整合的迫切需求。
1.2 信任边界概念
信任边界（Trust Boundary）是安全架构中用于划分不同信任等级的逻辑或物理边界。在镜像供应链场景下，信任边界定义了镜像在流转过程中，哪些环节、哪些实体（用户、服务、节点）被默认信任，哪些必须经过验证与授权。
| 信任边界层级 | 典型范围 | 默认信任策略 |
|---|---|---|
| 构建边界 | 开发者本地、CI/CD 构建节点 | 仅信任签名后的基础镜像与已验证的构建脚本 |
| 存储边界 | 镜像仓库（Registry）、缓存代理 | 仓库内镜像需携带数字签名与完整性校验 |
| 分发边界 | 网络传输、镜像拉取/推送通道 | TLS 加密 + 摘要验证，防止中间人替换 |
| 部署边界 | Kubernetes 集群、容器运行时 | 仅允许部署经过策略审批且签名有效的镜像 |
每个信任边界内部维护独立的资源模型：镜像层、签名元数据、部署策略、访问凭证等均被视为受控资源。跨边界的数据流动必须经过身份验证、授权判定与审计记录。
1.3 RBAC 与资源模型整合的必要性
在镜像供应链中，不同角色（开发者、安全审计员、运维工程师、集群管理员）对镜像资源（层、标签、签名、部署策略）的访问需求差异巨大。传统 RBAC 仅基于“用户-角色-权限”三元组，缺乏对资源类型、资源状态、信任等级的细粒度描述，导致以下典型问题：
- 权限粒度粗糙：运维人员可能被授予“仓库管理员”角色，从而获得删除所有镜像层的权限，而实际只需“拉取+部署”权限。
- 信任状态缺失：RBAC 策略无法表达“仅允许部署经过安全扫描且签名有效的镜像”，导致策略与安全状态脱节。
- 跨边界授权困难：镜像从构建边界流转至部署边界时，原有 RBAC 策略无法自动继承或映射，造成权限黑洞。
整合核心价值：将信任边界内的镜像资源抽象为“资源模型”（包含资源类型、属性、状态、关系），再基于该模型设计 RBAC 策略，使权限判定能够感知资源的信任上下文。例如：“允许角色 X 在部署边界内，仅对信任等级 ≥ 高且签名有效的镜像执行 deploy 操作”。
1.3.1 资源模型对 RBAC 的增强维度
| 增强维度 | 传统 RBAC 局限 | 整合后能力 |
|---|---|---|
| 资源类型 | 仅区分“镜像”或“仓库” | 细分为镜像层、签名元数据、部署策略、扫描报告等 |
| 资源属性 | 无属性感知 | 支持基于标签、版本、创建时间、签名状态等属性授权 |
| 资源关系 | 无关系模型 | 表达“镜像属于仓库”、“部署策略关联镜像标签”等关系 |
| 信任等级 | 无信任上下文 | 将信任边界等级（高/中/低）作为资源属性参与策略评估 |
1.3.2 整合后的策略执行流程
- 资源建模：将镜像供应链中所有受控实体（镜像层、签名、策略、凭证）按信任边界分类，构建统一资源模型。
- 角色定义：基于组织职责（如 Developer、Security Auditor、Cluster Admin）定义角色，并关联最小权限集。
- 策略绑定：将 RBAC 策略绑定到资源模型的特定类型、属性或关系上，例如：“允许 Security Auditor 读取所有信任等级为高的镜像的扫描报告”。
- 运行时鉴权：在镜像拉取、推送、部署等关键操作点，调用策略引擎，结合当前资源的信任状态与请求者角色，做出允许/拒绝决策。
- 审计与迭代：记录所有跨信任边界的授权事件，定期分析策略有效性，调整资源模型与角色映射。
常见误区：不要试图在现有 RBAC 系统上直接叠加资源模型标签，而应重新设计资源抽象层。否则会导致策略膨胀、规则冲突，最终难以维护。建议从最小信任边界（如构建边界）开始试点，逐步扩展至全链路。