Flux2 项目中 OpenShift SCC 的声明式配置实践

背景介绍

在 Kubernetes 生态系统中，OpenShift 作为企业级发行版提供了额外的安全控制机制，其中 Security Context Constraints (SCC) 是其特有的安全特性。SCC 定义了 Pod 和容器运行时的权限边界，比标准的 Kubernetes Pod Security Policies (PSP) 提供了更细粒度的控制。

传统命令式配置方式

在 Flux2 项目的文档中，原本推荐使用 OpenShift 命令行工具 oc adm 来为 Flux 控制器服务账户添加 SCC 权限。这种方式虽然有效，但存在几个明显缺点：

1. 需要手动执行命令
2. 不利于版本控制和审计
3. 无法实现 GitOps 工作流
4. 在多集群环境中难以保持一致

典型的命令式配置示例如下：

for i in ${!FLUX_CONTROLLERS[@]}; do
  oc adm policy add-scc-to-user nonroot system:serviceaccount:${FLUX_NAMESPACE}:${FLUX_CONTROLLERS[$i]}
done

声明式配置方案

我们可以将上述命令式操作转换为 Kubernetes 原生资源定义，具体实现为 ClusterRole 资源。这种声明式配置有以下优势：

1. 可版本控制
2. 可审计
3. 符合 GitOps 原则
4. 易于在多集群环境中保持一致

具体实现

以下是一个完整的 ClusterRole 定义示例，用于授予 Flux 控制器服务账户使用 OpenShift 的 nonroot SCC 权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: flux-nonroot-scc
rules:
- apiGroups:
  - security.openshift.io
  resources:
  - securitycontextconstraints
  resourceNames:
  - nonroot
  verbs:
  - use

工作原理

1. apiGroups：指定了安全相关的 API 组，这里是 OpenShift 特有的 security.openshift.io
2. resources：定义了要操作的资源类型，即 securitycontextconstraints (SCC)
3. resourceNames：限定了具体的 SCC 名称，这里是 nonroot
4. verbs：定义了允许的操作，对于 SCC 只需要 use 权限

部署建议

1. 预安装配置：可以在 Flux 安装前就将此 ClusterRole 定义应用到集群中
2. 结合 RoleBinding：需要创建相应的 RoleBinding 将此 ClusterRole 绑定到 Flux 控制器使用的服务账户
3. 多租户环境：在多命名空间部署时，确保为每个 Flux 实例的服务账户创建对应的绑定

安全最佳实践

1. 最小权限原则：仅授予必要的 SCC 权限，本例中使用的是限制较多的 nonroot SCC
2. 定期审计：定期检查 ClusterRole 和绑定关系，确保没有过度授权
3. 命名规范：为 ClusterRole 使用有意义的名称，如 flux-nonroot-scc，便于识别和管理

总结

将 OpenShift SCC 配置从命令式转换为声明式，不仅提升了配置管理的便利性，也更好地融入了 GitOps 工作流。这种模式可以推广到其他需要特殊权限的 OpenShift 工作负载中，实现更安全、更可控的集群管理。