NFS ファイル・ストレージ許可のグループ ID エラーでアプリが失敗するのはなぜですか?

ファイル・ストレージ・グループのIDに関するアクセス権限エラーのトラブルシューティングを行います。

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

NFS ストレージの作成またはクラスターへの既存のストレージの追加を行った後に、アプリのコンテナー・デプロイメントが失敗します。 グループ ID (GID) エラー・メッセージが表示されます。

ユーザーとユーザー ID (UID) が指定されていないイメージからコンテナーを作成する場合、Dockerfile 内のすべての命令は、デフォルトでコンテナー内の root ユーザー (UID: 0) によって実行されます。

ただし、NFS ファイル共有をコンテナーにマウントする場合、コンテナー内のユーザー ID 0 は、NFS ホスト・システム上のユーザー ID nobody にマップされます。 このため、ボリューム・マウント・パスは、nobody ではなく、ユーザー ID root によって所有されます。 このセキュリティー機能は、root squash とも呼ばれます。 root squash は、実際の NFS ホスト・ファイル・システムでユーザー ID に root 許可を付与せずにコンテナーをマウントすることにより、NFS 内のデータを保護します。

Kubernetes を使用し DaemonSet これにより、 NFSv4 ファイル共有について、すべてのワーカーノード上のストレージマウントパスに対してルート権限が有効になります。

ボリューム・マウント・パスで root 許可を使用できるようにするには、ワーカー・ノードで configmap を設定する必要があります。 configmap は、ユーザー ID nobody を NFS ホスト・システムからコンテナー内の root ユーザー ID 0 にマップします。 このプロセスは、no root squash とも呼ばれます。 すべてのワーカー・ノードを更新する有効な方法は、クラスター内のすべてのワーカー・ノードで指定されたポッドを実行するデーモン・セットを使用することです。 この場合、デーモン・セットによって制御されるポッドは、各ワーカー・ノードを更新して、ボリューム・マウント・パスに対する root 許可を有効にします。

デプロイメントは、デーモン・セット・ポッドを特権モードで実行できるように構成されています。これは、ホスト・ファイル・システムにアクセスするために必要です。 ポッドを特権モードで実行すると、セキュリティー・リスクが発生するため、このオプションの使用には注意が必要です。

デーモン・セットの実行中に、クラスターに追加された新しいワーカー・ノードが自動的に更新されます。

始める前に

以下のステップを実行します。

  1. norootsquash のデーモンセット ・デプロイメントのYAMLファイルをコピーします。

  2. norootsquash デーモン・セットのデプロイメントを作成します。

    oc apply -f norootsquash.yaml

  3. ストレージ・ボリュームがマウントされるポッドの名前を取得します。 このポッドは、norootsquash ポッドと同じではありません。

    oc get pods

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

    oc exec -it mypod /bin/bash

  5. マウント・パスへの許可が root であることを確認します。

    root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .

    この出力結果から、1行目のUIDの所有者が、 nobody から root に変更されたことがわかります。

  6. UID が nobody によって所有されている場合は、ポッドを終了して、クラスターのワーカー・ノードをリブートします。 ノードがリブートされるまで待ちます。

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. ステップ 4 および 5 を繰り返し、許可を検証します。