NFS ファイル・ストレージ許可のグループ 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 許可を有効にします。

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

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

始める前に

• 永続ストレージを作成します。
• Red Hat OpenShift クラスターにアクセスします。

ステップ:

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 .
   

   この出力では、最初の行の UID が root (以前の nobody ではない) によって所有されていることを示しています。

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

   ibmcloud oc worker reboot --cluster <my_cluster> --worker <my_worker1>,<my_worker2>
   

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