Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

🐞 Fix: ClickHouse Operator drops container-level securityContext

Open
  • Is something wrong?
#1,898 9 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go, kubernetes
Domain
devops, infrastructure

Research direction

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.

Written by the indexing model from the issue text.

Description

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

  1. 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.

Dominant language
Go
Stars
2.6k
Forks
579
Avg merge
5d 22h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Altinity/clickhouse-operator

All issues in Altinity/clickhouse-operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.