<p>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"</p>

<p>Here is my init-container:</p>

<pre><code>  - 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
</code></pre>

<p>I also have chmod 777 set on the nfs mount which has my persistent volume.</p>

<p>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?</p>

<p>The OpenShift documentation talks a little about this in the <a href="https://docs.okd.io/latest/creating_images/guidelines.html#openshift-specific-guidelines" rel="nofollow noreferrer">Support Arbitrary User IDs</a> section.</p>

<p>The issue is that the user your init container is running as does not have write permissions on that directory <code>/var/opt</code>.</p>

<p>If you have your initContainer run the <code>id</code> command you will see that your uid and gid should be 1000000000+:0</p>

<p>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. </p>

<p>Unfortunately many public container images do have this configuration setup out of the box.</p>

<p>You can see examples of this in the Red Hat base images. There is a script baked into each base container image called <a href="https://github.com/sclorg/s2i-base-container/blob/master/core/root/usr/bin/fix-permissions#L21" rel="nofollow noreferrer">fix-permissions</a> that gets run anywhere it is expected the application/user will need to write to later.</p>

<p>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.</p>

<pre><code>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 {} +
</code></pre>

<p>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 <a href="https://docs.okd.io/latest/install_config/master_node_configuration.html#master-node-config-project-config" rel="nofollow noreferrer">Project Config</a> section and the <a href="https://docs.okd.io/latest/install_config/master_node_configuration.html#security-allocator-configuration" rel="nofollow noreferrer">Security Allocator Configuration</a> section.</p>

<p>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 <a href="https://docs.okd.io/latest/architecture/additional_concepts/authorization.html#admission" rel="nofollow noreferrer">Understanding Pre-allocated Values and Security Context Constraints</a> section.</p>
