Warum kann ich keinen Benutzer ohne Rootberechtigung zum permanenten Speicher hinzufügen?

Klassische Infrastruktur

Nicht-Root-Benutzer können auch nach der Konfiguration der Zugriffsrechte nicht in den Dateispeicher schreiben.

Nachdem Sie Benutzerzugriff ohne Rootberechtigung zu persistentem Speicher hinzugefügt oder ein Helm-Diagramm mit einer angegebenen Benutzer-ID ohne Rootberechtigung bereitgestellt haben, kann der Benutzer nicht in den angehängten Speicher schreiben.

Ihre App-Bereitstellung oder Helm Diagrammkonfiguration gibt den Sicherheitskontext für die fsGroup (Gruppen-ID) und runAsUser (Benutzer-ID) des Pods an. Im Allgemeinen legt der Standardsicherheitskontext eines Pods runAsNonRoot fest, sodass der Pod nicht als Rootbenutzer ausgeführt werden kann. Da die Einstellung fsGroup nicht für gemeinsam genutzten Speicher wie NFS-Dateispeicher konzipiert ist, wird die Einstellung fsGroup nicht unterstützt und die Einstellung runAsUser wird automatisch auf 2020 gesetzt. Diese Standardeinstellungen lassen nicht zu, dass andere Benutzer ohne Rootberechtigung in den angehängten Speicher schreiben.

Problemlösung

Um einem Nicht-Root-Benutzer den Lese- und Schreibzugriff auf ein Dateispeichergerät zu ermöglichen, müssen Sie eine zusätzliche Gruppenkennung in einer Speicherklasse zuweisen, auf diese Speicherklasse in der PVC verweisen und den Sicherheitskontext des Pods mit einem runAsUser-Wert festlegen, der automatisch zur zusätzlichen Gruppenkennung hinzugefügt wird. Wenn Sie der zusätzlichen Gruppen-ID Lese- und Schreibzugriff auf den Dateispeicher erteilen, erhält jeder Benutzer ohne Rootberechtigung, der zu dieser Gruppen-ID gehört (also auch Ihr Pod) Zugriff auf den Dateispeicher.

Sie können eine der mitgelieferten gid Speicherklassen verwenden oder eine eigene Speicherklasse erstellen, um Ihre eigene zusätzliche Gruppenkennung zu definieren.

Die Zuordnung einer zusätzlichen Gruppen-ID für einen Benutzer ohne Rootberechtigung einer Dateispeichereinheit wird nur für Cluster mit einzelner Zone unterstützt und kann nicht in Clustern mit mehreren Zonen verwendet werden.

Wählen Sie eine der angegebenen gid-Speicherklassen aus, um die Standardgruppen-ID 65531 dem Benutzer ohne Rootberechtigung zuzuordnen, der den Dateispeicher lesen und in den Dateispeicher schreiben können soll. Wenn Sie eine angepasste Gruppen-ID zuweisen möchten, erstellen Sie eine YAML-Datei für eine angepasste Speicherklasse. Geben Sie den Parameter gidAllocate: "true" in die YAML-Datei für Ihre Speicherklasse ein und definieren Sie die Gruppen-ID im Parameter gidFixed.

Beispiel-Speicherklassen für die Zuweisung der Standard-Gruppen-ID 65531:
- ibmc-file-bronze-gid
- ibmc-file-silver-gid
- ibmc-file-gold-gid
Beispiel für eine benutzerdefinierte Speicherklasse zur Angabe einer anderen Gruppen-ID:
```
apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: ibmc-file-bronze-gid-custom
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  mountOptions: nfsvers=4.1,hard
  billingType: "hourly"
  reclaimPolicy: "Delete"
  classVersion: "2"
  gidAllocate: "true"
  gidFixed: "65165"
```
Um die Speicherklasse in Ihrem Cluster zu erstellen, führen Sie den Befehl kubectl apply -f storageclass.yaml aus.

Erstellen Sie für Ihren PVC eine YAML-Datei mit Verwendung der erstellten Speicherklasse.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: gid-pvc
  labels:
    billingType: "monthly"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
  storageClassName: ibmc-file-bronze-gid

Erstellen Sie die PVC in Ihrem Cluster.
```
kubectl apply -f pvc.yaml
```

Warten Sie einige Minuten, bis der Dateispeicher bereitgestellt wurde und der PVC in den Status Bound gewechselt hat.

