**Avant de me lancer, je tiens à souligner que les recherches et les analyses présentées dans cet article sont entièrement dues au travail exceptionnel de Rahul Raju, consultant senior Maximo chez Naviam, et de Murali Shunmugaraja, responsable des opérations cloud et de développement chez Yarra Valley Water.
‍

Migration des déploiements Maximo existants, en particulier la transition depuis Maximo 7.6.1 vers Maximo Application Suite (MAS) sur OpenShift, présente souvent un défi majeur en ce qui concerne l'accès persistant au stockage : Volume de DocLinks.
‍

Cet article détaille les étapes de configuration essentielles requises pour garantir que Maximo les charges de travail accèdent et interagissent avec succès avec les volumes NetApp NFS existants en appliquant un ID de groupe (GID) fixe, dépassant ainsi les normes OpenShift contraintes de sécurité dynamiques.

Le paradoxe de la persistance : GID maximo fixes par rapport aux UID OpenShift dynamiques
‍

‍
Dans l'ancien environnement Maximo 7.6.1, l'accès aux volumes DocLinks était provisionné à l'aide d'identifiants utilisateur (UID) et d'identifiants de groupe (GID) Linux fixes, disons 1000 et 1001 respectivement, associés à des utilisateurs spécifiques (wasuser, wasgroup).

Cependant, le Environnement MAS 9.0 sur OpenShift introduit un conflit :

1. Allocation dynamique : OpenShift alloue dynamiquement les UID par espace de noms, en attribuant souvent aux processus Maximo un UID à 10 chiffres qui peuvent varier selon les déploiements.
   ‍

2. Application fixe : Conformément à l'ancien modèle de sécurité, le volume NetApp NFS DocLinks existant applique l'accès strictement sur la base des autorisations historiques et fixes au niveau de l'UID.
   ‍

Étant donné que les charges de travail Maximo conteneurisées utilisent un UID aléatoire et attribué dynamiquement pour accéder au volume, alors que le volume attend un UID fixe (en particulier 1000), nous rencontrons incohérences de propriété de fichiers et problèmes d'autorisation lors de tentatives d'actions telles que le téléchargement de fichiers.
‍

Pour que nos modèles de volume NetApp existants fonctionnent correctement, il est essentiel qu'OpenShift communique avec le volume sur un UID/GID fixe, tel que 1000/1001, au lieu d'utiliser un UID aléatoire ou le groupe racine. Nous avons besoin d'un FSGroup ou d'un ID de groupe spécifique pour gérer l'accès en lecture/écriture.
‍

La solution : des SCCs personnalisés et des modèles de modules Maximo Workload

Pour obliger OpenShift à utiliser les GID fixe 1001 lors de l'accès au volume DocLinks, nous tirons parti des contraintes de contexte de sécurité (SCC) d'OpenShift et appliquons des modifications spécifiques au Définition de ressource personnalisée (CRD) de ManageWorkspaces instance.

Étape 1 : Création d'une contrainte de contexte de sécurité personnalisée (SCC)

Tout d'abord, nous créons un SCC qui impose le GID fixe exact dont nous avons besoin. Cette ressource définit les autorisations sur des contrôles OpenShift spécifiques.

Le réglage critique garantit que le FSgroup Les runes incontournables NUMÉRO 1001 :
‍

# Extrait SCC : MAS-Test-Manage-SCC
Groupe FS :
type : MustRunas
gammes :
- min : 1001 # Définissez le GID minimum autorisé
max : 1001 # Définissez le GID maximum autorisé
Groupes supplémentaires :
type : RunAsAny
volumes : ['*']
#... autres paramètres de sécurité standard non privilégiés...

Nous sauvegardons cette définition (par exemple,. /mas-test-scc.yaml) et appliquez-le à l'aide de la commande

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

‍

Un exemple complet d'un tel fichier yaml est partagé ci-dessous :
‍

‍

Étape 2 : appliquer un correctif SCC au compte de service

Ensuite, nous devons lier ce SCC personnalisé (mas-test-manage-securitycontext) au compte de service responsable de la création des pods Maximo (par exemple, ibm-mas-manage-manage-deployment) :
‍

Étape 3 : Mettre à jour les modèles d'espace de noms et de charge de travail maximale

Deux dernières mises à jour opérationnelles sont nécessaires :

1. Annotation de l'espace de noms : Mettez à jour l'annotation de l'espace de noms (oc edit namespace mas-test-manage -o yaml) pour autoriser explicitement l'utilisation de la plage de groupes fixe, permettant ainsi au SCC de fonctionner dans cet espace de noms
   ‍

2. Modèles de modules de charge de travail : Nous devons modifier l'instance CRD de ManageWorkspaces pour injecter le contexte de sécurité dans la section PodTemplates. Cela garantit que l'exécution du conteneur force le GID requis lors de l'accès au volume DocLinks.
   ‍

Le SecurityContext doit être appliqué RunasGroup : 1001 sur toutes les charges de travail Maximo pertinentes. Ce GID fixe doit être appliqué aux modèles de charge de travail suivants définis dans le CRD :

• maxinst
• tous
• jms
• repas
• interface
• cron
• rapport

Exemple d'extrait appliqué à l'instance CRD de ManageWorkSpaces :

Modèles de POD :
- nom : manage-maxinst
Contexte de sécurité :
RunAsGroup : 1001 # Appliquer le GID fixe
Groupes supplémentaires :
- 0
- nom : tous
Contexte de sécurité :
RunasGroup : 1001
Groupes supplémentaires :
- 0
#... répétez pour jms, mea, cron, ui, report...
‍

En définissant RunasGroup : 1001, chaque conteneur accédant au volume DocLinks est assuré d'utiliser le GID historique correct, résolvant ainsi l'incompatibilité d'autorisations de longue date.
‍

‍

Résultat

En résumé, une fois ces modifications appliquées à l'espace de noms OpenShift, tous les pods déployés dans celui-ci hériteront et s'exécuteront avec le GID configuré (par exemple, 1001), garantissant une application cohérente du contexte de sécurité entre les charges de travail.
‍

‍

Illustration du flux de solutions : application d'un GID fixe pour MAS
‍

‍

Cette approche structurée garantit une migration réussie et la continuité des fonctionnalités de la persistance de DocLinks après la mise à niveau vers Maximo Application Suite 9.0 sur OpenShift.
‍

Remarque : - La politique de sécurité au niveau NFS a été mise à jour pour définir la restriction d'accès au niveau GID (1001) uniquement. Fixation d'un UID constant pour OpenShift Pods n'est pas recommandé, en particulier lorsque vous prévoyez d'héberger plusieurs environnements sur le même cluster. Par conséquent, toutes les restrictions définies au niveau de l'UID doivent être supprimées ou redéfinies au niveau du GID.