kata-cc guest emptyDir volumes are not writable by non-root containers — permanent privileged-SCC workaround in kbs-access-curl

[butler54]

Summary

Under the kata-cc RuntimeClass, emptyDir volumes mounted inside the guest VM are not created with permissions that allow a non-root container to write to them. restricted-v2 (the standard OpenShift default SCC) sets runAsNonRoot: true with a random UID, and the guest-side emptyDir ends up root:root-owned — so any workload using an emptyDir under kata-cc gets Permission denied.

Where this shows up in coco-pattern

charts/coco-supported/kbs-access-curl has to carry a dedicated ServiceAccount + ClusterRoleBinding to system:openshift:scc:privileged, plus runAsUser: 0 and privileged: true on both containers, purely to work around this — see templates/sa.yaml and templates/deployment.yaml. This is a real weakening of the security posture the rest of the pattern otherwise enforces (every other coco-pattern workload runs under restricted-v2).

By contrast, kbs-access-sealed (same pattern, but uses a Secret volume instead of an emptyDir) works fine under restricted-v2 — confirming the emptyDir/kata-cc combination is specifically what triggers this.

Evidence

Init container (registry.access.redhat.com/ubi9/ubi:latest) cannot write to the emptyDir
mounted at /var/www/html:
  sh: /var/www/html/secret.txt: Permission denied

Root cause chain:

1. Pod uses kata-cc RuntimeClass → runs inside a kata guest VM
2. Default ServiceAccount only has restricted-v2 SCC → runAsNonRoot: true, random UID (e.g. 1000830000), all capabilities dropped
3. kata-cc does not apply fsGroup to the emptyDir mount inside the guest VM
4. The emptyDir is created root:root inside the guest → the non-root UID can't write to it

Attempts that did not work (tried before landing on the privileged-SCC workaround):

• securityContext.privileged: true on the container alone — SCC admission still picks restricted-v2 since the ServiceAccount doesn't have access to privileged
• oc adm policy add-scc-to-user privileged -z default — pod spec didn't explicitly request it, so admission still selected restricted-v2
• Mounting elsewhere (e.g. /tmp/shared) — same ownership problem, since it's still backed by the guest-side emptyDir mechanism

Ask

Root cause likely lives in kata-agent / OpenShift Sandboxed Containers volume-preparation logic (whether/how fsGroup or a writable mode is applied to kata-cc guest emptyDir mounts), not in coco-pattern itself. Filing here as a known-limitation tracking issue since:

1. coco-pattern carries a permanent, real security-posture weakening as a workaround
2. Any other coco-pattern (or downstream) workload that needs a writable ephemeral volume under kata-cc will hit the same wall

Requesting:

• Confirmation on whether a non-privileged fix is possible from the pattern side (e.g. an init container permission fix that doesn't require full privileged SCC)
• If not, tracking of the upstream kata-containers / OpenShift Sandboxed Containers issue here, so the workaround can eventually be removed

References

• charts/coco-supported/kbs-access-curl/templates/sa.yaml
• charts/coco-supported/kbs-access-curl/templates/deployment.yaml
• Found during Stability Run 4 (2026-07-27), bare-metal Intel TDX, OCP 4.21.24