使用init-container更改PV的权限时，权限被拒绝 [英] Permission denied when changing permissions on PV with init-container
问题描述
我正在尝试在OpenShift上运行部署配置.我的部署配置的一部分运行一个初始化容器，该容器使用chown在持久卷上设置权限.当初始化容器启动时，它失败并且日志打印出权限被拒绝"
I am trying to run an deployment config on OpenShift. Part of my deployment config runs an init container which sets up permissions on persistent volume with chown. When the init-container fires up, it fails and the logs print out "permission denied"
这是我的初始化容器:
- apiVersion: v1
kind: DeploymentConfig
metadata:
name: ${NAME}-primary
namespace: ${NAMESPACE}
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
labels:
name: ${NAME}-primary
test-app: ${NAME}
spec:
serviceAccountName: ${SERVICE_ACCOUNT}
initContainers:
- name: set-volume-ownership
image: alpine:3.6
command: ["sh", "-c", "chown -R 1030:1030 /var/opt"]
volumeMounts:
- name: test-app-data
mountPath: /var/opt
我还在具有永久卷的nfs挂载上设置了chmod 777.
I also have chmod 777 set on the nfs mount which has my persistent volume.
因此，我知道OpenShift默认情况下将pod作为随机UID运行.我知道我可以从我的部署配置中将服务帐户添加到scc anyuid，这将起作用，但是我不想这样做，因为这是安全问题，并且我的群集管理员不允许这样做.我该如何解决?我一直在阅读有关fsGroups的信息，但是它们对我来说没有任何意义.有什么意见吗?
So, I know OpenShift runs the pod as a random UID by default. I know I can add the service account from my deployment config to scc anyuid and this will work but I dont want to do that as that is a security concern and my cluster admin will not allow that. How can I get around this? I have been reading about fsGroups but they havent made sense to me. Any opinions?
推荐答案
The OpenShift documentation talks a little about this in the Support Arbitrary User IDs section.
问题是您的初始化容器所运行的用户对该目录/var/opt没有写权限.
The issue is that the user your init container is running as does not have write permissions on that directory /var/opt.
如果让initContainer运行id命令，您将看到uid和gid应该为1000000000+:0
If you have your initContainer run the id command you will see that your uid and gid should be 1000000000+:0
在这种情况下，典型的策略是在运行时需要向任何地方写入的根组授予写入权限.这将允许您的运行时用户访问文件，因为尽管uid是随机生成的，但该组始终为0.
The typical strategy expected in this situation is to grant write permissions to the root group anywhere you will need to write during runtime. This will allow your runtime user to access the files because despite the fact the uid is randomly generated, the group is always 0.
不幸的是，许多公共容器映像确实具有开箱即用的配置设置.
Unfortunately many public container images do have this configuration setup out of the box.
您可以在Red Hat基本图像中看到此示例.每个基本容器映像中都有一个名为修复权限可以在预期应用程序/用户以后需要写入的任何位置运行.
You can see examples of this in the Red Hat base images. There is a script baked into each base container image called fix-permissions that gets run anywhere it is expected the application/user will need to write to later.
在上述情况下，以下代码用于调整权限，以便以后ID为1000000000+:0的任意用户都可以向其写入.
In the above case the following code is used to tweak the permissions so that later arbitrary users with id's 1000000000+:0 can write to them.
find $SYMLINK_OPT "$1" ${CHECK_OWNER} \! -gid 0 -exec chgrp 0 {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} \! -perm -g+rw -exec chmod g+rw {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} -perm /u+x -a \! -perm /g+x -exec chmod g+x {} +
find $SYMLINK_OPT "$1" ${CHECK_OWNER} -type d \! -perm /g+x -exec chmod g+x {} +
If you want to tweak these values at the cluster level the configuration for UIDAllocatorRange is set in the master-config.yml on the master hosts in the Project Config section and the Security Allocator Configuration section.
您还可以通过openshift.io/sa.scc.uid-range批注修改生成的uid的行为.可以在了解预分配的值和安全性上下文中找到有关此问题的文档.约束部分.
You can also modify the behavior of the generated uids via the openshift.io/sa.scc.uid-range annotation. Documentation discussing this can be found in the Understanding Pre-allocated Values and Security Context Constraints section.
这篇关于使用init-container更改PV的权限时，权限被拒绝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
