OpenShift安装artifactory-oss Helm chart遇SCC权限校验失败问题

问题背景 #

• 部署使用的Helm chart包：https://charts.jfrog.io/artifactory-oss-107.39.4.tgz
• 操作身份：cluster-admin集群管理员账号
• 首次部署时报错信息如下：

pods "artifactory-artifactory-nginx-5c66b8c948-" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted: .spec.securityContext.fsGroup: Invalid value: []int64{107}: 107 is not an allowed group, spec.initContainers[0].securityContext.runAsUser: Invalid value: 104: must be in the ranges: [1000970000, 1000979999], spec.containers[0].securityContext.runAsUser: Invalid

• 初步判定为OpenShift安全上下文约束（SCC）类问题，尝试通过--set参数将artifactory、nginx组件的运行用户ID、用户组ID指定为命名空间允许范围，同时传入必填的masterKey、joinKey、PostgreSQL密码参数，执行命令如下：

helm upgrade --install artifactory --set artifactory.uid=1001010042,artifactory.gid=1001010042,nginx.uid=1001010042,nginx.gid=1001010042,artifactory.masterKey=${MASTER_KEY},artifactory.joinKey=${JOIN_KEY},artifactory.postgresql.postgresqlPassword=$POSTGRES_PASSWORD --namespace artifactory jfrog/artifactory-oss

• 上述操作执行后仍触发相同报错，排查确认传入的uid/gid参数未生效，chart默认配置的fsGroup、runAsUser值仍不在命名空间允许的ID范围内，部署失败。

问题根因 #

• 参数覆盖范围不全：107.39.4版本的artifactory-oss Helm chart中，除artifactory、nginx主容器外，init容器、内置PostgreSQL子chart、附属sidecar均有独立的安全上下文配置项，零散通过--set传参无法覆盖全部默认值，因此仍会加载默认的104、107这类不符合OpenShift命名空间ID范围的配置。
• 权限认知偏差：cluster-admin是集群层面的操作权限，OpenShift的SCC校验针对Pod运行时绑定的ServiceAccount身份生效，和执行安装命令的用户身份无直接关联。未给对应ServiceAccount绑定合规SCC时，哪怕使用集群管理员账号执行安装，Pod调度时仍会被SCC规则拦截。

修复步骤 #

1. 查询目标命名空间允许的UID/GID范围
   执行以下命令获取artifactory命名空间的合法ID段，返回结果中/10000代表段长度，取段首ID作为统一运行ID即可：

# 查询允许的UID范围
oc describe namespace artifactory | grep openshift.io/sa.scc.uid-range
# 查询允许的用户组范围
oc describe namespace artifactory | grep openshift.io/sa.scc.supplemental-groups

例如返回范围为1000930000/10000，则统一使用1000930000作为runAsUser、runAsGroup、fsGroup的配置值。

2. 编写自定义values配置文件全量覆盖安全上下文
   新建custom-values.yaml文件，将以下内容中的ID替换为上一步查询到的合法ID，同时替换密钥类配置为实际值：

global:
  securityContext:
    runAsUser: 1000930000
    runAsGroup: 1000930000
    fsGroup: 1000930000
  uid: 1000930000
  gid: 1000930000

artifactory:
  uid: 1000930000
  gid: 1000930000
  masterKey: 替换为实际生成的masterKey
  joinKey: 替换为实际生成的joinKey
  containerSecurityContext:
    runAsUser: 1000930000
    runAsGroup: 1000930000
  initContainerSecurityContext:
    runAsUser: 1000930000
    runAsGroup: 1000930000
  persistence:
    securityContext:
      runAsUser: 1000930000
      runAsGroup: 1000930000
      fsGroup: 1000930000
  postgresql:
    postgresqlPassword: 替换为实际设置的PostgreSQL密码
    securityContext:
      enabled: true
      runAsUser: 1000930000
      runAsGroup: 1000930000
      fsGroup: 1000930000
    containerSecurityContext:
      runAsUser: 1000930000
      runAsGroup: 1000930000
    volumePermissions:
      securityContext:
        runAsUser: 1000930000
        runAsGroup: 1000930000

nginx:
  uid: 1000930000
  gid: 1000930000
  containerSecurityContext:
    runAsUser: 1000930000
    runAsGroup: 1000930000
  initContainerSecurityContext:
    runAsUser: 1000930000
    runAsGroup: 1000930000

3. 为对应ServiceAccount绑定合规SCC
   artifactory部署时会创建3个独立的ServiceAccount，给其绑定anyuid SCC即可满足运行要求，执行以下命令：

oc adm policy add-scc-to-user anyuid system:serviceaccount:artifactory:artifactory-artifactory
oc adm policy add-scc-to-user anyuid system:serviceaccount:artifactory:artifactory-nginx
oc adm policy add-scc-to-user anyuid system:serviceaccount:artifactory:artifactory-postgresql

4. 重新执行部署
   使用自定义values文件重新安装对应版本的chart：

helm upgrade --install artifactory --namespace artifactory -f custom-values.yaml jfrog/artifactory-oss --version 107.39.4

5. 部署校验
   执行oc get pods -n artifactory查看Pod状态，所有工作负载状态为Running即为部署成功。

注意事项 #

• 生产环境不建议直接绑定privileged SCC，权限开放范围过大，存在安全风险
• 如果部署后仍有文件权限类报错，可执行oc rsh进入对应Pod，将挂载目录的属主修改为配置的运行ID即可

内容的提问来源于stack exchange，提问作者Rob