WP-Stateless プラグインを利用するための Cloud Storage (GCS) 権限設定
この記事で説明する内容は、以下の記事で説明した WP-Stateless プラグインを利用するための Google Cloud Storage に対する権限設定の補足説明です。元記事が長くなったため、権限設定に特化して分離しました。
WP-Stateles プラグインは、WordPress にアップロードする画像ファイルをオブジェクトストレージにも格納するためのプラグインです。
また、WP-Stateless に限った内容ではなく、Cloud Storage におけるややこしい権限設定「レガシーの有無って何ナノ?」といった点についても一部説明しています。
WP-Stateless に関する元記事はこちら。
この記事の要旨
結論として伝えたいことは以下の通りです。
- オブジェクトへの「アクセス制御」設定は、原則はGCPが推奨する「均一」でOK。ただしプラグインなどのクライアントの都合によっては「きめ細かい管理」にしないと動かないので注意しよう
- Cloud Storage バケットの「一般公開」を目的とした場合、
allUsers
に対してストレージのレガシーオブジェクト読み取り
の権限を設定しよう - サービスアカウントに与える権限は
Storage オブジェクト管理者
権限およびStorage レガシー バケット読み取り
権限の2つを与えて権限を最小化しよう
以下、詳細を説明します。
Cloud Storage バケットの作成における注意点
バケット名は何でもOKです。
但し、将来的に独自ドメインを割り当てることを考えている場合は、その独自ドメイン形式のバケット名を作成します(例えば、 image.example.com
)。このとき、ドメイン名のバケットを作成するためにはあなたがそのドメインの所有者であることを証明する必要があります。定番の Google Search Console にドメインを設定しておくのがお手軽でお勧めです。
Cloud Storage では Search Console を使用してドメインの所有権を確認します。
バケット作成時のアクセス制御設定
バケット作成時にこのような画面が表示されます。
- GCPドキュメントでは「均一」を推奨している
- 「均一」の方が一律設定なので考え方がシンプルでわかりやすく、権限付与誤りの事故も少ないはず
ということで「均一」を選びがちだと思います。
しかし WP-Stateles を使ううえでは「きめ細かい管理」にしないと動きません。厳密には、WP-Stateless の動作モードが複数あって「Stateless モードに限っては均一でも動いた」という点が厄介な事情がありますが詳細は割愛します。とにかく WP-Stateles モードを制限なく活用したい場合は「きめ細かい管理」でバケットを作成するようにしましょう(2022年1月現在)。
WP-Stateless 以外のアプリケーションを利用している場合も、アプリケーションの仕様によりますので注意してみてください。
Cloud Storage バケットへの一般公開の権限設定
GCPのドキュメントに記載の通りなのですが、微妙にややこしい点があります。
https://cloud.google.com/storage/docs/access-control/making-data-public?hl=ja#buckets
読み取りに関する権限その1
読み取りに関する権限その2
- Storage オブジェクト閲覧者
- ストレージのレガシーオブジェクト読み取り
どちらも似たような権限なので悩みます。
「レガシー」と書かれると古臭いから避けたほうがいい印象になります。ですがドキュメントにある通り、「レガシー」にしないとバケット内のオブジェクト一覧が表示されてしまいます。理由がなければ積極的に公開する必要はないでしょうから拒否しておくのがいいと思います。Apacheの設定をしたことがある方であれば Options -Indexes
と設定するようなイメージですね。
- [新しいプリンシパル] フィールドに「
allUsers
」と入力します。- [ロールを選択] プルダウンで [Cloud Storage] サブメニューを選択し、[ストレージ オブジェクト閲覧者] オプションをクリックします。
注:
roles/storage.objectViewer
には、バケット内のオブジェクトを一覧表示する権限があります。リスティングを公開しない場合は、[roles/storage.legacyObjectReader](https://cloud.google.com/storage/docs/access-control/iam-roles?hl=ja#legacy-roles)
を使用します。
「ストレージのレガシーオブジェクト読み取り」を設定した場合の一覧表示:拒否されている
サービスアカウントに付与する権限
何らかのアプリやクライアントが Cloud Storage にアクセスする必要がある場合、多くの場合はその用途専用のサービスアカウントを作成することになります。アカウントに対しての権限付与は最小限にすることがクラウドアーキテクチャの基本原則ですので、しっかり設定しておきましょう。
楽だからといって過剰な権限を付与すると、いざ事故が発生したときに取り返しのつかないことになります。
WP-Stateless プラグインにおいては、マニュアルによるとサービスアカウントには Storage 管理者権限
を付与するように説明されています。
Click on “Add members” and type “wp-stateless” in Input field. GCP will autocomplete this name with full IAM email. Select this email. In dropdown “Select a role”, select “Storage Admin”. Click on “Save”.
「Storage 管理者」権限を与えてしまうと WP-Stateless が必要とするバケット以外のバケットに対しても読み書き権限が付与されてしまうので、少々気持ち悪く感じます。マニュアルよりも小さい権限の設定を試みました。結果、
- Storage オブジェクト管理者
- Storage レガシー バケット読み取り
の2つの権限を付与すればOKです。
前提として、ここでは自身が手動でバケットを作成して準備しておくことを想定しています。もし WP-Stateless プラグインにバケットの自動作成をさせたい場合はバケット作成の権限が必要でしょう(なお、WP-Stateless によるバケット作成機能があるかは未確認です。自動設定機能を利用する際に用いるのかもしれません)。
「ストレージ管理者」はバケット作成や削除ができてしまいます。一方で、「ストレージオブジェクト管理者」であればオブジェクト操作に対する全権限を与えつつもバケットに対する権限が無いので、指定したバケット内のオブジェクトに限ってのみ全権限を与えることが可能です。
役割 | バケット作成 | バケット削除 | ファイル作成 | ファイル閲覧 |
---|---|---|---|---|
ストレージ管理者roles/storage.admin |
◯ | ◯ | ◯ | ◯ |
ストレージオブジェクト管理者 roles/storage.objectAdmin |
× | × | ◯ | ◯ |
ストレージオブヘクトの作成者 roles/storage.objectCreator |
× | × | ◯ | × |
ストレージオブジェクト閲覧者 roles/storage.objectViewer |
× | × | × | ◯ |
引用 https://cloud.google.com/storage/docs/access-control/iam-roles?hl=ja
一見すると「ストレージオブジェクト管理者」だけでも良さそうに見えるのですが、実際のところはエラーが生じます。
発生する WP-Stateless のエラー
Error Getting Bucket Region - There was an error attempting to get the region of the bucket XXXX: … 中略 … service-account does not have
storage.buckets.get
access to the Google Cloud Storage bucket. … 中略 … readson: forbidden
「ストレージオブジェクト管理者」のみでは、指定したバケットさえも参照できない状態にあるのだと思います。よって、「Storage レガシー バケット読み取り」権限を付与することでバケットに対する参照権限を追加しています。バケットの Write 権限を与えるよりは若干マシかと思います。
引用 — レガシーバケット関連の権限 https://cloud.google.com/storage/docs/access-control/iam-roles?hl=ja
まとめ
WordPreses で画像データをオブジェクトストレージに格納するためのプラグイン WP-Stateless を事例にした、Cloud Storage への権限付与に関する説明をしました。
WP-Stateless に限らず、Cloud Storage を利用するアプリケーションにおいては応用可能な考え方だと思いますので参考にしてください。