configMap volumes are not allowed to be used

Question

I am using OKD4, and I am trying to mount /etc/php.ini in my pods using a ConfigMap. In order to do so, I am creating the following K8S objects in my project.

Configmap (previously created to Deployment):

  - apiVersion: v1
    kind: ConfigMap
    data:
      php.ini: |-
        [PHP]

        ;;;;;;;;;;;;;;;;;;;
        ; About php.ini   ;
        ;;;;;;;;;;;;;;;;;;;

    metadata:
      name: php-ini

Deployment object:

  - kind: Deployment
    apiVersion: apps/v1
    metadata:
      name: privatebin
      labels:
        app: privatebin
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: privatebin
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: privatebin
            deploymentconfig: privatebin
        spec:
          containers:
            - name: privatebin
              image: <my container registry>/privatebin:${IMAGE_TAG}
              volumeMounts:
              - name: config-volume
                mountPath: php.ini
              livenessProbe:
                exec:
                  command:
                  - /bin/sh
                  - -c
                  - "[ -f /run/nginx.pid ] && ps -C nginx >/dev/null 2>&1 && ps -C php-fpm >/dev/null 2>&1"
                initialDelaySeconds: 10
                periodSeconds: 5
              readinessProbe: 
                httpGet: 
                  scheme: HTTP
                  path: /
                  port: 8080
                  initialDelaySeconds: 10
                  periodSeconds: 5
              ports:
                - containerPort: 8080
                  protocol: TCP
              resources: 
                limits:
                  cpu: "250m" # parameterize in tekton pipeline 
                  memory: "368Mi" # parameterize in tekton pipeline, maybe using template
                requests:
                  cpu: "100m" # parameterize in tekton pipeline, maybe using template
                  memory: "256Mi" # parameterize in tekton pipeline, maybe using template
              securityContext:
                runAsUser: 1000
                fsGroup: 1000
                fsGroupChangePolicy: "OnRootMismatch"
              imagePullPolicy: Always
          restartPolicy: Always
          terminationGracePeriodSeconds: 30
          volumes:
            - name: config-volume
              configMap:
                name: php-ini
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxUnavailable: 25%
          maxSurge: 25%

For some reason my pods are missing and there are the following errors:

• lastTransitionTime: "2021-10-08T12:53:01Z" lastUpdateTime: "2021-10-08T12:53:01Z" message: 'pods "privatebin-55678c66c5-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.runAsUser: Invalid value: 1000: must be in the ranges: [1002460000, 1002469999] spec.volumes[0]: Invalid value: "configMap": configMap volumes are not allowed to be used]'

ReplicaSet times out also with similar error: status: conditions:

• lastTransitionTime: "2021-10-08T12:53:01Z" message: 'pods "privatebin-55678c66c5-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.runAsUser: Invalid value: 1000: must be in the ranges: [1002460000, 1002469999] spec.volumes[0]: Invalid value: "configMap": configMap volumes are not allowed to be used]'

Why can't I mount the ConfigMap? Is it because of the Securitycontext in the Deployment?

Thanks in advance,

Answer 1

(The error has nothing to do with configmaps, but when you get the error resolved you may need to tweak your configmap slightly to accurately drop the file into the directory you want it to land.)

OKD is OpenShift, so it's using SCC (not PSP).

By default you have access to the "restricted" SCC in your namespace. The UIDs being thrown out in the error are from the namespace annotation (oc get namespace FOO -o yaml) will show them.

To fix:

• you can change your runAsUser to match the namespace annotation; or (better) just use "runAsNonRoot: true" which forces it to not run as root and takes the first uid in that annotation range. You may need to update the container image to leverage GROUP membership, not uid, for file access permissions.
• you can allow your accounts to use the "nonroot" SCC to run as any uid, meeting your expectation to run as uid=1000. I would suggest you look at the first option as being the preferable option.

Answer 2

Your cluster is installed with a pod security policy that reject your spec. You can get the psp with kubectl get psp , then check the settings with kubectl describe psp <name> . Look at the settings volumes and runAsUser .