Skip to content

feat(helm): make pod and container securityContext configurable via values#404

Open
arnabmaji wants to merge 1 commit into
temporalio:mainfrom
arnabmaji:feat/configurable-security-context
Open

feat(helm): make pod and container securityContext configurable via values#404
arnabmaji wants to merge 1 commit into
temporalio:mainfrom
arnabmaji:feat/configurable-security-context

Conversation

@arnabmaji

@arnabmaji arnabmaji commented Jun 25, 2026

Copy link
Copy Markdown

Summary

Add optional podSecurityContext and containerSecurityContext value overrides to manager.yaml, allowing users to fully customize security settings without vendoring the chart.

This is a non-breaking, additive change. Existing securityContext.seccompProfile.enabled behavior is preserved unchanged.

Problem

The current chart hardcodes:

  • Pod level: runAsNonRoot: true + optional seccompProfile toggle (boolean)
  • Container level: allowPrivilegeEscalation: false + capabilities.drop: ALL

This makes it impossible to satisfy common security policies (Kyverno, OPA Gatekeeper, Pod Security Standards restricted profile) that additionally require:

  • readOnlyRootFilesystem: true
  • runAsUser / runAsGroup / fsGroup
  • Container-level seccompProfile

Users are forced to either create policy exceptions or vendor the chart locally to patch the templates.

Solution

Add two new optional values that override the defaults when set:

  • podSecurityContext: {} — when non-empty, replaces the default pod securityContext block entirely
  • containerSecurityContext: {} — when non-empty, replaces the default container securityContext block for both manager and kube-rbac-proxy

When empty (the default), existing behavior is preserved exactly as-is, including the securityContext.seccompProfile.enabled toggle.

Template logic:

{{- if .Values.podSecurityContext }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
{{- else }}
      securityContext:
        runAsNonRoot: true
        {{- if .Values.securityContext.seccompProfile.enabled }}
        seccompProfile:
          type: RuntimeDefault
        {{- end }}
{{- end }}

Example usage (satisfies Kyverno/PSS restricted):

podSecurityContext:
  runAsNonRoot: true
  runAsUser: 65532
  runAsGroup: 65532
  fsGroup: 65532
  seccompProfile:
    type: RuntimeDefault

containerSecurityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  runAsGroup: 65532
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - "ALL"

Backwards Compatibility

Scenario Behavior
No changes to values Identical output to current chart
securityContext.seccompProfile.enabled: true Still works as before
podSecurityContext set Overrides legacy pod securityContext
containerSecurityContext set Overrides legacy container securityContext

Files Changed

  • helm/temporal-worker-controller/templates/manager.yaml — conditional template logic
  • helm/temporal-worker-controller/values.yaml — new optional values with documented examples

@arnabmaji arnabmaji requested review from a team and jlegrone as code owners June 25, 2026 09:03
@CLAassistant

CLAassistant commented Jun 25, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

…alues

Add podSecurityContext and containerSecurityContext value overrides to

manager.yaml. When set, they replace the default hardcoded security

context blocks. When empty (default), existing behavior is preserved:

- Pod: runAsNonRoot: true + securityContext.seccompProfile.enabled toggle

- Container: allowPrivilegeEscalation: false + capabilities.drop: ALL

This is a non-breaking, additive change. The existing

securityContext.seccompProfile.enabled value continues to work as before.

Users who need stricter policies (Kyverno, OPA, PSS restricted) can now

set the new values without vendoring the chart.
@arnabmaji arnabmaji force-pushed the feat/configurable-security-context branch from 6fb58b4 to ce4d542 Compare June 25, 2026 09:07
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.

2 participants