**Bevor ich eintauche, möchte ich anerkennen, dass die Recherche und Analyse in diesem Artikel ausschließlich der herausragenden Arbeit von Rahul Raju, Senior Maximo Consultant bei Naviam, und Murali Shunmugaraja, Cloud and Dev Ops Lead bei Yarra Valley Water, zu verdanken sind.
‍

Migration vorhandener Maximo-Bereitstellungen, insbesondere beim Übergang von Von Maximo 7.6.1 zur Maximo Application Suite (MAS) auf OpenShift, stellt oft eine entscheidende Herausforderung in Bezug auf den persistenten Speicherzugriff dar: die DocLinks-Volumen.
‍

In diesem Beitrag werden die wichtigen Konfigurationsschritte beschrieben, die erforderlich sind, um sicherzustellen, dass Maximo Workloads greifen erfolgreich auf bestehende NetApp NFS-Volumes zu und interagieren mit ihnen, indem sie eine feste Gruppen-ID (GID) durchsetzen und so den Standard überwinden OpenShift dynamische Sicherheitsbeschränkungen.

Das Persistenz-Paradoxon: Feste Maximo-GIDs im Vergleich zu dynamischen OpenShift-UIDs
‍

‍
In der älteren Maximo 7.6.1-Umgebung wurde der DocLinks-Volume-Zugriff mithilfe fester Linux-Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs) bereitgestellt, sagen wir 1000 und 1001 jeweils mit bestimmten Benutzern verknüpft (wasuser, wasgroup).

Allerdings ist der MAS 9.0-Umgebung auf OpenShift führt zu einem Konflikt:

1. Dynamische Zuweisung: OpenShift weist dynamisch UIDs pro Namespace zu und weist Maximo-Prozessen häufig eine 10-stellige UID das kann je nach Bereitstellung variieren.
   ‍

2. Feste Durchsetzung: Gemäß dem alten Sicherheitsmodell erzwingt das bestehende NetApp NFS DocLinks-Volume den Zugriff ausschließlich auf der Grundlage der historischen, festen UID-Level-Berechtigungen.
   ‍

Da die containerisierten Maximo-Workloads eine zufällige, dynamisch zugewiesene UID verwenden, um auf das Volume zuzugreifen, während das Volume eine feste UID (insbesondere 1000) erwartet, stoßen wir auf Nicht übereinstimmende Dateieigentümer und Berechtigungsprobleme bei Aktionen wie Datei-Uploads.
‍

Damit unsere bestehenden NetApp Volume-Muster korrekt funktionieren, ist es wichtig, dass OpenShift mit dem Volume über eine feste UID/GID kommuniziert, z. B. 1000/1001, anstatt eine zufällige UID oder die Root-Gruppe zu verwenden. Wir benötigen eine bestimmte FSGroup- oder Gruppen-ID, um den Lese-/Schreibzugriff abzuwickeln.
‍

Die Lösung: Benutzerdefinierte SCCs und Maximo Workload Pod-Vorlagen

Um OpenShift zu zwingen, das erforderliche zu verwenden feste GID 1001 beim Zugriff auf das DocLinks-Volume nutzen wir die Security Context Constraints (SCCs) von OpenShift und wenden spezifische Änderungen an den Benutzerdefinierte Ressourcendefinition (CRD) von ManageWorkspaces Instanz.

Schritt 1: Erstellen Sie eine benutzerdefinierte Sicherheitskontextbeschränkung (SCC)

Zuerst erstellen wir ein SCC, das genau die feste GID vorschreibt, die wir benötigen. Diese Ressource legt Berechtigungen für bestimmte OpenShift-Steuerelemente fest.

Die kritische Einstellung stellt sicher, dass die FSGroup Muss Runen NUMMER 1001:
‍

