janhoy opened a new pull request, #875: URL: https://github.com/apache/solr-operator/pull/875
Fixes #873, fixes #582 The pods the operator generates now satisfy the Kubernetes [Pod Security Standards "restricted" profile](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) out of the box, so they run in a namespace that enforces it without any extra configuration. Nothing outside that profile is defaulted, and there is no opt-in flag or platform detection: a platform-conditional default would make the hardened path the least tested one. A `seccompProfile` is set once at pod level. Every container and init container the operator generates gets `runAsNonRoot: true`, `allowPrivilegeEscalation: false` and `capabilities.drop: [ALL]`. The busybox-based init containers also get `runAsUser: 8983`, because that image has no non-root user of its own and the kubelet will not honour `runAsNonRoot` without one. `podSecurityContext`, `containerSecurityContext` and `defaultInitContainerSecurityContext` are now merged over these defaults field by field rather than replacing them, so one field opts out of one default. This also extends the init container security context to the TLS init containers, which it never reached before. The Solr Operator's own Helm chart container drops all capabilities and sets a seccomp profile too. The `volume-prep` init container can no longer `chown` a backup repository directory. It checks the directory is writable and fails with a message naming it; `defaultInitContainerSecurityContext.runAsUser: 0` restores the previous behaviour. ZooKeeper is not covered. A provided ensemble's pods come from the ZooKeeper operator, whose `zookeeperPodPolicy` exposes only a pod-level `securityContext`, and the `zookeeper-operator` chart dependency is configured by its own chart. Containers and volumes that users add themselves are theirs to bring in line. ### Testing A unit test evaluates the generated pod templates against the upstream profile checks, so a new operator container that is not hardened fails the build. Nothing in CI checked this before. Verified in a kind cluster against Kyverno's full restricted policy set and native Pod Security Admission with `enforce=restricted`: plain, backup-volume, TLS and provided-ZooKeeper SolrClouds, the Prometheus exporter and the operator itself all pass 17/17 policies and reach Ready. The ZooKeeper pods and the backup-volume root opt-in fail exactly the policies documented above. ### Notes - Stacked on #874, which renames this init container to `volume-prep`. Review that one first. - Adds `k8s.io/pod-security-admission` as a test-only dependency, pinned to the `k8s.io/api` version. It needs to move in lockstep, so #865 should bump it to 0.37.1. - Builds on the `defaultInitContainerSecurityContext` field added by @alexalex89 in #796. #706 proposes fixing #466 by autodetecting OpenShift, which is the platform-conditional approach this deliberately avoids; `fsGroup` is left untouched here, so #466 still needs its own decision. #801 asks for `readOnlyRootFilesystem` on the volume prep container, which is outside the profile and not defaulted. -- 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]
