このページは Cloud Translation API によって翻訳されました。

アクセス制御

このページでは、Filestore インスタンスへのアクセスを制御する方法について説明します。

NFSv4.1 プロトコルを使用すると、Kerberos を使用して Filestore インスタンスへのアクセスを保護できます。詳細については、サポートされているプロトコルについてをご覧ください。
Linux オプションで NFS アクセスを制御し、IAM（Identity and Access Management）でインスタンスの作成、編集、表示、削除などのインスタンス操作へのアクセスを制御することができます。次のガイドでは、これらの各タスクを完了する方法について説明します。

ファイル共有のエクスポート設定

Filestore のファイル共有には、次のデフォルトの /etc/exports 設定が割り当てられます。

クライアントリスト（ファイル共有への接続が許可されるクライアントを識別）には、Filestore インスタンスに選択した VPC ネットワーク内のすべての内部 IP アドレスが含まれます。内部 IP アドレスは、サブネット範囲に含まれる任意の範囲を指定できます。ただし、クライアントがRFC 1918 以外のサブネット範囲を使用する場合は、IP ベースのアクセス制御を使用して Filestore インスタンスへのアクセス権を明示的に付与する必要があります。
rw オプションが使用されるため、ファイル共有では読み取りオペレーションと書き込みオペレーションの両方が許可されます。
ユーザー ID マッピングオプション no_root_squash が使用されるため、Filestore インスタンスとクライアントの双方で、root ユーザーを含むすべてのユーザーとグループが同じであると想定されます。
他のすべてのオプションでは、/etc/exports のデフォルトが使用されます。

基本階層インスタンス

基本 SSD と基本 HDD のインスタンスでは /config/google-prober というラベルが付いたエクスポートされる共有が作成され、内部プロービングプロセスに役立つように使用されます。これにより、アクセス、耐久性、またはパフォーマンスが検証されます。共有は、前のセクションで説明した設定を使用して、インスタンスの IP アドレスにのみアクセス可能なクライアントリストにエクスポートされます。この共有には、インスタンスでホストされているプローバーまたはインスタンスから発信されたプローバーのみがアクセスでき、インスタンス外からはアクセスできません。インスタンスは、IP ベースのアクセス制御が適用されているかどうかに関係なく、共有をエクスポートします。エクスポートされた共有は、showmount -e コマンドを使用して確認できます。

IP ベースのアクセス制御

これらのエクスポート設定を変更するには、Google Cloud コンソールを使用してアクセス制御ルールを作成するか、インスタンスの作成時に gcloud CLI を使用して JSON 構成ファイルを指定します。詳細については、IP ベースのアクセス制御を構成するをご覧ください。

また、インスタンスを作成した後に、新しいアクセス制御ルールの追加や、既存のアクセス制御ルールの変更を行えます。詳細については、インスタンスの編集をご覧ください。

ファイル共有の権限

Filestore インスタンスを作成する場合、そのインスタンスのファイル共有には rwxr-xr-x のデフォルトの POSIX ファイル権限が設定されます。これらの権限は、Filestore インスタンス上で、接続クライアントの root ユーザーのみにファイル共有への読み取り / 書き込みアクセス権が付与されることを意味します。その他のユーザーにはデフォルトで読み取りアクセスのみが付与されます。クライアントの root ユーザーは権限やオーナーを変更できます。

ファイル共有をマウントする際は、マウントオプションと /etc/fstab 設定を使用して、ファイル共有が書き込み可能であるかどうか、また、ファイルに対して実行可能かどうか確認できます。ファイル共有のマウント後に、chmod や setfacl などの標準の Linux コマンドを使用して、ファイルおよびファイル共有のアクセス権限を設定できます。ベーシックティアのみが setfacl をサポートします。

一貫性のあるアクセス権限を設定する

権限昇格を防ぐため、同じ Filestore インスタンスに接続するすべてのクライアントの各ユーザーには、一貫性のあるアクセス権限を設定することを強くおすすめします。ファイル共有が複数のクライアントにマウントされ、ユーザーが 1 つのクライアントに複数のルート権限を持ち、他にない場合、次の権限昇格のシナリオが考えられます。

ユーザーは、ルートアクセス権を持つクライアントから実行可能ファイルに setuid 属性を設定します。
次にユーザーは、実行可能ファイルをファイル共有にアップロードします。
ユーザーは、少なくとも読み取り権限を持っているクライアントで、アップロードされたファイルを root として実行します。

setuid ビットを使用すると、ファイルのオーナー権限（この場合は root）を使用してファイルを実行できるため、このシナリオが可能です。

重複する権限

ゾーン、リージョン、エンタープライズのインスタンスで重複する権限がサポートされるようになりました。

重複する IP アドレスサブネットに対して個別に 2 つのアクセス制御ルールを定義している場合は、小さい方のサブネットに対して定義されているルールが優先されます。

たとえば、JSON 構成ファイルに IPv4 アドレスのサブネット 10.0.0.0/24 に対する読み取り / 書き込みアクセス権を付与するルールがあり、別のルールで IPv4 アドレスのサブネット 10.0.0.0/28 に対する読み取り専用アクセス権を付与する場合、Filestore では、最初に小さい方のサブネットのルールが認識され、適用されます。次に、定義した IP アドレスサブネットの残りの部分にもう一方のルールが適用されます。この例では、IPv4 アドレス 10.0.0.20 を使用するクライアントに読み取り / 書き込みアクセス権が付与され、10.0.0.12 を使用するクライアントには読み取り専用アクセス権が付与されます。

   {
  "--file-share":
    {
      "capacity": "2048",
      "name": "my_vol",
      "nfs-export-options": [
        {
          "access-mode": "READ_WRITE",
          "ip-ranges": [
            "10.0.0.0/24"
          ],
          "squash-mode": "ROOT_SQUASH",
          "anon_uid": 1003,
          "anon_gid": 1003
        },
         {
          "access-mode": "READ_ONLY",
          "ip-ranges": [
            "10.0.0.0/28"
          ],
          "squash-mode": "NO_ROOT_SQUASH"
        }
      ]
    }
}

一定の制限事項が適用される:

同一の IPv4 サブネットに対する権限の重複はサポートされておらず、エラーが返されます。
基本 SSD インスタンスまたは基本 HDD インスタンスでは、権限の重複はサポートされていません。