Cuándo tener en cuenta useIrisFsGroup en vuestros despliegues con IKO

Si echáis un vistazo al archivo values.yaml del Helm chart de IKO, encontraréis:

useIrisFsGroup:false

Vamos a desglosar qué es useIrisFsGroup y en qué situaciones puede ser útil activarlo.

FsGroup se refiere al file system group (grupo del sistema de archivos).

Por defecto, los volúmenes en Kubernetes son propiedad del usuario root, pero necesitamos que IRIS sea propietario de sus propios archivos (IRIS en contenedores se instala bajo el usuario irisowner). Para solucionar esto, utilizamos uno de estos dos métodos:

1) initContainers

Los initContainers se ejecutan antes que los contenedores de la aplicación (como IRIS) en un pod. Generalmente preparan el entorno para la aplicación y luego terminan. El initContainer se ejecuta como root antes que IRIS y ejecuta:

chown irisowner:irisowner /irissys/*

El SecurityContext está, por defecto, configurado como:

RunAsUser:51773RunAsGroup:51773RunAsNonRoot:true

para el pod. Y vemos que 51773 es el ID de usuario y grupo para irisowner:

$ id
uid=51773(irisowner) gid=51773(irisowner) groups=51773(irisowner)

2) Montar volúmenes con una propiedad de grupo específica

Algunos entornos pueden restringir que los contenedores se ejecuten como root, por ejemplo, mediante las Security Context Constraints en OpenShift. En este caso, ni siquiera podemos ejecutar un initContainer como root y necesitaremos que los volúmenes tengan la propiedad del sistema de archivos correcta en el momento de su montaje. Para hacerlo, desplegad el InterSystems Kubernetes Operator con:

useIrisFsGroup:true

en el archivo /chart/iris-operator/values.yaml.

Ahora, vuestros pods se desplegarán sin initContainers.

Una advertencia: si deseáis configurar sidecars, se requiere un paso adicional. No podréis utilizar el sidecar habitual de Apache/NGINX. Encontraréis este problema:

>> kubectl get pods
NAME                                              READY   STATUS    RESTARTS      AGE
intersystems-iris-operator-amd-76b75f6b48-7lnw2   1/1     Running   043m
iris-data-0-01/2     Error     2 (22s ago)   2m

lo que resultará en un CrashLoopBackOff. Un análisis más profundo nos muestra que cuando el sidecar habitual de Apache/NGINX está presente, el parámetro useIrisFsGroup no se tiene en cuenta. Esto se debe a que estos contenedores de Apache/NGINX, en este caso el sidecar, se ejecutan como root. IRIS no se ejecuta como root y no puede acceder a sus directorios, lo que causa nuestro problema.

irisowner@iris-data-0-0:/irissys$ ls -l
total 16
drwxrwxrwx 3 root root  107 Mar 31 14:28 cpf
drwxr-xr-x 3 root root 4096 Mar 31 14:21 data
drwxr-xr-x 3 root root 4096 Mar 31 14:21 journal1
drwxr-xr-x 3 root root 4096 Mar 31 14:21 journal2
drwxrwxrwt 3 root root  100 Mar 31 14:28 key
drwxr-xr-x 3 root root 4096 Mar 31 14:21 wij

IRIS falla con el error:

[ERROR] Command "iris start IRIS quietly" exited with status 256
03/31/25-14:41:06:870 (795) 3 [Utility.Event] Error while moving data directories ERROR #5001: Cannot create target: /irissys/data/IRIS/

En su lugar, deberíamos utilizar la imagen non-root del web gateway  (ya que suponemos que queremos que todas nuestras imágenes se ejecuten como no root). Esto implicaría un web gateway restringido o locked-down. También debemos asegurarnos de agregar el security context para hacer cumplir esta condición. Necesitamos declarar explícitamente:

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

en vuestros nodos de datos/cómputo.

Un ejemplo de YAML para nuestro IrisCluster CRD que integra todo esto se puede ver a continuación.

apiVersion:intersystems.com/v1alpha1kind:IrisClustermetadata:  name:irisspec:  licenseKeySecret:    name:iris-key-secret  configSource:    name:iris-cpf  imagePullSecrets:    - name:intersystems-pull-secret  topology:    data:      image:containers.intersystems.com/intersystems/irishealth:2025.1      compatibilityVersion:"2025.1.0"      mirrored:true      podTemplate:        spec:          resources:            requests:              memory:"4Gi"              cpu:"2"            limits:              memory:"4Gi"              cpu:"2"          securityContext:            runAsUser:51773            runAsGroup:51773            runAsNonRoot:true            fsGroup:51773      webgateway:        image:containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1        type:apache-lockeddown        applicationPaths:          -/csp/sys          -/csp/user          -/csp/broker          -/api          -/isc          -/oauth2          -/ui          -/csp/healthshare        loginSecret:          name:iris-webgateway-secret    webgateway:      replicas:1      image:containers.intersystems.com/intersystems/webgateway-lockeddown:2025.1      type:apache-lockeddown      podTemplate:        spec:          resources:            requests:              memory:"2Gi"              cpu:"1"            limits:              memory:"2Gi"              cpu:"1"      applicationPaths:        -/csp/sys        -/csp/user        -/csp/broker        -/api        -/isc        -/oauth2        -/ui        -/csp/healthshare      alternativeServers:LoadBalancing      loginSecret:        name:iris-webgateway-secret    arbiter:      image:containers.intersystems.com/intersystems/arbiter:2025.1  serviceTemplate:    spec:      type:ClusterIP

Feliz YAMLing