Pourquoi ne puis-je pas ajouter un accès utilisateur non root au stockage persistant ?

Infrastructure classique

Après avoir ajouté un accès utilisateur non superutilisateur à un stockage permanent ou déployé un graphique Helm avec un ID utilisateur non superutilisateur spécifié, l'utilisateur ne peut pas écrire dans le stockage monté.

Le déploiement de l'application ou la configuration du graphique Helm spécifie le contexte de sécurité pour le 'fsGroup (ID de groupe) et le 'runAsUser (ID d'utilisateur) du pod. En général, le contexte de sécurité par défaut d'un pod définit runAsNonRoot de sorte que le pod ne puisse pas s'exécuter en tant qu'utilisateur root. Étant donné que le paramètre fsGroup n'est pas conçu pour un stockage partagé tel que le stockage de fichiers NFS, le paramètre fsGroup n'est pas pris en charge et le paramètre runAsUser est automatiquement défini sur 2020. Ces paramètres par défaut ne permettent pas à d'autres utilisateurs non root d'écrire dans le stockage monté.

Pour permettre à un utilisateur non root d'accéder en lecture et en écriture à un périphérique de stockage de fichiers, vous devez attribuer un ID de groupe supplémentaire dans une classe de stockage, faire référence à cette classe de stockage dans le PVC et définir le contexte de sécurité du pod avec une valeur " runAsUser qui est automatiquement ajoutée à l'ID de groupe supplémentaire. Lorsque vous octroyez à l'ID de groupe supplémentaire l'accès en lecture et en écriture au stockage de fichiers, l'accès au stockage de fichiers est octroyé à tout utilisateur non root appartenant à cet ID de groupe, y compris votre pod.

Vous pouvez utiliser l'un des " classes de stockage gid fournis ou créer votre propre classe de stockage pour définir votre propre identifiant de groupe supplémentaire.

L'allocation d'un ID de groupe supplémentaire pour un utilisateur non superutilisateur d'une unité de stockage de fichiers n'est prise en charge que pour les clusters de zone unique et ne peut pas être utilisée dans les clusters multi-zones.

1. Sélectionnez l'une des classes de stockage gid fournies pour affecter l'ID de groupe par défaut 65531 à votre utilisateur non root. Si vous souhaitez affecter un ID de groupe personnalisé, créez un fichier YAML pour une classe de stockage personnalisée. Dans votre fichier YAML de votre classe de stockage personnalisé, incluez le paramètre gidAllocate: "true" et définissez l'ID de groupe dans le paramètre gidFixed.

   Exemples de classes de stockage pour l'affectation de l'ID groupe par défaut 65531.

   • ibmc-file-bronze-gid
   • ibmc-file-silver-gid
   • ibmc-file-gold-gid

   Exemple de classe de stockage personnalisée spécifiant un ID de groupe différent.

   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"
   

   Pour créer la classe de stockage dans votre cluster, exécutez la commande kubectl apply -f storageclass.yaml.

2. Créez un fichier YAML pour votre PVC utilisant la classe de stockage que vous avez créée.

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

3. Créez la PVC dans votre cluster.

   kubectl apply -f pvc.yaml
   

4. Patientez quelques minutes, le temps que le stockage de fichiers soit mis à disposition et que la réservation de volume persistant (PVC) passe à l'état Bound (Bound). Sachez que si vous avez créé la PVC dans un cluster multizone, celle-ci reste à l'état pending (pending).

   kubectl get pvc
   

   Exemple de sortie

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

5. Créez un fichier YAML pour le déploiement qui monte la PVC que vous avez créée. Dans la zone spec.template.spec.securityContext.runAsUser, indiquez l'ID de l'utilisateur non root que vous souhaitez utiliser. Cet ID utilisateur est automatiquement ajouté à l'ID de groupe supplémentaire défini dans la classe de stockage pour obtenir l'accès en lecture et en écriture au stockage de fichiers.

   Exemple de création d'un déploiement 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
   

6. Créez le déploiement dans votre cluster.

   kubectl apply -f deployment.yaml
   

7. Vérifiez que votre pod est à l'état Running.

   kubectl get pods
   

   Exemple de sortie

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

8. Connectez-vous à votre pod.

   kubectl exec <pod_name> -it -- bash