Perché non posso aggiungere l'accesso utente non root all'archiviazione persistente?

Infrastrutture classiche

Gli utenti non root non possono scrivere sui file di archiviazione anche dopo aver configurato le autorizzazioni di accesso.

Dopo aver aggiunto l'accesso di un utente non root allo storage persistente o aver distribuito un grafico Helm con un ID utente non root specificato, l'utente non può scrivere sullo storage montato.

La configurazione del deployment dell'applicazione o del grafico Helm specifica il contesto di sicurezza per il pod fsGroup (ID gruppo) e runAsUser (ID utente). Generalmente, il contesto di sicurezza predefinito di un pod imposta runAsNonRoot in modo che il pod non possa essere eseguito come utente root. Poiché l'impostazione fsGroup non è destinata per l'archiviazione condivisa come ad esempio l'archiviazione file NFS, l'impostazione fsGroup non è supportata e l'impostazione runAsUser viene automaticamente impostata su 2020. Queste impostazioni predefinite non consentono ad altri utenti non root di scrivere sullo storage montato.

Risolvere il problema

Per consentire a un utente non root l'accesso in lettura e scrittura a un dispositivo di archiviazione file, è necessario allocare un ID di gruppo supplementare in una classe di archiviazione, fare riferimento a questa classe di archiviazione nel PVC e impostare il contesto di sicurezza del pod con un valore runAsUser che viene aggiunto automaticamente all'ID di gruppo supplementare. Quando concedi all'ID gruppo supplementare l'accesso in lettura e scrittura all'archiviazione file, a tutti gli utenti non root che appartengono all'ID gruppo, incluso il tuo pod, viene concesso l'accesso all'archiviazione file.

È possibile utilizzare uno dei siti gid classi di stoccaggio o creare una propria classe di archiviazione per definire il proprio ID di gruppo supplementare.

L'assegnazione di un ID di gruppo supplementare per un utente non root di un dispositivo di archiviazione file è supportata solo per cluster a zona singola e non può essere utilizzata in cluster multizona.

Seleziona una delle classi di archiviazione gid fornite per assegnare l'ID gruppo predefinito 65531 al tuo utente non root che desideri leggere e scrivere nella tua archiviazione file. Se vuoi assegnare un ID gruppo personalizzato, crea un file YAML per una classe di archiviazione personalizzata. Nel tuo file YAML della classe di archiviazione personalizzata, includi il parametro gidAllocate: "true" e definisci l'ID gruppo nel parametro gidFixed.

Esempio di classi di memorizzazione per l'assegnazione dell'ID di gruppo predefinito 65531:
- ibmc-file-bronze-gid
- ibmc-file-silver-gid
- ibmc-file-gold-gid
Esempio di classe di archiviazione personalizzata per specificare un ID di gruppo diverso:
```
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"
```
Per creare la classe di archiviazione nel tuo cluster, esegui kubectl apply -f storageclass.yaml.

Crea un file YAML per la tua PVC che utilizza la classe di archiviazione che hai creato.

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

Crea la PVC nel tuo cluster.
```
kubectl apply -f pvc.yaml
```

Attendi alcuni minuti che venga eseguito il provisioning dell'archiviazione file e che venga modificato lo stato della PVC con Bound.

Se il PVC è stato creato in un cluster multizona, il PVC resta nello stato pending.

kubectl get pvc

Output di esempio:

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

Crea un file YAML per la tua distribuzione che monta la PVC che hai creato. Nel campo spec.template.spec.securityContext.runAsUser, specifica l'ID utente non root che vuoi utilizzare. Questo ID utente viene automaticamente aggiunto all'ID gruppo supplementare definito nella classe di archiviazione per ottenere l'accesso in lettura e scrittura all'archiviazione file.

Esempio di creazione di un'installazione client node-hello:

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

Crea la distribuzione nel tuo cluster.
```
kubectl apply -f deployment.yaml
```

Verifica che il tuo pod sia in uno stato Running.

kubectl get pods

Output di esempio:

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

Accedi al tuo pod.
```
kubectl exec <pod_name> -it -- bash
```

Verifica dei permessi di lettura e scrittura per l'utente non-root

Elenca l'ID utente e gli ID gruppo per l'utente corrente all'interno del pod. La configurazione è corretta se il tuo ID utente non root viene elencato come uid e l'ID gruppo supplementare definito nella tua classe di archiviazione viene elencato in groups.
```
id
```
Output di esempio:
```
uid=2020 gid=0(root) groups=0(root), 65531
```
Elenca le autorizzazioni per la tua directory di montaggio del volume definita nella tua distribuzione. La configurazione è corretta se l'ID gruppo supplementare definito nella tua classe di archiviazione viene elencato con le autorizzazioni di lettura e scrittura nella tua directory di montaggio del volume.
```
ls -l /<volume_mount_path>
```
Output di esempio:
```
drwxrwxr-x 2 nobody 65531 4096 Dec 11 07:40 .
drwxr-xr-x 1 root   root  4096 Dec 11 07:30 ..
```

Crea un file nella tua directory di montaggio.

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

Elenca le autorizzazioni per i file nella tua directory di montaggio del volume.
```
ls -al /myvol/
```
Output di esempio:
```
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 .
```
Nel tuo output della CLI, l'ID utente non root viene elencato con l'accesso in lettura e scrittura al file che hai creato.
Esci dal tuo pod.
```
exit
```

Se devi modificare la proprietà del percorso di montaggio da nobody, vedi L'applicazione genera un errore quando un utente non root possiede il percorso di montaggio dell'archiviazione file NFS.