1. OpenShift安全体系总览

在OpenShift中，安全不是一个可以单独开启的开关，而是一条贯穿请求生命周期的协同链路。当用户执行 oc get pods、CI流水线推送镜像、或控制器调谐Deployment时，请求会依次经过认证（Authentication）、授权（Authorization）、准入控制（Admission Control），最终被审计（Audit）记录。理解这四者的分工与衔接，是设计安全策略和权限治理模型的前提。

集群安全边界：先划清“谁的地盘”

OpenShift的安全边界首先体现在集群与外部世界之间。API Server是唯一入口，所有kubectl/oc请求、控制器回调和Webhook都必须通过它。边界之外是用户、外部CI、镜像仓库；边界之内是etcd、节点、Pod网络和存储。边界上的关键控制点包括：

• API Server的TLS与端口暴露：默认6443端口对外提供HTTPS，内部组件通过服务网络访问。
• 节点与Pod网络隔离：NetworkPolicy、EgressIP、Multus等决定Pod能否跨命名空间或出集群。
• 镜像来源边界：ImageStream、Registry白名单和ImagePolicy决定哪些镜像能被拉取。
• 基础设施边界：控制平面节点与工作节点的角色分离，etcd只对控制平面开放。

这些边界不是静态的，而是由集群配置、网络插件和云平台共同定义。安全策略的第一步，就是明确哪些边界由平台团队控制、哪些由租户团队控制。

认证：确认“你是谁”

认证解决身份问题。OpenShift支持多种身份提供者：HTPasswd、LDAP、OIDC、GitHub、Keystone等。认证成功后，API Server会签发一个短期Token或使用客户端证书，后续请求携带该凭证。关键点在于：

• 认证只回答“你是谁”，不回答“你能做什么”。
• 系统用户（如 system:admin、system:node）由集群内部管理，普通用户由外部IdP映射。
• ServiceAccount是Pod访问API的身份，Token以Secret形式挂载到Pod内。

例如，一个开发人员通过OIDC登录后，API Server识别其用户名为 alice@example.com，并附加其所属组。此时认证完成，但Alice能否创建Pod、能否读取Secret，仍取决于授权。

授权：决定“你能做什么”

授权在认证之后执行。OpenShift默认使用RBAC（基于角色的访问控制），通过Role、ClusterRole、RoleBinding、ClusterRoleBinding将权限授予用户、组或ServiceAccount。RBAC的核心是“允许”模型：没有明确允许的请求一律拒绝。

授权检查发生在API Server内部，针对每个请求的动词（get、list、create、delete等）和资源（pods、secrets、deployments等）进行判定。例如，一个RoleBinding将 edit ClusterRole绑定到命名空间 dev-team 的组 developers，则该组用户可以在该命名空间内创建和修改大多数工作负载资源，但不能修改RBAC本身或访问集群级资源。

授权是权限治理的核心层。权限治理的目标不是“给每个人足够权限”，而是“用最小权限集支撑业务，同时保持可审计、可回收”。这要求：

• 按团队和命名空间划分RoleBinding，避免集群级通配。
• 定期审查ClusterRoleBinding，尤其是 cluster-admin 的绑定。
• 用ServiceAccount隔离工作负载身份，避免Pod继承过大的用户权限。

准入控制：在落盘前做最后一道检查

授权通过后，请求进入准入控制阶段。准入控制器是一组插件或Webhook，在对象被持久化到etcd之前对其进行校验或修改。OpenShift内置了多种准入控制器，例如：

• SecurityContextConstraint（SCC）：决定Pod能以什么用户、什么能力、什么卷类型运行。
• LimitRanger：为未指定资源的Pod注入默认requests/limits。
• ResourceQuota：拒绝超出命名空间配额的创建请求。
• ImagePolicy：校验镜像来源是否符合集群策略。
• ValidatingAdmissionPolicy / Webhook：执行自定义校验逻辑。

准入控制是安全策略落地的关键。例如，一个Pod请求以root用户运行，SCC会拒绝该请求，除非绑定了允许root的SCC。再如，一个Deployment没有设置资源限制，LimitRanger会注入默认值，而ResourceQuota可能直接拒绝创建。准入控制把“策略”从文档变成了API Server的强制行为。

审计：记录“发生了什么”

审计发生在请求处理过程中，记录谁在什么时间对什么资源做了什么操作，以及结果如何。OpenShift的审计日志分为多个级别：None、Metadata、Request、RequestResponse。审计日志写入文件或转发到外部SIEM。审计的价值在于：

• 事后追溯：谁删除了生产命名空间的Secret？
• 合规检查：是否有未授权的cluster-admin绑定？
• 异常检测：某个ServiceAccount突然大量list secrets，可能是凭证泄露。

审计不是安全链路的终点，而是反馈闭环的起点。通过审计发现的问题，会反过来驱动授权策略和准入策略的调整。

四层协同：一个请求的完整旅程

把四层放在一起看，一个创建Pod的请求会经历如下过程：

1. 认证：API Server验证请求携带的Token或证书，识别用户为 alice@example.com，组为 developers。
2. 授权：RBAC检查 developers 组在目标命名空间是否有 create pods 权限。如果有，继续；如果没有，返回403。
3. 准入：SCC检查Pod的securityContext是否允许；LimitRanger注入默认资源；ResourceQuota检查命名空间配额；ImagePolicy检查镜像来源。任何一步拒绝，请求失败。
4. 审计：整个请求过程被记录，包括用户、动词、资源、结果、时间戳。

如果Pod成功创建，它还会在运行时受到NetworkPolicy、SCC实际约束和节点安全配置的影响。因此，安全体系不是四道独立的门，而是一条链：认证确认身份，授权分配权限，准入执行策略，审计记录行为。任何一环缺失，都会让其他环节的效果打折扣。

权限治理的实践要点

在OpenShift中做权限治理，建议从以下三个动作开始：

• 盘点现有绑定：使用 oc get clusterrolebindings -o wide 和 oc get rolebindings --all-namespaces 找出所有绑定，标记出 cluster-admin、system:admin 和通配权限。
• 按命名空间收敛：把开发、测试、生产的权限绑定到各自命名空间，避免跨环境共享RoleBinding。对需要集群级权限的场景，优先使用专用ServiceAccount而非个人用户。
• 用审计验证：定期检查审计日志中是否有未预期的 create clusterrolebinding、delete namespace 或 get secrets 操作，发现异常后回溯授权配置。