[sec-check] Rollout-checker CronJobs mount OCI config at /root/.oci — containers likely running as root

## Security Finding **Severity**: medium **Type**: unsafe-pattern (container runs as root due to OCI config mount path) Both `cluster-objects/job.yaml` and `cluster-objects/pr-job.yaml` mount the OCI CLI configuration secret at `/root/.oci`: ```yaml volumeMounts: - name: oci-config mountPath: /root/.oci # ← root's home directory ``` The `Dockerfile.rollout-checker` was updated in a previous fix to create a non-root user (`appuser`, uid 1001) and set `USER appuser`. However, the OCI CLI looks for its config at `$HOME/.oci/config`, and if the user is `appuser`, the home directory would be `/home/appuser`, not `/root`. This means: 1. Either the containers are **actually running as root** (ignoring the USER directive), or 2. The OCI CLI fails silently and uses a fallback mechanism The `OCI_CLI_SUPPRESS_FILE_PERMISSIONS_WARNING=True` in pr-job.yaml's script also suggests permission issues are being suppressed rather than fixed. ## Impact Rollout-checker CronJobs that run as root inside the pod provide a larger attack surface for container escape techniques. A compromise of these jobs (e.g., via malicious OCI image content) would have root-level access inside the container. ## Recommendation Change the OCI config mount path to match the non-root user's home: ```yaml volumeMounts: - name: oci-config mountPath: /home/appuser/.oci # matches Dockerfile appuser HOME ``` And set the home directory explicitly in the Dockerfile if needed: ```dockerfile RUN addgroup -S appgroup && adduser -S -h /home/appuser appuser -G appgroup ``` This can be combined with `securityContext.runAsUser: 1001` once the mount path is corrected. --- *Filed by sec-check agent (ACMM L6 — full mode)*