在OpenShift上部署WSO2 Kubernetes-APIM的正确安全上下文是什么?
我之前处理过不少OpenShift部署WSO2组件的权限问题,结合你提到的场景——用pattern-2部署APIM 2.1.0,默认Pod无法访问挂载卷,临时用特权模式解决——问题根源其实和OpenShift的安全上下文约束(SCC)以及WSO2镜像的固定UID有关,下面给你一步步梳理正确的配置方案:
问题到底出在哪?
OpenShift默认用restricted SCC来管控Pod的权限,这个SCC会限制Pod使用的UID范围,还会给Pod分配随机UID。但WSO2 APIM 2.1.0的镜像里硬编码了用UID 1000000000 运行应用,这个UID不在OpenShift默认允许的范围内,再加上PVC卷的文件权限没匹配这个UID,自然就没法访问卷了。
正确配置步骤
1. 创建专属的Security Context Constraint(SCC)
别用太宽泛的anyuid SCC,咱们创建一个刚好适配WSO2 UID的自定义SCC,这样更安全:
把下面的内容存成wso2-apim-scc.yaml:
apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: wso2-apim-scc allowPrivilegeEscalation: false allowedCapabilities: [] fsGroup: type: MustRunAs ranges: - min: 1000000000 max: 1000000000 runAsUser: type: MustRunAs uid: 1000000000 seLinuxContext: type: MustRunAs supplementalGroups: type: MustRunAs ranges: - min: 1000000000 max: 1000000000 volumes: - configMap - emptyDir - persistentVolumeClaim - secret - downwardAPI
然后执行创建命令:
oc apply -f wso2-apim-scc.yaml
2. 给服务账号绑定这个SCC
找到你部署WSO2用的服务账号(默认是default,如果有自定义的就替换),把它和刚创建的SCC绑定:
oc adm policy add-scc-to-user wso2-apim-scc -z default -n <你的命名空间>
记得把<你的命名空间>换成实际的OpenShift项目名称。
3. 给Pod配置安全上下文
在WSO2 APIM的Deployment或者StatefulSet配置里,加上安全上下文的设置,明确指定运行用户和FSGroup:
spec: template: spec: securityContext: runAsUser: 1000000000 fsGroup: 1000000000 containers: - name: wso2apim # 这里保留你原来的容器配置,比如镜像、端口这些 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: false # WSO2部分组件需要可写根目录,别改成true
4. 调整PVC的文件权限(如果已经创建过PVC)
如果你的PVC已经存在,得确保卷里的文件权限允许UID 1000000000 读写。可以临时启动一个特权Pod来修改:
oc run -it --rm --image=busybox:1.34.1 --restart=Never chmod-pod --overrides='{"spec":{"securityContext":{"runAsUser":0}}}' -- /bin/sh -c "chown -R 1000000000:1000000000 /mnt && exit" -v <你的PVC名称>:/mnt
替换<你的PVC名称>为实际的PVC名字。
验证是否生效
重新部署WSO2 APIM之后,先看Pod状态:
oc get pods
然后进入Pod里检查卷的访问情况:
oc exec -it <Pod名称> -- /bin/bash # 比如试试访问挂载的配置卷:ls /home/wso2carbon/wso2-config-volume
要是Pod能正常启动,而且卷里的文件能正常读写,就说明配置没问题了,再也不用开特权模式啦。
内容的提问来源于stack exchange,提问作者gusto2

