このページでは、NFS クライアントを接続する方法について説明します。
始める前に
Linux ディストリビューションのタイプに基づいて NFS クライアント ツールをインストールし、クライアントを準備します。
Red Hat
次のコマンドを実行します。
sudo yum install -y nfs-utils
SuSe
次のコマンドを実行します。
sudo yum install -y nfs-utils
Debian
次のコマンドを実行します。
sudo apt-get install nfs-common
Ubuntu
次のコマンドを実行します。
sudo apt-get install nfs-common
エクスポート ポリシーを使用したボリューム アクセス制御
NFSv3 と NFSv4.1 のボリューム アクセス制御は、クライアントの IP アドレスに基づいています。ボリュームのエクスポート ポリシーには、最大 20 個のエクスポート ルールが含まれています。各ルールは、ボリュームのマウントを許可する許可されたクライアントを定義する IP またはネットワーク CIDR のカンマ区切りリストです。ルールでは、クライアントが持つアクセスの種類（読み取りと書き込み、読み取り専用など）も定義します。
次のタブを使用して、NFS バージョンに基づくポリシーを確認します。
Kerberos を使用しない NFS
Kerberos を使用しないすべての NFS バージョンは、AUTH_SYS セキュリティ フレーバーを使用します。このモードでは、信頼できるクライアントのみを許可し、ユーザー ID とグループ ID の完全性を確保できるように、エクスポート ルールを厳密に管理する必要があります。
セキュリティ対策として、NFS サーバーは UID=0（root）の NFS 呼び出しを UID=65534（匿名）に自動的にマッピングします。この UID=65534 には、ファイル システムに対する権限が制限されています。詳細については、ユーザー ID の圧縮をご覧ください。
Kerberos を使用した NFSv4.1
Kerberos を使用する NFSv4.1 は、エクスポート ポリシーと Kerberos を使用した追加の認証を使用してボリュームにアクセスします。次の対象に適用するエクスポート ルールを構成できます。
Kerberos のみ（
krb5）Kerberos 署名（
krb5i）Kerberos のプライバシー（
krb5p）
エクスポート ポリシーのベスト プラクティス
エクスポート ポリシーには、次のベスト プラクティスをおすすめします。
エクスポート ルールを最も具体的なものから最も具体的でないものまで順に並べます。
特定のクライアントや信頼できるクライアントを含む CIDR など、信頼できるクライアントにのみエクスポートします。
ルートアクセスを信頼できる少数の管理クライアントに制限します。
| ルール | 許可されたクライアント | アクセス | ルートアクセス権 | 説明 |
|---|---|---|---|---|
| 1 | 10.10.5.3、
10.10.5.9 |
読み取り / 書き込み | オン | 管理クライアント。root ユーザーは root のままで、 のすべてのファイル権限を管理できます。 |
| 2 | 10.10.5.0/24 | 読み取り / 書き込み | オフ | 10.10.5.0/24 ネットワークの他のすべてのクライアントはマウントできますが、root アクセスは nobody にマッピングされます。 |
| 3 | 10.10.6.0/24 | 読み取り専用 | オフ | 別のネットワークがボリュームからデータを読み取ることは許可されますが、書き込みは許可されません。 |
クライアントがボリュームをマウントすると、ファイルレベルのアクセスによってユーザーが実行できる操作が決まります。詳細については、UNIX スタイルのボリュームの NFS ファイルレベルのアクセス制御をご覧ください。
ユーザー ID の統合
NFS エクスポート ポリシーは、ユーザー ID とグループ ID のスクワッシュの制御を提供します。これにより、セキュリティ上の理由から、ユーザー ID とグループ ID を匿名ユーザー ID に再マッピングできます。
ルート スカッシュ
NFS サーバーは、root ユーザー（UID=0）を nobody（UID=65534）に再マッピングすることでセキュリティを強化します。これにより、root はボリューム上のファイル アクセス権のないユーザーになります。この機能は、ルート スカッシュと呼ばれます。この機能を無効にして root の権限を保持するオプションは、NFS サーバーでは no_root_squash と呼ばれます。
デフォルトでは、エクスポート ポリシーが定義されていないボリュームには、クライアント IP アドレスからアクセスできません。 Google Cloud コンソールでエクスポート ポリシー ルールを作成すると、デフォルトの設定には読み取り / 書き込みアクセス権とルート スカッシュが含まれます。以前は、Google Cloud API、Google Cloud CLI、Terraform で has-root-access パラメータを使用してルート スカッシュを制御できました。has-root-access は引き続き受け付けられますが、squash-mode パラメータに置き換えられました。
ベスト プラクティスとして、信頼できる管理者ホストの root アクセスを有効にし、他のクライアントの root アクセスを無効にする専用のエクスポート ルールを作成します。このルールは、より一般的なルールの前に配置します。
ユーザー ID とグループ ID の圧縮
squash-mode パラメータを使用すると、ユーザー ID とグループ ID の両方を匿名の UID に圧縮できます。これは、公開 SFTP ドロップボックス ディレクトリで役立ちます。このパラメータは has-root-access パラメータも置き換え、API、Google Cloud CLI、Terraform でサポートされています。
squash-mode パラメータは次の値を受け入れます。
no-root-squash: このモードでは、ルートユーザーはルートのままで、nobody（UID=65534）に再マッピングされません。root-squash: この設定により、root ユーザーが nobody に再マッピングされます。all-squash: このオプションは、root を含むすべてのユーザーに匿名アクセスを提供します。すべてのユーザーは、anon-uidパラメータで指定された UID と GID に再マッピングされます。all-squashを使用する場合は、anon-uidも指定し、access-typeをREAD_WRITEに設定する必要があります。
考慮事項
squash mode を含むエクスポート ポリシー ルールについては、次の点を考慮してください。
エクスポート ポリシーでサポートされる
all-squashルールは 1 つのみです。all-squashが有効になっている場合、root ユーザーは匿名にスカッシュされます。これは、no-root-squashを使用する優先度の高いルールでオーバーライドできます。squash-modeスタイルのエクスポート ポリシー ルールがあるボリュームでは、ボリュームのレプリケーションはサポートされていません。Flex サービスレベルの場合、
all-squashはボリュームのルート inode の所有権を自動的に変更しません。これを実現するには、no-root-squashエクスポート ルールを追加して、ルートユーザーがchownを使用してルート inode の所有権を必要な UID に変更できるようにします。has-root-accessパラメータがサポートされています。has-root-accessまたはsquash-modeのどちらかを使用します。両方のパラメータを同時に使用することはできません。
ボリュームを編集する
Google Cloud CLI を使用して、squash-mode でボリュームのエクスポート ポリシーを更新するには、次の操作を行います。
gcloud
squash-mode を使用してエクスポート ポリシーを含むボリュームを更新します。
gcloud netapp volumes update VOLUME_ID \ --project=PROJECT_ID \ --location=LOCATION \ --export-policy=access-type=ACCESS_TYPE,squash-mode=SQUASH_MODE,anon-uid=ANON_UID,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES
次の情報を置き換えます。
VOLUME_ID: ボリュームの ID。PROJECT_ID: ボリュームが存在するプロジェクトの名前。LOCATION: ボリュームのロケーション。ACCESS_TYPE: アクセスタイプはREAD_WRITE、READ_ONLY、READ_NONEのいずれかにする必要があります。SQUASH_MODE: エクスポート ルールは、NO_ROOT_SQUASH、ROOT_SQUASH、ALL_SQUASHのいずれかにする必要があります。ANON_UID: スカッシュする UID 番号。ALLOWED_CLIENTS_IP_ADDRESSES: 許可されているクライアントの IP アドレスまたは範囲のリスト（カンマ区切り）。
エクスポート ポリシー パラメータを繰り返して、複数のルールを含めることができます。
次の例は、エクスポート ポリシーに root-squash ルールと all-squash ルールの両方がある場合を示しています。
gcloud netapp volumes update my_volume --location=us-east4 \ --export-policy=allowed-clients=10.0.1.18,nfsv3=true,access-type=READ_WRITE,squash-mode=NO_ROOT_SQUASH \ --export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000
その他のオプションのフラグの詳細については、ボリューム エクスポート ポリシーに関する Google Cloud SDK のドキュメントをご覧ください。
NFS クライアントのマウント手順
Google Cloud コンソールまたは Google Cloud CLI を使用して NFS クライアントのマウント手順を取得するには、次の操作を行います。
コンソール
Google Cloud コンソールで、[NetApp Volumes] ページに移動します。
[ボリューム] をクリックします。
[さらに表示] をクリックします。
[取り付け手順] を選択します。
Google Cloud コンソールに表示されるマウント手順に沿って操作します。
ワークロードに特定のマウント オプションの要件がない限り、マウント コマンドを特定してマウント オプションを使用します。
NFSv3 のみ: アプリケーションでロックを使用していない場合や、NSM 通信を有効にするようにクライアントを構成していない場合は、
nolockマウント オプションを追加することをおすすめします。
gcloud
ボリュームのマウント手順を検索します。
gcloud netapp volumes describe VOLUME_NAME \ --project=PROJECT_ID \ --location=LOCATION \ --format="value(mountOptions.instructions)"
次の情報を置き換えます。
VOLUME_NAME: ボリュームの名前。PROJECT_ID: ボリュームが存在するプロジェクトの名前。LOCATION: ボリュームのロケーション。
その他のオプション フラグの詳細については、ボリュームに関する Google Cloud SDK のドキュメントをご覧ください。
NFSv4.1 の追加の手順
Flex Unified、Standard、Premium、Extreme のサービスレベルのボリュームで NFSv4.1 を有効にすると、これらのボリュームで NFSv4.2 が自動的に有効になります。マウントするバージョンを指定しない限り、Linux のマウント コマンドは常に使用可能な最新の NFS バージョンをマウントします。NFSv4.1 でマウントする場合は、マウント コマンドで -o vers=4.1 パラメータを使用します。
NFSv3 では、ユーザーとグループは NFSv3 プロトコルで送信されるユーザー ID（UID）とグループ ID（GID）で識別されます。同じ UID と GID が、ボリュームにアクセスするすべてのクライアントで同じユーザーとグループを表すようにすることが重要です。NFSv4 では、セキュリティ ID を使用することで、UID と GID の明示的なマッピングが不要になりました。セキュリティ識別子は <username|groupname>@<full_qualified_domain> 形式の文字列です。セキュリティ ID の例は bob@example.com です。クライアントは、内部で使用される UID と GID をセキュリティ ID に変換してから、NFSv4 リクエストをサーバーに送信する必要があります。サーバーは、受信リクエストのセキュリティ識別子を UID と GID に変換し、レスポンスではその逆の変換を行う必要があります。変換を使用する利点は、すべてのクライアントとサーバーが異なる内部 UID と GID を使用できることです。ただし、すべてのクライアントとサーバーで UID と GID、ユーザー名とグループ名のマッピング リストを維持する必要があるというデメリットがあります。クライアントのマッピング情報は、/etc/passwd や /etc/groups などのローカル ファイル、または LDAP ディレクトリから取得できます。このマッピングの構成は rpc.idmapd によって管理されます。rpc.idmapd はクライアントで実行する必要があります。
NetApp ボリュームでは、LDAP はマッピング情報を提供する必要があります。Active Directory は、サポートされている唯一の RFC2307bis 互換 LDAP サーバーです。NFSv4 で Kerberos を使用する場合、セキュリティ ID は Kerberos プリンシパルを username@DOMAINNAME 形式で保存します。ここで、DOMAINNAME（大文字）はレルム名になります。
数値 ID
名前マッピングを構成せずに NFSv3 の代替として NFSv4 を使用するユーザー向けに、NFSv4 では numeric ID というオプションが導入されました。このオプションは、UID と GID のエンコードされたテキスト文字列をセキュリティ ID として送信します。これにより、ユーザーの構成プロセスが簡素化されます。
クライアント設定を確認するには、次のコマンドを使用します。
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
デフォルト値は Y で、数値 ID が有効になります。NetApp Volumes は数値 ID の使用をサポートしています。
NFS クライアントで rpc.idmapd を構成する
使用する ID またはセキュリティ識別子の種類に関係なく、NFS クライアントで rpc.idmapd を構成する必要があります。始める前にのクライアント ユーティリティのインストール手順に沿って操作した場合は、すでにインストールされているはずですが、実行されていない可能性があります。一部のディストリビューションでは、最初の NFS ボリュームをマウントするときに systemd を使用して自動的に開始します。rpc.idmapd に必要な最小構成は、ドメイン設定を行うことです。それ以外の場合、ユーザー root は UID=65534 or 4294967295 のない nobody として表示されます。
次の手順に沿って、NFS クライアントで rpc.idmapd を構成します。
クライアントで
/etc/idmapd.confファイルを開き、ドメイン パラメータを次のいずれかに変更します。ボリュームで LDAP が有効になっていない場合は、
domain = defaultv4iddomain.com。ボリュームで LDAP が有効になっている場合は、
domain = <FDQN_of_Windows_Domain>。
次のコマンドを実行して、
rpc.idmapdの変更を有効にします。nfsidmap -c
NFSv4.2 のサポート
Flex Unified、Standard、Premium、Extreme の各サービスレベルで、NFSv4.1 がすでに有効になっているボリュームで NFSv4.1 に加えて NFSv4.2 プロトコルがサポートされるようになりました。
NFS ボリュームをマウントすると、Linux の mount コマンドは使用可能な最も高い NFS バージョンを自動的に選択します。vers=4.1 マウント オプションが明示的に指定されていない限り、NFSv4.1 対応ボリュームのマウントはデフォルトで NFSv4.2 になります。
NetApp Volumes は、NFSv4.2 で NFS 拡張属性 xattrs をサポートします。TR-4962 で詳しく説明されている xattrs の使用と制限事項も適用されます。
Linux を LDAP に接続する
NFSv3 拡張グループまたは NFSv4.1 をセキュリティ ID とともに使用している場合は、ストレージ プールに接続された Active Directory を使用して、Active Directory を LDAP サーバーとして使用するように NetApp Volumes を構成しました。
NFS クライアントとサーバー間でユーザー情報を一貫して維持するには、ユーザーとグループの情報に Active Directory を LDAP ネーム サービスとして使用するようにクライアントを構成する必要があります。
次のリソースを使用して LDAP を構成します。
Kerberized NFS を使用する場合は、このセクションで説明したデプロイガイドを使用して LDAP を構成し、クライアントとサーバー間の整合性を確保する必要があります。
次のステップ
複数のストレージ エンドポイントを使用して大容量ボリュームを接続します。