IRIS Cluster defininition don't allow WebGateway to set security context

Yes, this can be handled through the IrisCluster definition by using a podTemplate.spec.securityContext on your IRIS data/compute nodes, and for Web Gateway in locked-down environments the examples use the non-root Web Gateway image instead of the regular Apache/NGINX image. [1][2]

One example specifically calls out that the regular Apache/NGINX Web Gateway containers run as root, and that this causes problems when you need non-root execution. It recommends using the non-root image webgateway-lockeddown and explicitly setting: [1]

securityContext:
  runAsUser: 51773
  runAsGroup: 51773
  runAsNonRoot: true
  fsGroup: 51773

[1]

The same example shows this being set in the IrisCluster CRD under topology.data.podTemplate.spec.securityContext, together with a locked-down Web Gateway under topology.data.webgateway: [1]

topology:
  data:
    podTemplate:
      spec:
        securityContext:
          runAsUser: 51773
          runAsGroup: 51773
          runAsNonRoot: true
          fsGroup: 51773
    webgateway:
      image: containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1
      type: apache-lockeddown

[1]

Another IrisCluster example shows the same pattern: non-root security context in podTemplate.spec.securityContext and a locked-down Web Gateway image/type in the cluster definition. [2]

So for your admission-policy error (runAsNonRoot / runAsUser != 0), the documented direction is to use the locked-down Web Gateway image and define the pod security context in the IrisCluster YAML. [1][2]

There is also an IKO setting useIrisFsGroup: true in the operator Helm values that is described as relevant when you need volumes mounted with the correct filesystem ownership for IRIS containers running as non-root. [1]

Based on the retrieved material, the practical next step is to update your IrisCluster to use:

• webgateway-lockeddown
• type: apache-lockeddown
• podTemplate.spec.securityContext with runAsUser, runAsGroup, runAsNonRoot, and fsGroup set to 51773 [1][2]

I cannot confirm from the retrieved documents whether every standalone topology.webgateway variant exposes its own separate podTemplate for a direct Web Gateway-only securityContext override, or whether you must rely on the node podTemplate plus the locked-down image pattern shown in the examples. [1][2][3]

If your environment still rejects the generated Web Gateway pod after applying the documented locked-down/non-root pattern, the retrieved documents do not provide further troubleshooting steps. [1][2]

Sources: