4. 权限变更风险定义：容器网络运维中的权限变更类型与风险模型
在容器网络运维场景中，权限变更并非单一操作，而是涉及多个维度的权限对象调整。任何对 RBAC、NetworkPolicy 或 ServiceAccount 的变更，都可能引入非预期的攻击面。本章将系统定义这三类权限变更的类型，并建立对应的风险模型，为后续 Sigstore 策略评审提供分析基础。
4.1 权限变更的三大核心类型
容器网络运维中的权限变更可归纳为以下三类，每类变更对应不同的风险特征与审计重点：
| 权限类型 | 变更对象 | 典型变更操作 | 影响范围 |
|---|---|---|---|
| RBAC | Role / ClusterRole / RoleBinding / ClusterRoleBinding | 新增/修改/删除绑定关系；提升 verbs（get, list, watch, create, delete, patch, update）；扩大资源范围（pods, services, networkpolicies） | 集群级或命名空间级 |
| NetworkPolicy | NetworkPolicy 资源对象 | 新增/修改/删除入站/出站规则；调整 podSelector / namespaceSelector / ipBlock；放宽或收紧端口与协议 | 命名空间级（Pod 网络隔离） |
| ServiceAccount | ServiceAccount 资源及其关联的 Secret / | 创建/删除 ServiceAccount；绑定高权限 Role；挂载到高风险 Pod；自动挂载开关变更 | 命名空间级（身份与凭证） |
运维提示： 三类权限变更往往相互关联。例如，一个 ServiceAccount 被绑定到具有 NetworkPolicy 写权限的 Role 后，该 SA 即可修改网络隔离策略，形成权限链式放大风险。
4.2 权限变更风险模型
基于上述三类变更，我们构建一个统一的风险模型，用于评估每次权限变更的潜在危害。该模型包含三个核心维度：暴露面、提权路径、持久化能力。
风险模型公式：
Risk = f(Exposure, PrivilegeEscalation, Persistence)
其中每个维度取值 0-3，综合风险等级分为 Low (0-3)、Medium (4-6)、High (7-9)。
Risk = f(Exposure, PrivilegeEscalation, Persistence)
其中每个维度取值 0-3，综合风险等级分为 Low (0-3)、Medium (4-6)、High (7-9)。
4.2.1 暴露面（Exposure）
- RBAC 暴露： 变更是否将敏感资源（如 secrets、networkpolicies、pods/exec）暴露给非管理员主体。
- NetworkPolicy 暴露： 变更是否放宽了网络隔离，允许来自非信任命名空间或外部 IP 的访问。
- ServiceAccount 暴露： 变更是否将高权限 SA 挂载到可被外部访问的 Pod 上。
4.2.2 提权路径（Privilege Escalation）
- 直接提权： 变更是否允许主体创建/修改 RoleBinding 或 ClusterRoleBinding。
- 间接提权： 变更是否允许主体修改 NetworkPolicy 从而绕过网络隔离，或通过 SA 凭证访问更高权限的 API。
- 横向移动： 变更是否允许主体在命名空间之间或集群之间进行权限扩散。
4.2.3 持久化能力（Persistence）
- 凭证持久化： 变更是否创建了长期有效的 ServiceAccount 或 Secret。
- 策略持久化： 变更是否创建了难以被审计的默认允许策略或宽松的 RBAC 绑定。
- 后门植入： 变更是否允许主体在集群中创建具有隐蔽权限的 ServiceAccount 或 Role。
4.3 三类权限变更的典型风险场景
以下表格列举了每类权限变更中最高频的风险场景，以及对应的风险模型评分示例：
| 权限类型 | 风险场景 | 暴露面 | 提权路径 | 持久化 | 综合风险 |
|---|---|---|---|---|---|
| RBAC | 将 cluster-admin 绑定到默认 ServiceAccount | 3 | 3 | 3 | High (9) |
| RBAC | 允许普通用户创建 RoleBinding | 2 | 3 | 2 | High (7) |
| NetworkPolicy | 删除所有 NetworkPolicy，恢复默认允许 | 3 | 2 | 1 | Medium (6) |
| NetworkPolicy | 添加允许来自 0.0.0.0/0 的入站规则 | 3 | 1 | 1 | Medium (5) |
| ServiceAccount | 创建 SA 并绑定到具有 pod/exec 权限的 Role | 2 | 3 | 2 | High (7) |
| ServiceAccount | 将高权限 SA 挂载到无安全上下文的 Pod | 3 | 2 | 2 | High (7) |
关键风险洞察： 在容器网络运维中，NetworkPolicy 变更往往被低估。虽然它不直接控制 API 权限，但通过放宽网络隔离，可以为攻击者提供绕过 RBAC 审计的通道，例如直接访问数据库 Pod 或 etcd 端口。
4.4 权限变更的链式风险传递
三类权限变更并非孤立存在，它们之间可以形成链式风险传递。以下 SVG 展示了从 ServiceAccount 变更到 NetworkPolicy 绕过，再到数据泄露的典型攻击链：
4.5 风险模型在 Sigstore 策略评审中的应用
在 Sigstore 策略评审中，上述风险模型将作为 策略规则引擎 的输入条件。每次权限变更请求（通过 Kubernetes Admission Webhook 或 CI/CD 管道触发）都会经过以下评审流程：
- 变更解析： 提取变更对象类型（RBAC / NetworkPolicy / ServiceAccount）及具体操作。
- 风险评分： 根据风险模型计算 Exposure、PrivilegeEscalation、Persistence 三个维度的分值。
- 策略匹配： 将评分结果与预定义的 Sigstore 策略规则进行比对（例如：High 风险变更必须经过至少两名维护者签名）。
- 决策输出： 允许 / 拒绝 / 需要额外审批。
实践要点： 建议将风险模型中的每个维度映射为 Sigstore 策略中的
customCheck 条件。例如，当 exposure_score >= 2 且 privilege_escalation_score >= 2 时，要求变更必须附带来自安全团队的 cosign 签名。
通过将权限变更风险模型与 Sigstore 的签名验证机制结合，容器网络运维团队可以在变更发生前识别并阻断高风险操作，实现真正的“左移”安全控制。