Wenn Sie den PVC in einem Multizonen-Cluster erstellt haben, bleibt der PVC im Zustand pending.

kubectl get pvc

Beispielausgabe:

NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS           AGE
gid-pvc   Bound    pvc-5e4acab4-9b6f-4278-b53c-22e1d3ffa123   20Gi       RWX            ibmc-file-bronze-gid   2m54s

Erstellen Sie für Ihre Bereitstellung eine YAML-Datei, die den erstellten PVC anhängt. Geben Sie im Feld spec.template.spec.securityContext.runAsUser die Benutzer-ID ohne Rootberechtigung an, die Sie verwenden möchten. Diese Benutzer-ID wird automatisch zur zusätzlichen Gruppen-ID hinzugefügt, die in der Speicherklasse definiert ist, um Lese- und Schreibzugriff auf den Dateispeicher zu erhalten.

Beispiel für die Erstellung einer node-hello Bereitstellung:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gid-deployment
  labels:
    app: gid
spec:
  selector:
    matchLabels:
      app: gid
  template:
    metadata:
      labels:
        app: gid
    spec:
      containers:
      - image: gcr.io/google-samples/node-hello:1.0
        name: gid-container
        volumeMounts:
        - name: gid-vol
          mountPath: /myvol
      securityContext:
        runAsUser: 2020
      volumes:
      - name: gid-vol
        persistentVolumeClaim:
          claimName: gid-pvc

Erstellen Sie die Bereitstellung in Ihrem Cluster.
```
kubectl apply -f deployment.yaml
```

Vergewissern Sie sich, dass der Pod den Status Running aufweist.

kubectl get pods

Beispielausgabe:

NAME                              READY   STATUS    RESTARTS   AGE
gid-deployment-5dc86db4c4-5hbts   2/2     Running   0          69s

Melden Sie sich bei Ihrem Pod an.
```
kubectl exec <pod_name> -it -- bash
```

Lese- und Schreibberechtigungen für den Benutzer ohne Rootberechtigung überprüfen

Listen Sie die Benutzer-ID und die Gruppen-IDs für den aktuellen Benutzer im Pod auf. Die Konfiguration ist korrekt, wenn Ihre Benutzer-ID ohne Rootberechtigung als uid aufgelistet ist und die zusätzliche Gruppen-ID, die Sie in Ihrer Speicherklasse definiert haben, unter groups aufgeführt ist.
```
id
```
Beispielausgabe:
```
uid=2020 gid=0(root) groups=0(root), 65531
```
Listen Sie die Berechtigungen für Ihr Datenträgermountverzeichnis auf, das Sie in Ihrer Bereitstellung definiert haben. Die Konfiguration ist korrekt, wenn die zusätzliche Gruppen-ID, die Sie in Ihrer Speicherklasse definiert haben, mit Lese- und Schreibberechtigungen für Ihr Datenträgermountverzeichnis aufgelistet wird.
```
ls -l /<volume_mount_path>
```
Beispielausgabe:
```
drwxrwxr-x 2 nobody 65531 4096 Dec 11 07:40 .
drwxr-xr-x 1 root   root  4096 Dec 11 07:30 ..
```

Erstellen Sie eine Datei in Ihrem Mountverzeichnis.

echo "Able to write to file storage with my non-root user." > /myvol/gidtest.txt

Listen Sie die Berechtigungen für die Dateien in Ihrem Datenträgermountverzeichnis auf.
```
ls -al /myvol/
```
Beispielausgabe:
```
drwxrwxr-x 2 nobody      65531 4096 Dec 11 07:40 .
drwxr-xr-x 1 root        root  4096 Dec 11 07:30 ..
-rw-r--r-- 1 2020   4294967294   42 Dec 11 07:40 gidtest.txt .
```
In Ihrer CLI-Ausgabe ist die Benutzer-ID ohne Rootberechtigung mit Lese- und Schreibzugriff auf die von Ihnen erstellte Datei aufgeführt.
Verlassen Sie den Pod.
```
exit
```

Wenn Sie das Eigentumsrecht für den Mountpfad in einen anderen Wert als nobody ändern müssen, finden Sie weitere Informationen unter App schlägt fehl, wenn ein Benutzer ohne Rootberechtigung Eigner des NFS-Dateispeichermountpfads ist.