Deploying IRIS For Health on OpenShift

In case you're planning on deploying IRIS For Health, or any of our containerized products, via the IKO on OpenShift, I wanted to share some of the hurdles we had to overcome.

As with any IKO based installation, we first need to deploy the IKO itself. However we were getting this error:

Warning FailedCreate 75s (x16 over 3m59s) replicaset-controller Error creating: pods "intersystems-iris-operator-amd-f6757dcc-" is forbidden: unable to validate against any security context constraint:

proceeded by a list of all the security context constraints (SCCs) it could not validate against.

If you're like me, you may be surprised to see such an error when deploying in Kubernetes, because a security context constraint is not a Kubernetes object. This comes from the OpenShift universe, which extends the regular Kubernetes definition (read more about that here). 

What happens is that when we install the IKO via helm (see more on how to do that here) we create a service account.

[ User accounts are for humans. Service accounts are for application processes - Kubernetes docs].

This service account is put in charge of creating objects, such as the IKO pod. However, it fails.

OpenShift has a wide array of security permissions that can be limited, and one way to do this is via the security context constraint. 

What we needed to do was to create the following SecurityContextConstraint:

# Create SCC for ISC resources
kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
  name: iris-scc
  namespace: <iris namespace>
allowPrivilegedContainer: false
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowHostDirVolumePlugin: false
allowHostIPC: false
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
users:
  - system:serviceaccount:<iris namespace>:intersystems-iris-operator-amd

This gives access to the intersystems-iris-operator-amd service account to create objects by allowing it to validate against the iris-scc.

Next is to deploy the IrisCluster itself (more on that here). But this was failing too, because we needed to give the default service account access to the anyuid SCC, allowing our containers to run as any user (more specifically, we need to let the irisowner/51773 user run the containers!). We do this as follows:

ocm adm policy add-scc-to-user anyuid -z default -n <iris namespace>

We then create a rolebinding for the Admin role to the service account intersystems-iris-operator-amd, giving it the ability to create and monitor in the namespace. In OpenShift one can do this via the console, or as explained in kubectl create rolebinding.

One very last thing to note is that you may notice the container getting a SIGKILL, as is shown in the IRIS Messages Log:

Initializing IRIS, please wait...
Merging IRIS, please wait...
Starting IRIS
Startup aborted.
Unexpected failure: The target process received a termination signal 9.
Operation aborted.
[ERROR] Command "iris start IRIS quietly" exited with status 256

This could be due to Resource Quotas and Limit Ranges. Take into account that these exist at both the pod level and the container level.

Hope this helps and happy deploying!

P.S.

You may have noted that in the values.yaml of the Helm chart, there is this snippet:

serviceAccount:
  # Specifies whether a ServiceAccount should be created
  create: true
  # The name of the ServiceAccount to use.
  # If not set and create is true, a name is generated using the fullname template
  name:

You can actually change edit this and use a service account that already exists. For example:

serviceAccount:
  # Specifies whether a ServiceAccount should be created
  create: false
  # The name of the ServiceAccount to use.
  # If not set and create is true, a name is generated using the fullname template
  name: myExistingServiceAccount

Note that this is not a one size fits all, but it could help you if you're deploying on a strict system where you cannot create service accounts, but can use some that already exist.