こんにちは、博報堂テクノロジーズの木村です。
Google Cloudでは、Cloud CDNにて署名付きURLを利用することができ、オリジンとしてCloud Storage、Cloud Runなどのバックエンドを指定することができます。しかし、Cloud Storage以外のバックエンドをオリジンに設定するケースについては、公式のマニュアルはあるもののブログ記事などがなく、LLMの回答もズレている回答が多かったため、設定していて引っかかったポイント、特に署名検証の部分についてまとめます。
全体構成
はじめに今回構築した構成を以下に示します。
Cloud StorageとCloud Runの差分
Cloud CDNを利用して署名付きURLを利用する際には、Cloud Storageをバックエンドにする場合もCloud Runなどをバックエンドにする場合にも署名鍵の生成とバックエンドへの署名鍵の設定、署名付きURLへのアクセスについては同じ流れとなります。
差分となるのが署名検証の部分となります。Cloud Storageをバックエンドとする場合、署名検証についてはGoogle Cloud側にて対応されますが、Cloud RunなどCloud Storage以外のサービスをオリジンに設定するケースでは、オリジン側での署名検証はバックエンド側で実施する必要があります。そのため、以下の章では署名検証について説明していきます。
署名検証
この章では、署名検証の際のポイントについて説明していきます。
リクエストが署名されていないときの動作
Cloud Storageをバックエンドに設定した場合とCloud Runなどをバックエンドに設定した場合、署名されていないリクエストの動作が異なります。
Cloud Storageをバックエンドとした場合、キャッシュされていないコンテンツの検証はCloud Storageにて検証され 403 になります。一方 Cloud Run など（Cloud Storage 以外）ではキャッシュされていないコンテンツについては、オリジンで署名検証を実装して拒否する必要があります。
署名されていないリクエストを拒否したい場合はオリジン側で403を返すよう実装します。403を返して署名されていないリクエストをCDNでキャッシュさせないようにすることで、署名されていないリクエストは必ずオリジンに到着し、必ず署名検証プロセスが動くようになります。
署名検証の方法については以下を参考にオリジン側で実装します。
https://docs.cloud.google.com/cdn/docs/using-signed-urls?hl=ja#validate-signed-urls
署名検証時に対象とするURL
署名検証の対象となるURLは x-client-request-url ヘッダを参照する必要があります。リクエストのURLそのものは署名関連のパラメータはURLから削除されます。
署名検証時の検証鍵の取り扱い
署名検証時の検証鍵はbase64でデコードして署名・複合の処理を実施する必要があります。gcloud コマンドで署名生成する際は自動でやってくれるので、Cloud Storageをオリジンにしている場合には、意識しない部分のため、注意が必要です。
まとめ
今回はCloud CDN + Cloud Runにて署名付きURLを利用する際のCloud Storageとの差分である、署名検証に関する部分について主に解説してきました。皆さんの参考になれば幸いです。