Warum schlägt meine App mit einem Gruppen-ID-Fehler für NFS-Dateispeicherberechtigungen fehl?

Fehler bei den Berechtigungen für Dateispeichergruppen-IDs beheben.

Klassische Infrastruktur

Nachdem Sie für Ihren Cluster NFS-Speicher erstellt oder Ihrem Cluster vorhandenen NFS-Speicher hinzugefügt haben, schlägt die Containerbereitstellung der App fehl. Sie erhalten Fehlernachrichten für Gruppen-IDs (GIDs).

Wenn Sie einen Container anhand eines Image erstellen, in dem kein Benutzer und keine Benutzer-ID (UID) angegeben ist, werden alle Anweisungen in der Dockerfile standardmäßig vom Rootbenutzer (UID: 0) im Container ausgeführt.

Wenn Sie jedoch eine NFS-Dateifreigabe an Ihren Container anhängen möchten, wird die Benutzer-ID 0 innerhalb des Containers der Benutzer-ID nobody auf dem NFS-Hostsystem zugeordnet. Daher ist die Benutzer-ID nobody und nicht root Eigner des Datenträgermountpfads. Diese Sicherheitsfunktion wird auch als Root-Squash bezeichnet. Root-Squash schützt die Daten innerhalb des NFS, indem ein Container angehängt wird, ohne dass der Benutzer-ID Rootberechtigungen für das eigentliche NFS-Hostdateisystem erteilt werden.

Verwenden Sie Kubernetes, um DaemonSet auf allen Ihren Worker-Knoten Root-Rechte für den Speicher-Mount-Pfad der Dateifreigaben von NFSv4 zu aktivieren.

Um die Rootberechtigung für den Datenträgermountpfad zuzulassen, müssen Sie eine Konfigurationszuordnung auf Ihrem Workerknoten einrichten. Die Konfigurationszuordnung ordnet die Benutzer-ID nobody Ihres NFS-Hostsystems der Rootbenutzer-ID 0 in Ihrem Container zu. Dieser Prozess wird auch als No-Root-Squash bezeichnet. Eine effektive Methode für die Aktualisierung aller Workerknoten ist die Verwendung einer Dämongruppe, die einen angegebenen Pod auf jedem Workerknoten in Ihrem Cluster ausführt. In diesem Fall aktualisiert der Pod, der von der Dämongruppe gesteuert wird, jeden einzelnen Workerknoten, um die Rootberechtigung für den Datenträgermountpfad zu aktivieren.

Die Bereitstellung ist so konfiguriert, dass der Pod der Dämongruppe im privilegierten Modus ausgeführt werden kann, was für den Zugriff auf das Hostdateisystem erforderlich ist. Wenn Sie einen Pod im privilegierten Modus ausführen, stellt dies ein Sicherheitsrisiko dar. Verwenden Sie diese Option daher mit Vorsicht.

Während die Dämongruppe ausgeführt wird, werden neue Workerknoten, die dem Cluster hinzugefügt werden, automatisch aktualisiert.

Vorbereitende Schritte:

Führen Sie die folgenden Schritte aus.

  1. Kopieren Sie die YAML-Datei für die Bereitstellung des norootsquash Daemon-Sets.

  2. Erstellen Sie die Dämongruppenbereitstellung norootsquash.

    oc apply -f norootsquash.yaml

  3. Rufen Sie den Namen des Pods ab, an den Ihr Speicherdatenträger angehängt ist. Dieser Pod ist nicht mit den Pods für norootsquash identisch.

    oc get pods

  4. Melden Sie sich beim Pod an.

    oc exec -it mypod /bin/bash

  5. Überprüfen Sie, ob für den Mountpfad die root-Berechtigungen definiert sind.

    root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .

    Diese Ausgabe zeigt, dass die UID in der ersten Zeile nun gehört ( root anstelle von nobody).

  6. Wenn die Benutzer-ID nobody gehört, beenden Sie den Pod und starten Sie die Workerknoten Ihres Clusters erneut. Warten Sie, bis der Warmstart der Knoten abgeschlossen ist.

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. Wiederholen Sie die Schritte 4 und 5, um die Berechtigungen zu überprüfen.