You should not try to generate your own key for this workflow. For iris-google-run-deploy-template, you need to request the service key from the InterSystems community team in Discord, specifically in the Open Exchange channel. One related announcement also says the key could be obtained in the Docker channel in Discord. [1][2]

After you receive it, add it to your GitHub repository secrets as SERVICE_ACCOUNT_KEY, and for this template you should put the JSON key there. [1]

If you are using the newer reusable demo deployment workflow instead, it also says to ask for the deployment key and store it as the SERVICE_ACCOUNT_KEY secret. [3]

Sources:

Replacing the character by converting the segment to a string, applying $Replace(), and then rebuilding the segment with EnsLib.HL7.Segment.ImportFromString() is a reasonable approach based on the returned examples. A returned example also shows ImportFromString() being used to create an HL7 segment from a string. [1]

The \r you are seeing at the end of the segment string is expected in HL7. The returned material states that carriage return (CR, ASCII 13) is the normal HL7 segment terminator, and another returned discussion confirms that seeing r as the segment terminator is normal HL7 behavior. [1][2]

For your specific question about removing that trailing \r, the returned documents do not provide a documented supported method for stripping it from the result of OutputToString() in this use case. They only establish that CR is the normal segment terminator and that ImportFromString() is used for segment-from-string reconstruction. [1]

A safer alternative shown in the returned material is to avoid rebuilding the full segment text where possible, and instead iterate through fields/components/subcomponents using GetValueAt() and SetValueAt(). That avoids working directly with the full serialized segment string, including its terminator. [1]

There is also a warning in the returned material that if your target is still an HL7 message, you should be careful not to blindly unescape or otherwise alter HL7 syntax in a way that makes the message invalid. [3]

If the goal is only to replace a literal non-ASCII data character such as © with (C), using $Replace() on the relevant data value is consistent with the returned examples. [1][3][4]

Sources:

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: