4.11.3. NFS ボリュームのセキュリティー
このセクションでは、一致するパーミッションや SELinux の考慮点を含む、NFS ボリュームのセキュリティーについて説明します。ユーザーは、POSIX パーミッションやプロセス UID、補助グループおよび SELinux の基礎的な点を理解している必要があります。
開発者は、Pod 定義の volumes セクションで、PVC を名前で参照するか、または NFS ボリュームのプラグインを直接参照して NFS ストレージを要求します。
NFS サーバーの /etc/exports ファイルにはアクセス可能な NFS ディレクトリーが含まれています。ターゲットの NFS ディレクトリーには、POSIX の所有者とグループ ID があります。OpenShift Container Platform NFS プラグインは、同じ POSIX の所有者とエクスポートされる NFS ディレクトリーにあるパーミッションを使って、コンテナーの NFS ディレクトリーをマウントします。ただし、コンテナーは NFS マウントの所有者と同等の有効な UID では実行されません。 これは期待される動作です。
ターゲットの NFS ディレクトリーが NFS サーバーに表示される場合を例に取って見てみましょう。
$ ls -lZ /opt/nfs -d
出力例
drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0 /opt/nfs
$ id nfsnobody
出力例
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
次に、コンテナーは SELinux ラベルに一致し、ディレクトリーにアクセスするために UID の 65534、nfsnobody 所有者、または補助グループの 5555 のいずれかで実行される必要があります。
所有者 ID 65534 は一例として使用されています。NFS の root_squash が root、uid 0 を nfsnobody、uid 65534 にマップしても、NFS エクスポートは任意の所有者 ID を持つことができます。所有者 65534 は NFS エクスポートには必要ありません。
4.11.3.1. グループ ID
NFS アクセスに対応する際の推奨される方法として、補助グループを使用することができます (NFS エクスポートのパーミッションを変更するオプションがないことを前提としています)。OpenShift Container Platform の補助グループは共有ストレージに使用されます (例: NFS)。これとは対照的に、iSCSI などのブロックストレージは、Pod の securityContext で fsGroup SCC ストラテジーと fsGroup の値を使用します。
永続ストレージへのアクセスを取得するには、通常はユーザー ID ではなく、補助グループ ID を使用することが推奨されます。
ターゲット NFS ディレクトリーの例で使用したグループ ID は 5555 なので、Pod は、supplementalGroups を使用してグループ ID を Pod の securityContext 定義の下で定義することができます。以下に例を示します。
spec:
containers:
- name:
...
securityContext: 1
supplementalGroups: [5555] 2
Pod の要件を満たすカスタム SCC が存在しない場合、Pod は restricted SCC に一致する可能性があります。この SCC では、supplementalGroups ストラテジーが RunAsAny に設定されています。 これは、指定されるグループ ID は範囲のチェックなしに受け入れられることを意味します。
その結果、上記の Pod は受付をパスして起動します。しかし、グループ ID の範囲をチェックすることが望ましい場合は、カスタム SCC の使用が推奨されます。カスタム SCC は、最小および最大のグループ ID が定義され、グループ ID の範囲チェックが実施され、グループ ID の 5555 が許可されるように作成できます。
カスタム SCC を使用するには、まずこれを適切なサービスアカウントに追加する必要があります。たとえば、Pod 仕様に指定がない場合には、指定されたプロジェクトで default サービスアカウントを使用します。
