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

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

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

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

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

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

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

1. 提供されている gid ストレージ・クラスのいずれかを選択して、デフォルトのグループ 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