janhoy opened a new issue, #873: URL: https://github.com/apache/solr-operator/issues/873
## Summary The operator-generated pods do not satisfy the Kubernetes [Pod Security Standards "restricted" profile](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) out of the box, so users running PSA enforcement, Kyverno policies, or OpenShift have to hand-write security hardening into every SolrCloud spec. Solr itself runs fine under these restrictions, so the operator should emit them by default rather than leaving each user to rediscover the same set of snippets. ## What the operator sets today At pod level, `GenerateStatefulSet` sets only `fsGroup: 8983` (`controllers/util/solr_util.go:564`). At container level the Solr container gets no `securityContext` unless the user supplies `customSolrKubeOptions.podOptions.containerSecurityContext`. Of the operator-generated init containers, only `setup-zk` sets anything (`readOnlyRootFilesystem: true`, `solr_util.go:1332`); `cp-solr-xml` sets nothing. ## What "restricted" requires Per container: `allowPrivilegeEscalation: false`, `capabilities.drop: ["ALL"]`, `runAsNonRoot: true`. Plus `seccompProfile.type: RuntimeDefault`, which can be set once at pod level. ## Proposal Apply these as defaults to the pod spec and to every container and init container the operator generates, keeping the existing user overrides as the escape hatch. This is deliberately **not** gated behind an OpenShift detection switch or an opt-in flag: the settings are valid on any conformant cluster and benefit everyone, and a platform-conditional default means the hardened path is the one least tested in CI. Two defaults need care rather than a blanket change: - `fsGroup: 8983` is what OpenShift's `restricted-v2` SCC rejects, since it assigns its own project-scoped UID/GID range. It is also currently re-applied even when the user supplies a `podSecurityContext` that omits it (`solr_util.go:613-614`), so there is no way to turn it off — that bug is #466. - `readOnlyRootFilesystem` must be verified per container rather than assumed; `cp-solr-xml` is believed not to need a writable root (#801). ## Related - #466 — `fsGroup` cannot be cleared; blocks OpenShift. PR #706 proposes fixing it by autodetecting OpenShift, which is the platform-conditional approach this issue argues against — worth settling the direction before merging. - #582 — run `cp-solr-xml` as nonRoot - #801 — `readOnlyRootFilesystem: true` for `cp-solr-xml` - #797 — closed; made the default init containers' `securityContext` user-configurable, which is the override hook this would build on - #671 — original OpenShift PSA report, closed; contains a working SCC-based workaround -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
