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"
Here is my init-container:
- 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/optI also have chmod 777 set on the nfs mount which has my persistent volume.
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.
The issue is that the user your init container is running as does not have write permissions on that directory /var/opt.
If you have your initContainer run the id command you will see that your uid and gid should be 1000000000+: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.
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.
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.
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.