Repository navigation
opensearch: the privileged init-sysctl container is refused by the tenant PodSecurity level, so no Pod is ever created #4131
Description
Describe the bug
packages/apps/opensearch/templates/opensearch.yaml:22 sets spec.general.setVMMaxMapCount: true. The vendored operator (v2.8.0, pkg/builders/cluster.go:563-579 and :1012-1027) then adds an init-sysctl container with privileged: true to every node pool StatefulSet and to the bootstrap Pod. Tenant namespaces run under the cluster default PodSecurity level, baseline, which refuses privileged containers, so the StatefulSet never creates a Pod:
create Pod opensearch-test-nodes-0 in StatefulSet opensearch-test-nodes failed error: pods "opensearch-test-nodes-0" is forbidden: violates PodSecurity "baseline:latest": privileged (container "init-sysctl" must not set securityContext.privileged=true)
Nothing else sets vm.max_map_count on the nodes. The sysctl DaemonSet that #1953 first shipped was removed during that PR's review (bb660b5, "Remove sysctl DaemonSet in favor of operator's built-in setVMMaxMapCount init container"), the Talos profiles under packages/core/talos carry no sysctls, and Talos leaves the kernel default of 65530, below the 262144 OpenSearch requires. Turning the flag off alone moves the failure to OpenSearch's own bootstrap check. docs/changelogs/v1.2.0.md:17 and :39 still describe the DaemonSet.
Environment
- Cozystack main, 2026-09-07; e2e cluster, run 34071594228 (first e2e suite for opensearch, added by feat(opensearch)!: issue HTTP and Dashboards certificates from cert-manager #2682)
To Reproduce
- Create an
OpenSearchapplication in a tenant namespace on a cluster with the default PodSecurity level kubectl describe statefulset <release>-nodesshows theFailedCreateevent above
Expected behaviour
The application starts in a tenant namespace without a privileged container.
Actual behaviour
No OpenSearch Pod is ever created.
Additional context
Three ways out, each with a cost: a sysctl DaemonSet in the operator's system namespace, which runs privileged where that is already allowed but reverses the #1953 review decision; the sysctl in the node contract (Talos profiles, talm, ansible-cozystack), which is the clean long-term answer but does nothing for clusters prepared by hand; or node.store.allow_mmap: false through spec.general.additionalConfig, self-contained but at the cost of falling back from mmapfs to niofs. vm.max_map_count is not in kubelet's namespaced sysctl set, so a Pod-level securityContext.sysctls cannot set it.
Checklist
- I have checked the documentation
- I have searched for similar issues
- I have included all required information
- I have provided clear steps to reproduce
- I have included relevant logs
Activity
feat(opensearch)!: issue HTTP and Dashboards certificates from cert-m…
lexfrei commentedon Sep 11, 2026
Closed on main. The sysctl now comes from a DaemonSet in the operator's own namespace, which the platform labels privileged, and the chart stopped asking the operator for its init container:
setVMMaxMapCountisfalseas of cecb4b1.Carrying the value in the node contract instead, which is what would let that DaemonSet go, stays open as #4144.