# SCC-Schnipsel: MAS-Test-Manage-SCC
FS-Gruppe:
Typ: MustRunas
Bereiche:
- min: 1001 # Definiere die minimal zulässige GID
max: 1001 # Definiere die maximal zulässige GID
Zusätzliche Gruppen:
Typ: RunAsAny
Bände: ['*']
#... andere standardmäßige Sicherheitseinstellungen ohne Privilegien...

Wir speichern diese Definition (z. B. /mas-test-scc.yaml) und wenden Sie sie mit dem Befehl an

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

‍

Ein vollständiges Beispiel für eine solche Yaml-Datei finden Sie unten:
‍

‍

Schritt 2: Patchen Sie SCC auf das Dienstkonto

Als Nächstes müssen wir diesen benutzerdefinierten SCC (mas-test-manage-securitycontext) an das Dienstkonto binden, das für die Erstellung der Maximo-Pods verantwortlich ist (z. B. ibm-mas-manage-manage-deployment):
‍

Schritt 3: Namespace- und Maximo-Workload-Vorlagen aktualisieren

Zwei letzte Betriebsupdates sind erforderlich:

1. Namespace-Anmerkung: Aktualisieren Sie die Namespace-Anmerkung (oc edit namespace mas-test-manage -o yaml), um die Verwendung des festen Gruppenbereichs explizit zuzulassen, sodass der SCC innerhalb dieses Namespace funktionieren kann
   ‍

2. Workload-Pod-Vorlagen: Wir müssen die ManageWorkspaces CRD-Instanz ändern, um den Sicherheitskontext in den PodTemplates-Abschnitt einzufügen. Dadurch wird sichergestellt, dass die Container-Laufzeit beim Zugriff auf das DocLinks-Volume die erforderliche GID erzwingt.
   ‍

Der SecurityContext muss durchgesetzt werden Als Gruppe ausführen: 1001 für alle relevanten Maximo-Workloads. Diese feste GID muss auf die folgenden Workload-Vorlagen angewendet werden, die in der CRD definiert sind:

• Maxinst
• alles
• jms
• Mea
• ui
• Cron
• melden

Beispielausschnitt, der auf die ManageWorkspaces CRD-Instanz angewendet wurde:

POD-Vorlagen:
- Name: manage-maxinst
Sicherheitskontext:
runAsGroup: 1001 # Die feste GID erzwingen
Zusätzliche Gruppen:
- 0
- Name: alle
Sicherheitskontext:
Als Gruppe ausführen: 1001
Zusätzliche Gruppen:
- 0
#... wiederhole für jms, mea, cron, ui, report...
‍

Durch die Definition Als Gruppe ausführen: 1001, jeder Container, der auf das DocLinks-Volume zugreift, verwendet garantiert die korrekte historische GID, wodurch die seit langem bestehende Nichtübereinstimmung der Berechtigungen behoben wird.
‍

‍

Ergebnis

Zusammenfassend lässt sich sagen, dass, sobald diese Änderungen auf den OpenShift-Namespace angewendet werden, alle darin bereitgestellten Pods die konfigurierte GID (z. B. 1001) erben und mit ihr ausgeführt werden, wodurch eine konsistente Durchsetzung des Sicherheitskontexts für alle Workloads gewährleistet wird.
‍

‍

Veranschaulichung des Lösungsablaufs: Feste GID-Durchsetzung für MAS
‍

‍

Dieser strukturierte Ansatz gewährleistet eine erfolgreiche Migration und die fortgesetzte Funktionalität der DocLinks-Persistenz nach dem Upgrade auf Maximo Application Suite 9.0 auf OpenShift.
‍

Hinweis: - Die Sicherheitsrichtlinie auf NFS-Ebene wurde aktualisiert, um die Zugriffsbeschränkung nur auf GID-Ebene (1001) zu definieren. Korrektur einer konstanten UID für OpenShift Pods werden nicht empfohlen, insbesondere wenn Sie planen, mehrere Umgebungen auf demselben Cluster zu hosten. Daher müssen alle auf UID-Ebene definierten Einschränkungen aufgehoben oder auf GID-Ebene neu definiert werden.