**Before diving in, I want to acknowledge the research and analysis in this piece is entirely thanks to the outstanding work of Rahul Raju, Senior Maximo Consultant with Naviam, and Murali Shunmugaraja, Cloud and Dev Ops Lead with Yarra Valley Water.
‍

Migrating existing Maximo deployments, specifically transitioning from Maximo 7.6.1 to Maximo Application Suite (MAS) on OpenShift, often presents a critical challenge concerning persistent storage access: the DocLinks volume.
‍

This post details the vital configuration steps required to ensure that Maximo workloads successfully access and interact with existing NetApp NFS volumes by enforcing a fixed Group ID (GID), thereby overcoming standard OpenShift dynamic security constraints.

The Persistence Paradox: Fixed Maximo GIDs vs. Dynamic OpenShift UIDs
‍

‍
In the legacy Maximo 7.6.1 environment, DocLinks volume access was provisioned using fixed Linux User IDs (UIDs) and Group IDs (GIDs), let us say 1000 and 1001 respectively, associated with specific users (wasuser, wasgroup).

However, the MAS 9.0 environment on OpenShift introduces a conflict:

1. Dynamic Allocation: OpenShift dynamically allocates UIDs per namespace, often assigning Maximo processes a 10-digit UID that can vary across deployments.
   ‍

2. Fixed Enforcement: As per the legacy security model, the existing NetApp NFS DocLinks volume enforces access strictly based on the historical, fixed UID-level permissions.
   ‍

Because the containerized Maximo workloads use a random, dynamically assigned UID to access the volume, while the volume expects a fixed UID (specifically 1000), we encounter file ownership mismatches and permission issues when attempting actions like file uploads.
‍

For our existing NetApp volume patterns to function correctly, it is vital that OpenShift communicates to the volume on a fixed UID/GID, such as 1000/1001, instead of using a random UID or the root group. We need a specific fsGroup or Group ID to handle read/write access.
‍

The Solution: Custom SCCs and Maximo Workload Pod Templates

To compel OpenShift to use the required fixed GID 1001 when accessing the DocLinks volume, we leverage OpenShift's Security Context Constraints (SCCs) and apply specific changes to the ManageWorkspaces Custom Resource Definition (CRD) instance.

Step 1: Create a Custom Security Context Constraint (SCC)

First, we create an SCC that mandates the exact fixed GID we need. This resource sets permissions on specific OpenShift controls.

The critical setting ensures that the fsGroup MustRunAs GID 1001:
‍

# SCC Snippet: mas-test-manage-SCC
fsGroup:
 type: MustRunAs
 ranges:
   - min: 1001       # Define the minimum allowed GID
     max: 1001       # Define the maximum allowed GID
supplementalGroups:
 type: RunAsAny
volumes: ['*']
# ... other standard non-privileged security settings ...

We save this definition (e.g., ./mas-test-scc.yaml) and apply it using command

oc apply -f ./mas-test-scc.yaml

‍

Complete example of such yaml file is shared below:
‍

‍

Step 2: Patch SCC to the Service Account

Next, we must bind this custom SCC (mas-test-manage-securitycontext) to the service account responsible for creating the Maximo pods (e.g., ibm-mas-manage-manage-deployment):
‍

Step 3: Update Namespace and Maximo Workload Templates

Two final operational updates are necessary:

1. Namespace Annotation: Update the namespace annotation (oc edit namespace mas-test-manage -o yaml) to explicitly allow the use of the fixed group range, thereby permitting the SCC to function within that namespace
   ‍

2. Workload Pod Templates: We must modify the ManageWorkspaces CRD instance to inject the security context into the podTemplates section. This ensures the container runtime forces the required GID when accessing the DocLinks volume.
   ‍

The securityContext must enforce runAsGroup: 1001 across all relevant Maximo workloads. This fixed GID must be applied to the following workload templates defined in the CRD:

• maxinst
• all
• jms
• mea
• ui
• cron
• report

Example snippet applied to the manageWorkspaces CRD instance:

podTemplates:
   - name: manage-maxinst
     securityContext:
       runAsGroup: 1001         # Enforce the fixed GID
       supplementalGroups:
         - 0
   - name: all
Contexto de seguridad:
Funciona como grupo: 1001
Grupos suplementarios:
- 0
#... repita para jms, mea, cron, ui, report...
‍

Al definir Funciona como grupo: 1001, se garantiza que todos los contenedores que acceden al volumen de DocLinks utilizan el GID histórico correcto, lo que resuelve el antiguo desajuste de permisos.
‍

‍

Resultado

En resumen, una vez que estos cambios se apliquen al espacio de nombres de OpenShift, todos los pods implementados en él heredarán y se ejecutarán con el GID configurado (por ejemplo, 1001), lo que garantiza una aplicación coherente del contexto de seguridad en todas las cargas de trabajo.
‍

‍

Ilustración del flujo de soluciones: aplicación de GID fija para MAS
‍

‍

Este enfoque estructurado garantiza una migración exitosa y una funcionalidad continua de la persistencia de DocLink tras la actualización a Maximo Application Suite 9.0 en OpenShift.
‍

Nota: - La política de seguridad a nivel NFS se actualizó para definir la restricción de acceso únicamente a nivel GID (1001). Corregir un UID constante para OpenShift No se recomienda usar pods, especialmente si planeas hospedar varios entornos en el mismo clúster. Por lo tanto, cualquier restricción definida a nivel de UID debe suprimirse o redefinirse a nivel de GID.