The int cluster did not enforce Pod Security when this was written - no namespace labels, no Kyverno or Gatekeeper. The sandbox was NOT checked; there is no kubeconfig context for it. A cluster that does enforce it rejects the pod outright rather than degrading, which is slow to diagnose from an unrelated namespace.
Records the matching gap it cannot fix: PipesK8sClient builds the payload pod specs, and this service passes no securityContext through base_pod_spec, so a restricted namespace would admit the dispatcher and reject every payload it creates.
Changelog: changed
Runs loosely_coupled_k8s_job from one throwaway pod with only the RBAC the pipes client needs, clearing readiness checks L4-L9 without deploying a code location, a webserver or a database. Because the pod is its own control plane it also sidesteps the 1.13.19 vs 1.12.8 skew that blocks registering this service against the sandbox Dagster.
Verified in the container beforehand: the CLI form reaches RUN_SUCCESS, the multiprocess executor fans out to four dynamic steps, and PipesK8sClient selects in-cluster credentials from KUBERNETES_SERVICE_HOST, so no code change is needed to run it in a pod.
Changelog: added
