feat: add PSA restricted compliance — securityContext, remove SYS_PTRACE#45
Open
will-corrigan wants to merge 8 commits into
Open
feat: add PSA restricted compliance — securityContext, remove SYS_PTRACE#45will-corrigan wants to merge 8 commits into
will-corrigan wants to merge 8 commits into
Conversation
Open
1 task
… backward compat - Add containerSecurityContext to hatchet-api deployment template - Add podSecurityContext/containerSecurityContext defaults to hatchet-api values - Preserve old securityContext.enabled conditional in both deployment templates so existing users with securityContext.enabled: true are not broken - Mark old securityContext values as deprecated in favor of podSecurityContext
- Switch all templates from individual field references to toYaml pattern (matches cert-manager/Grafana convention, lets users add any field) - Remove runAsUser: 0 and runAsNonRoot: false from podSecurityContext defaults — these explicitly set root. Default now only sets seccompProfile: RuntimeDefault - Change seccompProfileType flat field to proper nested seccompProfile.type structure - Preserve old securityContext.enabled conditional in deployment templates for backward compatibility
…essNamespace flag
When quickstartJob.enabled=false, the setup job renders a fallback "empty" alpine container. This container was missing the containerSecurityContext block, causing PSA restricted violations. Apply the same toYaml pattern used by all other containers.
Users upgrading should not have shareProcessNamespace silently change from true to false. Keep the existing behavior as default, let users opt into false for PSA restricted compliance.
The previous defaults (drop ALL capabilities, seccompProfile, etc.)
would be breaking changes for users upgrading from the current chart.
Default to empty ({}) which matches existing behavior, and document
the restricted profile values in comments for users who want to opt in.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds configurable pod-level and container-level securityContext to all Hatchet deployments and jobs, enabling Kubernetes Pod Security Standards restricted profile compliance. Removes hardcoded
SYS_PTRACEcapability from setup job containers.All defaults are backward-compatible — existing deployments are unaffected. Security hardening is opt-in via values.
Type of change
What's Changed
Added
podSecurityContextandcontainerSecurityContextvalues for hatchet-api and hatchet-frontend chartsshareProcessNamespaceas a configurable value (default:truefor backward compatibility)toYamlpattern (matching cert-manager/Grafana convention) so users can pass any securityContext fieldRemoved
SYS_PTRACEcapability from all 4 setup job containers (not used by the codebase — no references in Go code or docker-compose)Backward compatibility
podSecurityContextandcontainerSecurityContextdefault to{}(empty) — no security context is applied unless the user opts inshareProcessNamespacedefaults totrue(matching existing behavior)securityContext.enabled/securityContext.runAsUser/securityContext.fsGroupvalues still workSYS_PTRACE, which was blocking pod creation on clusters with PSAbaselineenforceOpting into PSA restricted
Requires hatchet-dev/hatchet#3356 which creates a non-root user (UID 1000) in the Docker images. Once both are merged:
Testing
helm lintpasses on all 4 chartshelm templaterenders correctly with default values (backward compatible) and restricted values