Repository navigation
bug(helm): certgen hook is rejected by Restricted Pod Security #3215
Description
Activity
🏗️ build-plan
Implementation Plan
Issue type:
fix
Complexity: Low
Confidence: High — clear pathSummary
The certgen hook's container
securityContextomitsrunAsNonRootand
seccompProfile.type, and the gateway'ssecurityContextomitsseccompProfile. The
hook fails first athelm.sh/hook-weight: "-20", masking the second rejection, so
fixing only the hook leaves a default install still rejected by Restricted admission.
Both fields are added at container level, where Restricted accepts all four controls.Scope
deploy/helm/openshell/templates/certgen.yaml: addrunAsNonRoot: trueand
seccompProfile.type: RuntimeDefaultto the hook's existing container
securityContext(lines 85-89).deploy/helm/openshell/values.yaml: addseccompProfile.type: RuntimeDefaultto the
gatewaysecurityContext(lines 124-134).deploy/helm/openshell/tests/certgen_test.yaml: assert the two new hook fields.deploy/helm/openshell/tests/gateway_pod_security_context_test.yaml: assert the
gateway container profile. The file has no container-level assertions today.deploy/helm/openshell/README.md: regenerated bymise run helm:docs;
mise run helm:docs:checkis a required CI gate.
Implementation Steps
- Add the two fields to the hook's container
securityContext. No new values and no
pod-level block: the hook renders exactly one container, and Restricted accepts
runAsNonRootandseccompProfile.typeat container level. - Add
seccompProfile.type: RuntimeDefaultto the gatewaysecurityContext. It reaches
ci/values-openshift-scc.yamlautomatically, because Helm deep-merges values files. - Add the two test assertions. Verify with
mise run helm:test. - Regenerate the chart README and confirm
mise run helm:docs:checkpasses. - Verify on a k3d cluster with
pod-security.kubernetes.io/enforce=restrictedthat the
hook Job completes and the gateway pod reaches Ready.
Test Plan
- Unit tests:
certgen_test.yamlassertsrunAsNonRootandseccompProfile.typeon
the default render.gateway_pod_security_context_test.yamlgains one case asserting
the gateway containerseccompProfile.type. - Integration tests: N/A. Chart rendering has no integration layer between the unit
render and a live cluster. - E2E tests: No
e2e/change.e2e/with-kube-gateway.shalready runs the certgen
hook on every Kubernetes E2E run. - Manual verification: required.
helm templateproves the fields render, not that a
Restricted-enforcing namespace admits both workloads.
Risks & Open Questions
- No override values are added. No known configuration needs them, and the defaults are
OpenShift restricted-v2 compatible (runAsNonRootwith norunAsUser). Confirm this
satisfies the "exposes certgen-specific pod/container security-context values if
operators need to override the defaults" criterion. RuntimeDefaultnewly applies the container runtime's syscall filter to the gateway,
the only part of this change that alters a long-running workload on upgrade. This is
why manual cluster verification is warranted rather than optional.- Gateway seccomp is set at container level because
ci/values-openshift-scc.yamlnulls
podSecurityContext, which would discard a pod-level profile on OpenShift. - No LSM impact: seccomp is syscall filtering, orthogonal to SELinux and AppArmor
label-based access control.
Documentation Impact
deploy/helm/openshell/README.md— regenerated (CI-enforced). No prose or reference
page changes: the fix removes a failure mode rather than adding an operator knob.
Revision 1 — initial plan
will raise a PR based on above plan later if no other comments
PR is ready for review: #3340
User Story
As a Kubernetes platform operator enforcing the Restricted Pod Security Standard on controller namespaces, I want the OpenShell Helm chart's certificate-generation hook to pass admission, so that I can install the gateway without weakening the namespace security policy.
Problem Statement
OpenShell Helm chart
0.0.116rendersJob/<release>-certgenwithout a podsecurityContextand withoutrunAsNonRootorseccompProfileon its container. The container already drops all capabilities and disables privilege escalation, but Kubernetes Restricted Pod Security admission still rejects the hook for the missing non-root and seccomp settings.The main gateway workload can already be configured with
podSecurityContextandsecurityContext; the certgen hook does not inherit those settings and exposes no equivalent values.Impact / Why This Matters
The pre-install/pre-upgrade hook blocks the entire Helm release in a namespace labeled
pod-security.kubernetes.io/enforce: restricted. Operators must either weaken admission for the trusted gateway namespace or carry a Flux/Helm post-render patch for a security-sensitive hook. The post-render workaround is coupled to the hook resource name and container position and can silently stop matching after a chart refactor unless it is separately tested.Acceptance Criteria
helm templaterender of the certgen Job satisfies the Restricted Pod Security Standard for the chart's supported Kubernetes versions.Reproduction Steps
pod-security.kubernetes.io/enforce: restricted(tested with policy versionv1.36).0.0.116with Agent Sandbox available andpkiInitJob.enabled: true.Job/<release>-certgenis rejected by Pod Security admission for missingrunAsNonRootandseccompProfilefields.Environment
0.0.116, OCI digestsha256:df55cd1538bdfb7836834c30dfcf8373b85ffea83bbfd70d50dbe69407a0d2b3v1.36.4v1.13.9Logs
The rendered certgen container has
allowPrivilegeEscalation: falseand dropsALL, but neither the pod nor container declaresrunAsNonRootorseccompProfile. Restricted admission reports those missing fields under therestrictedpolicy.