OpenShift 4.6部署Hashicorp Vault+Consul时创建/consul目录权限被拒求助

根因说明 #

该报错本质是Consul容器的运行用户无/consul/extra-config路径的写入权限，此前配置的privileged/anyuid SCC未生效，大概率是服务账号绑定错误、或是chart默认安全配置未适配OpenShift的随机UID运行机制导致。 #

分步修复方案 #

1. 先确认SCC绑定配置正确 #

• 先查询对应命名空间下Consul、Vault实际使用的服务账号，不要直接使用模板命令的占位符
  oc get sa -n <替换为实际命名空间>
• 重新绑定正确的SCC，注意替换占位符为实际值：
  oc adm policy add-scc-to-user privileged -z <Consul对应服务账号名> -n <实际命名空间>
oc adm policy add-scc-to-user anyuid -z <Consul对应服务账号名> -n <实际命名空间>

2. 适配OpenShift安全规则（推荐，无需高权限SCC） #

优先使用该方案，避免给服务账号开放过高权限：

• 拉取helm chart到本地修改配置
  helm pull openlab-red/hashicorp-vault --untar
• 编辑values.yaml，在Consul配置段新增安全上下文和init容器配置，修复路径权限：

consul:
  securityContext:
    runAsNonRoot: true
    fsGroup: 1000
    allowPrivilegeEscalation: false
  extraInitContainers:
    - name: fix-config-perm
      image: busybox:1.36
      command: ["sh", "-c", "chmod -R 775 /consul/extra-config && chown -R 100:1000 /consul/extra-config"]
      volumeMounts:
        - mountPath: /consul/extra-config
          name: consul-extra-config

• 用修改后的本地chart重新执行安装操作即可。

3. 持久化存储场景额外排查 #

如果Consul使用了持久卷，进入debug模式确认卷权限：
oc debug pod/<报错的Consul Pod名称> -n <实际命名空间>
进入debug终端后执行：
ls -ld /consul/extra-config
若返回路径所属用户为root且无其他用户写入权限，除上述配置外，还需要给持久卷配置fsGroup策略为Always，确保卷权限被正确重写。 #

内容的提问来源于stack exchange，提问作者Shaik Nasrulla Sharif