Skip to content

feat(supervisor): parameterize worker pod annotations, securityContext, SA, envFrom#14

Draft
ConProgramming wants to merge 1 commit into
mainfrom
upstream-pr/supervisor-worker-pod-params
Draft

feat(supervisor): parameterize worker pod annotations, securityContext, SA, envFrom#14
ConProgramming wants to merge 1 commit into
mainfrom
upstream-pr/supervisor-worker-pod-params

Conversation

@ConProgramming
Copy link
Copy Markdown

Summary

Parameterizes worker pod metadata, securityContext, ServiceAccount, and envFrom-Secret via five new optional env vars on the supervisor process, plus matching Helm values. Lets operators configure compliance-required pod settings (annotations, runAsNonRoot, capabilities.drop, seccompProfile, etc.) without patching the supervisor image.

Discovered while rebasing our trigger.dev fork for a FedRAMP environment — Red Hat OpenShift's restricted SCC + pod-security admission policy reject worker pods that don't carry these settings.

Changes

  • New env vars on supervisor: KUBERNETES_WORKER_POD_ANNOTATIONS, _POD_SECURITY_CONTEXT, _CONTAINER_SECURITY_CONTEXT, _SERVICE_ACCOUNT, _ENV_FROM_SECRET (all optional, JSON-encoded for structured ones)
  • envUtil.ts helper for JSON parsing + Zod validation, with tests
  • workloadManager/kubernetes.ts applies parsed values to V1Pod spec
  • Helm chart: supervisor.yaml emits the env vars when corresponding values are set; new supervisor.config.kubernetes.workerPod* keys in values.yaml

Test plan

  • Unit tests for envUtil JSON parsing (success, malformed JSON, schema mismatch)
  • Helm template renders correctly with values set + unset
  • Manually verified against a real OpenShift cluster: worker pods now schedule with the expected securityContext applied

Notes

  • Defaults preserve current behavior — no behavior change for anyone not setting the new values.
  • This is PR 1 of 5 from a fork rebase; the others (helm extras, DEPLOY_IMAGE_OVERRIDE warning, s3.useIam, entrypoint migrate subcommand) are separate.

Made with Cursor

…t, SA, envFrom

The Kubernetes workload manager now reads five new env vars from the
supervisor process and applies them to every spawned worker pod:

  - KUBERNETES_WORKER_POD_ANNOTATIONS         (JSON, Record<string,string>)
  - KUBERNETES_WORKER_POD_SECURITY_CONTEXT    (JSON, V1PodSecurityContext)
  - KUBERNETES_WORKER_CONTAINER_SECURITY_CONTEXT (JSON, V1SecurityContext)
  - KUBERNETES_WORKER_SERVICE_ACCOUNT         (string, SA name)
  - KUBERNETES_WORKER_ENV_FROM_SECRET         (string, Secret name)

All five are optional. When unset, behavior matches today.

Lets compliance-sensitive deployments (Red Hat OpenShift, FedRAMP/IL5
environments, restricted PSA namespaces) configure worker pods through
the Helm chart instead of patching the supervisor image. Also unblocks
operators who need worker pods to:

  - Carry custom annotations (e.g. service mesh sidecar opt-out, audit tags)
  - Run under specific UIDs / capabilities / seccomp profiles
  - Use a non-default ServiceAccount (e.g. for IRSA / Workload Identity)
  - Inherit a batch of env vars from a Secret via envFrom

Includes envUtil helper + tests for JSON parsing of the structured envs.

The supervisor.yaml Helm template emits these env vars from values when set;
schema added under supervisor.config.kubernetes.* in values.yaml.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant