[computate]

Adding autodetection of solr-operator running on an OpenShift cluster to remove the default Solr fsGroup, and have an empty securityContext on OpenShift. Regular Kubernetes deployments have the same securityContext as before with fsGroup.

I have successfully tested these changes in OpenShift Local and confirmed that an empty securityContext allows the solrcloud pod run on OpenShift.

spec:
  template:
    spec:
      securityContext: {}

Fixes #466

[HoustonPutman]

I feel like it might be better to automatically tell if a cluster is openshift or not, and behave accordingly: https://github.com/grafana/grafana-operator/blob/master/controllers/autodetect/main.go

We can still let users over-ride the default, but just automatically choose the correct default for openshift. Thoughts?

[gerlowskija]

Hey @computate - starting to follow up on some of these outstanding PRs - what do you think about Houston's suggestion above regarding auto-detection? Is that something you'd be willing to add in here?

[computate]

Thanks for following up @gerlowskija and @HoustonPutman , I am a big fan of Solr. I would love to see the Zookeeper and Solr Operator work better on OpenShift, because I have had problems with it and had to switch to using bitnami helm charts instead. I haven't considered a solution like if apiGroups[i].Name == "route.openshift.io" { before. I will keep this update in mind, since this operator is also golang. I may need to create other issues for other things, I think I was also mostly blocked with issues with the Zookeeper Operator.

[gerlowskija]

I would love to see the Zookeeper and Solr Operator work better on OpenShift, because I have had problems

Sorry to hear it! ZK Operator stuff we can't do as much about, but we'd love to have better support for OpenShift on the Solr side - if you remember what the other issues were, please let us know with a ticket. We're blind in some ways without that feedback!

[gerlowskija]

Thinking a bit more on the proposal here, I'm a little leery about adding an explicit openShift: true flag. One flag isn't all that bad, but there's a number of popular environments out there that might eventually want similar tweaking.

Auto-detection I feel much better about, since it needn't add to our CRD. Could we just do auto-detection to start, and revisit down the road if that ends up being insufficient?

[computate]

Hi @gerlowskija and @HoustonPutman , I have now updated my branch to support the grafana-operator way of autodection of solr-operator running on OpenShift! If you would like to try this out, try my documentation for running OpenShift Local on your own computer with Windows 11 Pro, or Linux:

https://smaq.computate.org/en-us/view/article/install-openshift-local-on-your-computer

Then

install -d ~/.local/src/computate-gitops/
git clone https://github.com/computate-org/computate-gitops.git \
  ~/.local/src/computate-gitops/
cd ~/.local/src/computate-gitops/
oc apply -k openshift-local/gitops/base/

Then wait for the GitOps operator to become ready. You will be able to log into ArgoCD with your OpenShift Local kubeadmin credentials: https://openshift-gitops-server-openshift-gitops.apps-crc.testing/

oc -n openshift-operators wait pod -l control-plane=gitops-operator \
  --for=condition=Ready --timeout=5m
oc -n openshift-gitops wait pod \
  -l app.kubernetes.io/name=openshift-gitops-application-controller \
  --for=condition=Ready --timeout=5m

Then deploy the zookeeper operator with GitOps:

oc apply -k openshift-local/zookeeper-operator/applications/
oc apply -k openshift-local/zookeeper/applications/

Then deploy the solr operator with GitOps:

oc apply -k openshift-local/solr-operator/applications/
oc apply -k openshift-local/solr/applications/

You should be able to find a SolrCloud running in the solr namespace.

You will also find a log in the solr-operator pod:

{"level":"info","ts":"2025-09-25T04:13:19Z","logger":"setup","msg":"autodetect","isOpenShift":true}

[computate]

I have temporarily pointed my solr-operator ArgoCD Application to my branch, and my solr-operator image on quay.io quay.io/computate/solr-operator until this gets merged:
https://github.com/computate-org/computate-gitops/blob/main/openshift-local/solr-operator/applications/solr-operator/application.yaml#L13-L15

spec:
  project: default
  source:
    repoURL: https://github.com/computate/solr-operator.git
    targetRevision: openshift
    path: helm/solr-operator
    helm:
      parameters:
        - name: zookeeper-operator.install
          value: 'false'
        - name: zookeeper-operator.use
          value: 'false'
        - name: image.repository
          value: 'quay.io/computate/solr-operator'
        - name: image.tag
          value: 'openshift'

[janhoy]

Hi. Elsewhere we have discussed that we may not want vendor-specific toggles in solr-operator. That may be a reason why this has not been merged?

@computate Please see #875 where I have done an AI assisted implementation of the industry standard "restrited" profile. It is on by default rather than a toggle, but user can still override if they want/need. I don't know how that profile aligns with what OpenShift requires, but likely it will go much of the way there. Please have a look and see if it can be a unified solution also to this ask.

[computate]

Thanks for the updates you provided @janhoy , do you already have a solr-operator Container Image built somewhere in a public registry with these changes? I have been running my own branch of Solr Operator here, but I am highly motivated to get Solr Operator running on OpenShift upstream, because it is a very valuable open source search engine for the sovereign cloud and sovereign data center industry.

[janhoy]

No, this is WIP, so I invite you to review and give feedback on whether my branch will solve your needs or not. I do not have an openshift cluster myself. Should be fairly easy to build an image from the branch.

[computate]

@janhoy I have been testing a new container image for this branch that I have pushed here: quay.io/computate/solr-operator:restricted-pss-defaults

I have deployed this to Red Hat OpenShift with this ArgoCD application:

project: default
source:
  repoURL: https://github.com/computate/solr-operator.git
  path: helm/solr-operator
  targetRevision: openshift
  helm:
    parameters:
      - name: zookeeper-operator.install
        value: 'false'
      - name: zookeeper-operator.use
        value: 'false'
      - name: image.repository
        value: quay.io/computate/solr-operator
      - name: image.tag
        value: restricted-pss-defaults
    skipCrds: true
destination:
  server: https://kubernetes.default.svc
  namespace: solr
syncPolicy:
  automated:
    prune: true
    selfHeal: true
  syncOptions:
    - CreateNamespace=true
  managedNamespaceMetadata:
    labels:
      database-engine-admin: 'true'

[computate]

I see the following securityContexts appear in the StatefulSet of a SolrCloud.

kind: StatefulSet
apiVersion: apps/v1
spec:
  template:
    spec:
      securityContext:
        fsGroup: 8983
        seccompProfile:
          type: RuntimeDefault
      initContainers:
        - name: setup-zk
          securityContext:
            capabilities:
              drop:
                - ALL
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
      containers:
        - name: solrcloud-node
          securityContext:
            capabilities:
              drop:
                - ALL
            runAsNonRoot: true
            allowPrivilegeEscalation: false

[computate]

This is different from the main branch:

kind: StatefulSet
apiVersion: apps/v1
spec:
  template:
    spec: {}
      securityContext:
        fsGroup: 8983
      initContainers:
        - name: setup-zk
          securityContext:
            readOnlyRootFilesystem: true

[computate]

Unfortunately for OpenShift, SolrCloud still fails with the following events in the janhoy:restricted-pss-defaults branch, just the same as before in the main branch.

$ oc -n solr get event --field-selector involvedObject.name=solr-solrcloud
LAST SEEN   TYPE      REASON         OBJECT                               MESSAGE
5m1s        Normal    NoPods         poddisruptionbudget/solr-solrcloud   No matching pods found
2m17s       Warning   FailedCreate   statefulset/solr-solrcloud           Create Pod solr-solrcloud-0 in StatefulSet solr-solrcloud failed error: pods "solr-solrcloud-0" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: [8983]: 8983 is not an allowed group, provider restricted-v3: .spec.hostUsers: Invalid value: null: Host Users must be set to false, provider "restricted": Forbidden: not usable by user or serviceaccount, provider "nested-container": Forbidden: not usable by user or serviceaccount, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid-v2": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "hostpath-provisioner": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

[computate]

@janhoy here is a new computate:restricted-pss-defaults-openshift branch I created that is first rebased with your janhoy:restricted-pss-defaults branch, with a new commit of mine to add the autodetection of OpenShift to produce the expected empty securityContext: {} for SolrCloud and SolrPrometheusExporter. This is now working with my tests in OpenShift Local. There are no changes to these CustomResourceDefinitions. Does this work instead, adding the isOpenShift parameter to the defaultPodSecurityContext function, but detecting it automatically in main.go? I could merge this commit into my pull request branch here after your pull request gets merged.