アクセス制御

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

Filestore では、Filestore インスタンスへのアクセス保護に Kerberos がサポートされません。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）を使用してファイルを実行できるため、このシナリオが可能です。

権限の重複

ゾーン（以前は高スケール SSD）とエンタープライズ インスタンスで重複する権限がサポートされるようになりました。

重複する 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 インスタンスでは、重複する権限はサポートされていません。

次のステップ