OpenShift: Connect crashes under restricted SCC because /home/opuser/.op is not writable

[russell-parks]

---

name: Bug report
aabout: Report bugs and errors found while using any of the Helm charts.
title: ''
labels: bug
assignees: ''

---

Your environment

Chart Version: 2.4.1

Helm Version: 3.14+ (Helm 3.x)

Kubernetes Version: OpenShift Container Platform 4.x with default restricted / restricted-v2 SCC

Platform: OpenShift GitOps / Argo CD

What happened?

I deployed the connect chart on OpenShift under the normal restricted SCC model.

The pods get past SCC admission, but connect-api and connect-sync crash at runtime because the container cannot safely access /home/opuser/.op when that directory is not owned by the current user.

This is not the same as the earlier SCC admission problem reported in #95. That issue was closed with an SCC-related workaround, but that does not actually make the chart runtime-safe on OpenShift.

Current runtime error from the container logs:

failed to ConfigDir: Can't continue. We can't safely access "/home/opuser/.op" because it's not owned by the current user. Change the owner or logged in user and try again.

Both containers in the pod fail the same way:

• connect-api
• connect-sync

What did you expect to happen?

I expected the chart to run on OpenShift without requiring anyuid, privileged, or a custom SCC just to make the config directory writable.

In other words, the chart should work with OpenShift’s arbitrary-UID model and the default restricted SCC behavior.

Steps to reproduce

1. Deploy the connect chart into an OpenShift project using the default restricted SCC model.
2. Enable Connect and the operator as usual.
3. Provide Connect credentials and operator token.
4. Let OpenShift assign the pod an arbitrary UID from the namespace range.
5. Observe that the pod starts, then connect-api and connect-sync crash at runtime with the config-dir ownership error above.

Evidence

1) Previous OpenShift issue was SCC admission, not runtime ownership

I originally reported a related problem in #95.

That issue showed the earlier failure mode:

• the chart rendered runAsUser: 999
• OpenShift rejected the pod because 999 was outside the namespace UID range
• the error was an SCC admission failure

That is a different problem from the one below.

2) Current failure happens after SCC admission succeeds

In my current cluster, the pod is admitted and starts, but the containers crash because the config directory is not owned by the runtime UID.

The important distinction is:

• SCC no longer blocks the pod
• the container itself still cannot initialize /home/opuser/.op

3) Current chart layout hardcodes a mount structure that is not OpenShift-safe

The chart mounts:

• the shared data volume under /home/opuser/.op/data
• the credentials secret under /home/opuser/.op/1password-credentials.json

That means the parent directory /home/opuser/.op is still expected to exist and be writable/owned correctly at runtime.

On OpenShift, the container typically runs with an arbitrary UID, so the safer pattern is:

• mount writable storage higher up, such as /home/opuser
• let the process create and own .op itself
• keep the credentials mount outside .op

4) Relevant log message

Exact log line from the failing containers:

failed to ConfigDir: Can't continue. We can't safely access "/home/opuser/.op" because it's not owned by the current user. Change the owner or logged in user and try again.

Why I think this is a chart/image compatibility issue

OpenShift’s standard container model is arbitrary UID + restricted SCC. A chart or image that assumes a fixed user-owned home/config directory will break even when SCC admission is correct.

This looks like a chart/image layout issue, not something that should require elevated SCC permissions.

Proposed fix

Please consider making the mount layout configurable or changing the defaults so Connect is arbitrary-UID-safe on OpenShift.

Concrete options:

• add configurable mount paths for the shared data volume and credentials secret
• default to a layout that lets the runtime create and own .op
• avoid requiring runAsUser: 999 or any SCC escalation
• ensure the chart works under restricted SCC without anyuid/privileged

Workaround I used locally

I was able to work around the issue by vendoring the chart and changing the mount layout so the shared storage is mounted at /home/opuser and the credentials file is mounted outside .op, allowing the process to create .op itself.

That workaround works, but it is a downstream fix and not ideal as the upstream default.

Notes & Logs

Sanitized OpenShift error history from the earlier report in #95:

• the pod was rejected because runAsUser: 999 was not allowed in the namespace UID range

Current runtime failure:

• connect-api and connect-sync both crash
• both report that /home/opuser/.op is not owned by the current user

If helpful, I can provide:

• the exact oc describe pod output
• the exact oc logs output
• the rendered Helm manifest showing the current mount paths

References & Prior Work

• Previous OpenShift issue: #95
• OpenShift image guidance for arbitrary UID containers: https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/images/creating-images
• OpenShift SCC guidance: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authentication_and_authorization/managing-pod-security-constraints