🐞 Fix: ClickHouse Operator drops container-level securityContext

Problem

The ClickHouse Operator currently drops container-level securityContext fields defined in:
spec.templates.podTemplates[].spec.containers[].securityContext

While pod-level securityContext is applied correctly, Kubernetes does NOT inherit several critical security fields from the pod to the container.

According to Kubernetes documentation, the following fields must be set per container and are not inherited from the pod:

• allowPrivilegeEscalation
• capabilities
• privileged
• seccompProfile

Reference:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Because the operator drops container-level settings, users cannot run ClickHouse under Pod Security Admission (restricted) or equivalent security policies.

This is a functional bug, not a feature request.

---

Impact

This behavior causes:

• Admission failures in PSA restricted clusters
• Inability to enforce:
  • allowPrivilegeEscalation: false
  • capabilities.drop: ["ALL"]
  • seccompProfile: RuntimeDefault
• Security / compliance violations in:
  • GKE, EKS, AKS
  • Gatekeeper / Kyverno enforced clusters
• Helm charts (e.g. SigNoz) unable to harden ClickHouse containers

---

Expected Behavior

Container-level securityContext defined in ClickHouseInstallation should be preserved and propagated to the generated Pod.

Example ClickHouseInstallation

spec:
  templates:
    podTemplates:
      - name: pod-template
        spec:
          containers:
            - name: clickhouse
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop: ["ALL"]
                seccompProfile:
                  type: RuntimeDefault

Expected Pod Output

  containers:
    - name: clickhouse
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        seccompProfile:
          type: RuntimeDefault

Actual Behavior

Helm renders the ClickHouseInstallation correctly
ClickHouse Operator omits containers[].securityContext

The resulting Pod contains:
securityContext: null

Reproduction Steps

Tested locally using Minikube with SigNoz and ClickHouse Operator.

1. Verify Pod Does Not Contain Container-Level securityContext
   kubectl get pod chi-signoz-clickhouse-cluster-0-0-0 -n signoz -o yaml \ | yq '.spec.containers[].securityContext'

Output:
null

2. Verify Helm Values Are Correct

helm get values signoz -n signoz

• Container-level securityContext is present in Helm values
• ClickHouseInstallation resource is rendered correctly
• The field is dropped only after operator reconciliation

Scope of Change

Read container-level securityContext from:
podTemplates[].spec.containers[]

Propagate it verbatim into the generated Pod spec
No behavior change for users not defining container-level securityContext
Fully backward compatible

Why Pod-Level securityContext Is Not Sufficient

Pod-level securityContext cannot replace container-level security fields required by Kubernetes security enforcement.
Kubernetes explicitly requires container-level configuration for:

allowPrivilegeEscalation
capabilities
privileged
seccompProfile

Without this fix, ClickHouse cannot comply with modern Kubernetes security standards.

Start by tracing reconciliation from spec.templates.podTemplates[].spec.containers[] to the generated Pod spec, focusing on where container fields are copied or omitted. Reproduce the issue with the ClickHouseInstallation example and inspect the generated Pod using kubectl and yq. Done means the defined container-level securityContext is preserved, while Pods without it remain unchanged.