概要
Cloudflare Pagesは、GitHubとつなぐだけで静的サイトを公開できます。便利な一方で、最初の状態のままでは、production branchへのpushがそのまま本番反映になります。
会社サイトやサービスページでは、これは少し怖い運用です。文言修正、プライバシーポリシーの追加、ページ構成の変更も、確認を挟まず公開されてしまうからです。
そこで今回は、mainを本番用、devを開発確認用に分け、Preview deploymentをCloudflare AccessとGoogle認証で保護する形にしました。
devブランチを作る
まず、ローカルで開発用ブランチを作ります。
git switch -c dev
git push -u origin devこれでGitHub側にもdevブランチが作られます。Cloudflare Pagesでは、Production branch以外のブランチをPreview deploymentとして扱えます。
設定によっては、devにpushした時点でPreviewが自動作成されます。今回も、devをpushしただけでCloudflare側にPreview deploymentが作成されました。
mainとdevを分ける
Cloudflare Pages側では、Production branchがmainのままになっているか確認します。本番用の独自ドメインも、mainに紐づけたままにします。
一方で、devは*.pages.devのPreview URLで確認します。作業の流れは、devで編集、Previewで確認、問題がなければmainへ反映、という形です。
この分け方にすると、本番サイトを直接触らずに済みます。記事追加やサービスページ修正のたびに、今pushしたら公開されるのかを気にしなくてよくなります。
Previewを保護する
Preview URLは、何もしないと外部から見える場合があります。未公開ページや確認中の文言を見せたくない場合は、Cloudflare Accessで保護します。
Cloudflare Zero TrustでAccessアプリ、またはPages側のPreview保護を設定し、見られる人をメールアドレスで絞ります。
Allow
Emails = [email protected]注意点は、Previewだけを保護するのか、*.pages.devや独自ドメインも含めて保護するのかです。本番URLまでログイン必須にしないよう、設定後に必ず確認します。
Google認証を追加する
Cloudflare AccessではOne-time PINも使えます。ただ、Previewを見るたびにメールでPINを受け取り、入力するのは手間です。
そこでGoogle認証を追加します。Google CloudでOAuthクライアントを作り、Cloudflare Accessのcallback URLをリダイレクトURIに設定します。
https://time7.cloudflareaccess.com/cdn-cgi/access/callbackCloudflare側で聞かれる「アプリID」はGoogle CloudのClient IDです。「アプリシークレット」はClient secretです。メールクレームは、通常はemailのままで構いません。
One-time PINを残す
Google認証を追加しても、One-time PINを保険として残す運用はできます。普段はGoogleでログインし、Google認証まわりに問題が起きた時だけメールPINを使う形です。
ただし、Access policyの作り方には注意が必要です。One-time PINというログイン方法だけを許可条件にすると、意図せず広く開いてしまう可能性があります。
安全に使うなら、まず許可するメールアドレスやメールドメインを絞ります。ログイン方法ではなく、誰を許可するかを先に決めるのが実務上のポイントです。
最後に確認すること
設定後は、Preview URLがCloudflare Accessへリダイレクトされるかを確認します。ログインなしで未公開ページが見えるなら、保護範囲を見直します。
同時に、本番URLがログインなしで表示されるかも確認します。本番までAccess配下に入れてしまうと、公開サイトとして機能しなくなります。
今回の確認では、Preview URLはCloudflare Accessへリダイレクトされ、本番URLは通常通り公開状態でした。小さな静的サイトでも、この確認は省かない方が安全です。
まとめ
Cloudflare Pagesは簡単に公開できるぶん、本番と確認環境の境目が曖昧になりやすいサービスです。
本番はmain、開発確認はdev、PreviewはGoogleログイン付き。この分け方を最初に作っておくと、日々の修正を安心して進められます。
静的サイトでも、会社サイトやサービスページであれば確認環境は必要です。本番直デプロイを避けるだけで、公開前の判断と修正の余裕がかなり変わります。