永続ストレージへの非 root ユーザー・アクセスを追加できないのはなぜですか?

クラシック・インフラストラクチャー

非 root ユーザー ID を指定した状態で、永続ストレージへの非 root ユーザー・アクセスを追加するか、または Helm チャートをデプロイした後、ユーザーはマウントされたストレージに書き込むことができません。

アプリのデプロイメントやHelmチャートの設定では、ポッドの「fsGroup（グループID）と「runAsUser（ユーザーID）の セキュリティコンテキストを指定します。 一般に、ポッドのデフォルト・セキュリティー・コンテキストでは、そのポッドを root ユーザーとして実行できないよう、runAsNonRoot が設定されています。 fsGroup 設定は NFS ファイル・ストレージなどの共有ストレージ用に設計されていないため、fsGroup 設定はサポートされず、runAsUser 設定は自動的に 2020 に設定されます。 これらのデフォルト設定では、他の非 root ユーザーは、マウントされたストレージに書き込むことができません。

非ルート・ユーザにファイル・ストレージ・デバイスへの読み取りと書き込みのアクセスを許可するには、ストレージ・クラスに 補足グループIDを割り当て、PVCでこのストレージ・クラスを参照し、ポッドのセキュリティ・コンテキストに補足グループIDに自動的に追加される「runAsUser 値を設定する必要があります。 ファイル・ストレージに対する読み取りおよび書き込みアクセス権限を補助グループ ID に付与すると、ポッドを含め、そのグループ ID に属するすべての非 root ユーザーに、ファイル・ストレージに対するアクセス権限が付与されます。

提供されている'gid ストレージクラス のいずれかを使用するか、独自のストレージクラスを作成して、独自の補足グループIDを定義することができます。

ファイル・ストレージ・デバイスの非 root ユーザーに対する補足グループ ID の割り振りは、単一ゾーン・クラスターでのみサポートされ、マルチゾーン・クラスターでは実行できません。

1. 提供されている gid ストレージ・クラスの 1 つを選択して、デフォルト・グループ ID 65531 を、ファイル・ストレージに対する読み取り/書き込みを実行させる非 root ユーザーに割り当てます。 カスタム・グループ ID を割り当てる場合は、カスタマイズ・ストレージ・クラス用の YAML ファイルを作成します。 カスタマイズ・ストレージ・クラス YAML ファイルには、gidAllocate: "true" パラメーターを設定し、gidFixed パラメーターにグループ ID を定義してください。

   デフォルトのグループ ID 65531 を割り当てるためのストレージ・クラスの例。

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

   別のグループ 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"
   

   クラスターにストレージ・クラスを作成するには、kubectl apply -f storageclass.yaml を実行します。

2. 作成したストレージ・クラスを使用する PVC の YAML ファイルを作成します。

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

3. クラスター内に PVC を作成します。

   kubectl apply -f pvc.yaml
   

4. ファイル・ストレージがプロビジョニングされ、PVC が「Bound」状況に変わるまで、数分間待ちます。 マルチゾーン・クラスターで作成した PVC は、「pending」状態のまま変わらないことに注意してください。

   kubectl get pvc
   

   出力例

   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. 作成した PVC をマウントするデプロイメントの YAML ファイルを作成します。 spec.template.spec.securityContext.runAsUser フィールドに、使用する非 root ユーザー ID を指定します。 このユーザー ID は、ストレージ・クラスで定義した補助グループ ID に自動的に追加されて、ファイル・ストレージに対する読み取りおよび書き込みアクセス権限を取得します。

   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. クラスター内にデプロイメントを作成します。

   kubectl apply -f deployment.yaml
   

7. ポッドが Running の状況であることを確認します。

   kubectl get pods
   

   出力例

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

8. ポッドにログインします。

   kubectl exec <pod_name> -it -- bash