Introduction

Yes. shareProcessNamespace is a Pod setting, so you enable it in the Pod template of the resource used as the Helm hook. In practice, that usually means a Job annotated with helm.sh/hook: post-install. The important detail is placement: the field belongs under the hook Pod spec, not at the top level of the Job.

Where shareProcessNamespace Belongs

Kubernetes enables process namespace sharing with the shareProcessNamespace field on a Pod spec. A Helm post-install hook is not a special runtime type by itself. It is just a normal Kubernetes resource with hook annotations.

For a hook implemented as a Job, the correct location is:

• 'spec.template.spec.shareProcessNamespace for the Job'
• not spec.shareProcessNamespace on the Job object itself

That matters because the Job controller creates Pods from the template. The process-sharing behavior only exists inside those Pods.

Example Helm Hook Job

The following hook runs after install and enables process namespace sharing for two containers inside the same hook Pod.

1apiVersion: batch/v1
2kind: Job
3metadata:
4  name: example-post-install
5  annotations:
6    helm.sh/hook: post-install
7    helm.sh/hook-delete-policy: hook-succeeded
8spec:
9  template:
10    spec:
11      restartPolicy: Never
12      shareProcessNamespace: true
13      containers:
14        - name: worker
15          image: busybox:1.36
16          command: ["sh", "-c", "sleep 30"]
17        - name: inspector
18          image: busybox:1.36
19          command: ["sh", "-c", "ps ax && sleep 5"]

With this configuration, the containers in that one hook Pod can inspect each other’s processes. That is the only scope of the feature. It does not let a hook container see processes from other Pods created elsewhere in the release.

When This Is Actually Useful

shareProcessNamespace only matters when the hook Pod has more than one container and they need to cooperate at the process level. Typical examples include:

• a helper container inspecting another container’s process state
• a sidecar sending signals to a worker process
• debugging a short-lived post-install workflow

If your post-install hook has only one container, setting shareProcessNamespace: true adds no real value.

Use a Job, Not a Bare Pod, for Most Hooks

Helm can hook several resource types, but a Job is usually the best fit for post-install tasks because Kubernetes tracks completion and retries more cleanly.

A bare Pod hook can also carry shareProcessNamespace, since it is a Pod field, but Jobs are easier to reason about for one-off tasks such as migrations, bootstrap scripts, and post-deploy checks.

Cluster and Security Considerations

Process namespace sharing has security implications. Containers in the same Pod can see more information about each other’s processes, including command-line arguments visible through /proc. Keep that in mind before enabling it for a hook that handles secrets or untrusted helper containers.

Also remember that this setting does not cross Pod boundaries. If your chart creates one Job and one Deployment, the hook Job cannot see Deployment container processes just because both belong to the same release.

Common Pitfalls

• Putting shareProcessNamespace under the Job spec instead of the Job’s Pod template spec.
• Expecting process sharing across different Pods in the same Helm release.
• Enabling the feature on a single-container hook and expecting different behavior.
• Using a bare Pod hook when a Job would provide clearer completion semantics.
• Forgetting that shared process visibility can expose sensitive runtime details between containers.

Summary

• Yes, you can enable shareProcessNamespace for a Helm post-install hook.
• Set it on the hook Pod spec, which for a Job means spec.template.spec.shareProcessNamespace: true.
• The feature only affects containers inside the same Pod.
• A Job hook is usually the best vehicle for post-install work.
• Use the setting only when multiple hook containers genuinely need shared process visibility.