**Voordat ik erin duik, wil ik toegeven dat het onderzoek en de analyse in dit stuk volledig te danken zijn aan het uitstekende werk van Rahul Raju, Senior Maximo Consultant bij Naviam, en Murali Shunmugaraja, Cloud and Dev Ops Lead bij Yarra Valley Water.
‍

Migratie van bestaande Maximo-implementaties, met name de overgang van Maximo 7.6.1 naar Maximo Application Suite (MAS) op OpenShift, vormt vaak een kritieke uitdaging met betrekking tot permanente opslagtoegang: de DocLinks-volume.
‍

Dit bericht beschrijft de essentiële configuratiestappen die nodig zijn om ervoor te zorgen dat Maximo workloads hebben met succes toegang tot en interactie met bestaande NetApp NFS-volumes door een vaste groeps-ID (GID) af te dwingen, waardoor de standaard wordt overwonnen OpenShift dynamische beveiligingsbeperkingen.

The Persistence Paradox: vaste maximo GID's versus dynamische OpenShift-UID's
‍

‍
In de oude Maximo 7.6.1-omgeving werd de volumetoegang van DocLink voorzien van vaste Linux-gebruikers-ID's (UID's) en groeps-ID's (GID's), laten we zeggen 1000 en 1001 respectievelijk gekoppeld aan specifieke gebruikers (wasuser, wasgroup).

Echter, de MAS 9.0-omgeving op OpenShift introduceert een conflict:

1. Dynamische toewijzing: OpenShift wijst op dynamische wijze UID's toe per naamruimte, waarbij Maximo-processen vaak een UID van 10 cijfers dat per implementatie kan verschillen.
   ‍

2. Vaste handhaving: Volgens het oude beveiligingsmodel dwingt het bestaande NetApp NFS DocLinks-volume toegang af, strikt gebaseerd op de historische, vaste machtigingen op UID-niveau.
   ‍

Omdat de Maximo-workloads in containers een willekeurige, dynamisch toegewezen UID gebruiken om toegang te krijgen tot het volume, terwijl het volume een vaste UID verwacht (met name 1000), komen we verkeerde combinaties van bestandseigendom en toestemmingsproblemen bij het uitvoeren van acties zoals het uploaden van bestanden.
‍

Om onze bestaande NetApp-volumepatronen correct te laten functioneren, is het essentieel dat OpenShift communiceert met het volume op een vaste UID/GID, zoals 1000/1001, in plaats van een willekeurige UID of de basisgroep te gebruiken. We hebben een specifieke FSGroup- of groeps-ID nodig om lees-/schrijftoegang te verwerken.
‍

De oplossing: aangepaste SCC's en Maximo Workload Pod-sjablonen

Om OpenShift te dwingen het vereiste te gebruiken vaste GID 1001 bij toegang tot het DocLinks-volume maken we gebruik van de Security Context Constraints (SCC's) van OpenShift en passen we specifieke wijzigingen toe op de ManageWorkSpaces aangepaste brondefinitie (CRD) instantie.

Stap 1: Maak een aangepaste beveiligingscontextbeperking (SCC)

Eerst maken we een SCC die precies de vaste GID bepaalt die we nodig hebben. Deze bron stelt machtigingen in voor specifieke OpenShift-besturingselementen.

De kritieke setting zorgt ervoor dat de FSGroup Moet Runas GID 1001:
‍

# SCC-fragment: MAS-test-Manage-SCC
FS-groep:
soort: MustRunas
reeksen:
- min: 1001 # Definieer de minimaal toegestane GID
max: 1001 # Definieer de maximaal toegestane GID
Aanvullende groepen:
type: RunAsany
jaargangen: ['*']
#... andere standaard niet-geprivilegieerde beveiligingsinstellingen...

We slaan deze definitie op (bijv. /mas-test-scc.yaml) en pas het toe met de opdracht

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

‍

Het volledige voorbeeld van zo'n yaml-bestand wordt hieronder gedeeld:
‍

‍

Stap 2: SCC koppelen aan het serviceaccount

Vervolgens moeten we deze aangepaste SCC (mas-test-manage-securitycontext) koppelen aan het serviceaccount dat verantwoordelijk is voor het aanmaken van de Maximo-pods (bijvoorbeeld ibm-mas-manage-manage-deployment):
‍

Stap 3: Namespace- en Maximo Workload-sjablonen bijwerken

Er zijn twee laatste operationele updates nodig:

1. Annotatie van de naamruimte: De annotatie van de naamruimte bijwerken (of de naamruimte mas-test-manage -o yaml bewerken) om expliciet het gebruik van het bereik van de vaste groep toe te staan, zodat de SCC binnen die naamruimte kan functioneren
   ‍

2. Workload Pod-sjablonen: We moeten de ManageWorkSpaces CRD-instantie aanpassen om de beveiligingscontext in de sectie PodTemplates te injecteren. Dit zorgt ervoor dat de containerruntime de vereiste GID afdwingt bij toegang tot het DocLinks-volume.
   ‍

De SecurityContext moet afdwingen Runas Groep: 1001 voor alle relevante Maximo-workloads. Deze vaste GID moet worden toegepast op de volgende werkbelastingsjablonen die zijn gedefinieerd in de CRD:

• maximaal
• allemaal
• jms
• vlees
• ui
• kroon
• verslag doen van

Voorbeeldfragment toegepast op de ManageWorkSpaces CRD-instantie:

POD-sjablonen:
- naam: manage-maxinst
Beveiligingscontext:
RunAsGroup: 1001 # De vaste GID afdwingen
Aanvullende groepen:
- 0
- naam: alle
Beveiligingscontext:
Runas Groep: 1001
Aanvullende groepen:
- 0
#... herhaal dit voor jms, mea, cron, ui, report...
‍

Door te definiëren Runas Groep: 1001gebruikt elke container die toegang heeft tot het DocLinks-volume gegarandeerd de juiste historische GID, waardoor de langdurige mismatch tussen machtigingen wordt opgelost.
‍

‍

Uitkomst

Samenvattend: zodra deze wijzigingen zijn toegepast op de OpenShift-naamruimte, zullen alle pods die erin worden geïmplementeerd, de geconfigureerde GID (bijvoorbeeld 1001) overnemen en ermee worden uitgevoerd, wat zorgt voor consistente handhaving van de beveiligingscontext voor alle workloads.
‍

‍

De oplossingsstroom illustreren: vaste GID-handhaving voor MAS
‍

‍

Deze gestructureerde aanpak zorgt voor een succesvolle migratie en voortdurende functionaliteit van DocLink's persistentie na de upgrade naar Maximo Application Suite 9.0 op OpenShift.
‍

Opmerking: - Het beveiligingsbeleid op NFS-niveau is bijgewerkt om de toegangsbeperking alleen op GID-niveau (1001) te definiëren. Een constante UID repareren voor OpenShift Pods worden niet aanbevolen, vooral niet als u van plan bent meerdere omgevingen op hetzelfde cluster te hosten. Daarom moeten alle beperkingen die op UID-niveau zijn gedefinieerd, worden ingetrokken of opnieuw worden gedefinieerd op GID-niveau.