Bug: Bootstrap Job ignores spec.security.podSecurityContext on OpenShift (restricted-v2 SCC)

[meliops]

Summary

The bootstrap Job generated by the Paperclip Operator correctly inherits spec.security.containerSecurityContext, but it does not inherit spec.security.podSecurityContext.

Instead, the generated Job hard-codes:

spec:
  template:
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
        runAsNonRoot: true

This prevents the bootstrap Job from running on OpenShift clusters using the default restricted-v2 SCC.

---

Environment

• Paperclip Operator: v0.19.0
• Installed via OLM
• Platform: OpenShift
• SCC: restricted-v2

---

Instance configuration

The Instance specifies the following security configuration:

spec:
  security:
    podSecurityContext:
      runAsNonRoot: true
      runAsUser: 1000950000
      runAsGroup: 1000950000
      fsGroup: 1000950000
      fsGroupChangePolicy: OnRootMismatch

    containerSecurityContext:
      runAsNonRoot: true
      runAsUser: 1000950000
      runAsGroup: 1000950000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

The operator stores these values correctly.

Verification:

oc get instance paperclip-stg \
  -o jsonpath='PodSC={.spec.security.podSecurityContext}{"\n"}ContainerSC={.spec.security.containerSecurityContext}{"\n"}'

Output:

PodSC={"fsGroup":1000950000,"fsGroupChangePolicy":"OnRootMismatch","runAsGroup":1000950000,"runAsNonRoot":true,"runAsUser":1000950000}
ContainerSC={"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true,"runAsGroup":1000950000,"runAsNonRoot":true,"runAsUser":1000950000}

---

Generated bootstrap Job

The generated Job contains:

oc get job paperclip-stg-bootstrap \
  -o jsonpath='PodSC={.spec.template.spec.securityContext}{"\n"}ContainerSC={.spec.template.spec.containers[0].securityContext}{"\n"}'

Output:

PodSC={"fsGroup":1000,"runAsGroup":1000,"runAsNonRoot":true,"runAsUser":1000}

ContainerSC={"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true,"runAsGroup":1000950000,"runAsNonRoot":true,"runAsUser":1000950000}

The container security context is inherited correctly.

The pod security context is not.

---

Result

The bootstrap Job fails admission with:

.spec.securityContext.fsGroup: Invalid value: 1000

because the namespace uses dynamically allocated OpenShift UID/GID ranges.

As a result:

• the bootstrap Job never creates a pod
• the StatefulSet never starts
• the PVC remains WaitForFirstConsumer
• the Instance remains in Provisioning

---

Expected behavior

The bootstrap Job should inherit:

spec.security.podSecurityContext

exactly as it already inherits:

spec.security.containerSecurityContext

The generated Job should contain:

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000950000
        runAsGroup: 1000950000
        fsGroup: 1000950000
        fsGroupChangePolicy: OnRootMismatch

instead of the hard-coded UID/GID 1000.

---

Additional note

I noticed that PR #98 introduced spec.security.seLinuxRelabel, which resolves the privileged selinux-relabel init container issue.

This issue is separate and concerns only the bootstrap Job's pod security context not being propagated into the generated Job.