Repository navigation
bug(helm): certgen hook is rejected by Restricted Pod Security #3215
Description
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.116 renders Job/<release>-certgen without a pod securityContext and without runAsNonRoot or seccompProfile on 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 podSecurityContext and securityContext; 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
- A default
helm templaterender of the certgen Job satisfies the Restricted Pod Security Standard for the chart's supported Kubernetes versions. - The certgen pod and container run as non-root and declare a Restricted-compatible seccomp profile.
- The chart exposes certgen-specific pod/container security-context values if operators need to override the defaults.
- Chart tests cover the rendered certgen security context.
- Existing installs that do not enforce Pod Security continue to upgrade without manual migration.
Reproduction Steps
- Create a namespace with
pod-security.kubernetes.io/enforce: restricted(tested with policy versionv1.36). - Install OpenShell chart
0.0.116with Agent Sandbox available andpkiInitJob.enabled: true. - Observe that
Job/<release>-certgenis rejected by Pod Security admission for missingrunAsNonRootandseccompProfilefields. - Render the chart and compare the certgen Job with the configurable gateway StatefulSet security contexts.
Environment
- OpenShell Helm chart:
0.0.116, OCI digestsha256:df55cd1538bdfb7836834c30dfcf8373b85ffea83bbfd70d50dbe69407a0d2b3 - Kubernetes:
v1.36.4 - Distribution: Talos Linux
v1.13.9 - Deployment: Flux HelmRelease, Kubernetes Agent Sandbox driver
Logs
The rendered certgen container has allowPrivilegeEscalation: false and drops ALL, but neither the pod nor container declares runAsNonRoot or seccompProfile. Restricted admission reports those missing fields under the restricted policy.
Activity
lunarwhite commentedon Sep 14, 2026
Implementation Plan
Issue type:
fixComplexity: Low
Confidence: High — clear path
Summary
The certgen hook's container
securityContextomitsrunAsNonRootandseccompProfile.type, and the gateway'ssecurityContextomitsseccompProfile. Thehook fails first at
helm.sh/hook-weight: "-20", masking the second rejection, sofixing 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: trueandseccompProfile.type: RuntimeDefaultto the hook's existing containersecurityContext(lines 85-89).deploy/helm/openshell/values.yaml: addseccompProfile.type: RuntimeDefaultto thegateway
securityContext(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 thegateway 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
securityContext. No new values and nopod-level block: the hook renders exactly one container, and Restricted accepts
runAsNonRootandseccompProfile.typeat container level.seccompProfile.type: RuntimeDefaultto the gatewaysecurityContext. It reachesci/values-openshift-scc.yamlautomatically, because Helm deep-merges values files.mise run helm:test.mise run helm:docs:checkpasses.pod-security.kubernetes.io/enforce=restrictedthat thehook Job completes and the gateway pod reaches Ready.
Test Plan
certgen_test.yamlassertsrunAsNonRootandseccompProfile.typeonthe default render.
gateway_pod_security_context_test.yamlgains one case assertingthe gateway container
seccompProfile.type.render and a live cluster.
e2e/change.e2e/with-kube-gateway.shalready runs the certgenhook on every Kubernetes E2E run.
helm templateproves the fields render, not that aRestricted-enforcing namespace admits both workloads.
Risks & Open Questions
OpenShift restricted-v2 compatible (
runAsNonRootwith norunAsUser). Confirm thissatisfies 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.
ci/values-openshift-scc.yamlnullspodSecurityContext, which would discard a pod-level profile on OpenShift.label-based access control.
Documentation Impact
deploy/helm/openshell/README.md— regenerated (CI-enforced). No prose or referencepage changes: the fix removes a failure mode rather than adding an operator knob.
Revision 1 — initial plan
lunarwhite commentedon Sep 14, 2026
will raise a PR based on above plan later if no other comments
lunarwhite commentedon Sep 17, 2026
PR is ready for review: #3340