Skip to content

opensearch: the privileged init-sysctl container is refused by the tenant PodSecurity level, so no Pod is ever created #4131

Closed

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

To Reproduce

  1. Create an OpenSearch application in a tenant namespace on a cluster with the default PodSecurity level
  2. kubectl describe statefulset <release>-nodes shows the FailedCreate event 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

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)
    on Sep 7, 2026
  2. lexfrei commented on Sep 11, 2026

    @lexfrei
    ContributorAuthor

    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: setVMMaxMapCount is false as of cecb4b1.

    Carrying the value in the node contract instead, which is what would let that DaemonSet go, stays open as #4144.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)kind/bugCategorizes issue or PR as related to a bugtriage/needs-triageIndicates an issue needs triage by a maintainer

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions