GitLab Pagesでは足りない認証・期限管理をどう補うか

できること

GitLab Pagesには、プロジェクトの可視性に連動したAccess Control機能があります。プロジェクトをプライベートに設定し、Pages Access Controlを有効にすると、GitLabにサインインしていないユーザーはPagesにアクセスできなくなります。社内スタッフなど全員がGitLabアカウントを持つ環境では有効な認証手段です。

GitLab CIのスケジュールジョブを使えば、特定の日時にPagesのコンテンツを更新・削除するジョブを組むことも技術的には可能です。ただしジョブのスクリプトにPagesディレクトリのクリアとリダイレクトページの上書きを実装する必要があり、設定の工数が相応にかかります。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

GitLab Pages単体では、URLごとに異なるパスワードを設定したり、特定のメールアドレスにOTPを送信して認証したりすることはできません。Access ControlはGitLabアカウントと紐付いた認証のみであり、GitLabアカウントを持たない社外クライアントに対しては機能しません。

公開期限の自動管理も標準では提供されません。「3日後にURLを無効にする」という設定をGitLab Pagesの管理画面から行うことはできず、CIジョブのスクリプトで実装するか、手動でPagesを削除するかの2択になります。複数案件を並行管理するチームでは、ヒューマンエラーによる期限切れ忘れが発生しやすいです。

認証と期限の違い

GitLab Pagesに外部認証を追加する現実的な手段は、Cloudflare経由でプロキシしCloudflare Accessを適用することです。GitLab PagesのカスタムドメインにCloudflareのDNSを向け、Access Controlで任意のメール認証やOTPを設定します。GitLabとCloudflareの両方の設定が必要で、初期構築に1〜2時間かかります。

一時共有URLサービスはGitLabとCloudflareとは独立して機能します。ビルド成果物をZIPに圧縮してアップロードし、パスワードと期限を選んでURLを発行するだけです。ギガサイト便の場合は会社ドメイン認証も選択でき、「@example.co.jpのメールを持つ人だけが閲覧可能」という制御が追加設定なしに実現します。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

Cloudflare + GitLab Pagesの構成は、一度設定すれば継続的に利用できます。ただし追加のDNS設定・Cloudflareルーターの設定・Accessポリシーの管理が重なり、設定ミスによる意図しな公開範囲の変更リスクもあります。GitLabとCloudflareの両方のダッシュボードを管理する必要があります。

一時共有URLサービスへの切り出しは、案件ごとの管理が独立する利点があります。GitLab Pagesのデプロイ設定に一切触れることなく、共有URLの発行・差し替え・期限設定をすべてGitLab外で完結できます。制作会社では、デザイナーやプロデューサーがGitLabを操作せずに独立してレビュー共有を行えるため、エンジニアへの依頼が不要になります。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

GitLab Pages + Cloudflare Accessの構成が向くのは、GitLabとCloudflareをすでに有料プランで運用している組織・同一プロジェクトを長期にわたって同一メンバーに継続的に公開するステージング・セキュリティ設定の一元管理を求めるエンタープライズ環境です。

一時共有URLへの切り出しが向くのは、案件ごとにURLを使い捨てにしたい・非エンジニアがレビュー共有を担当する・期限管理の自動化でガバナンスを省力化したい・GitLabアカウントを持たない相手に認証付きで共有したいというケースです。ギガサイト便はCloudflareもGitLabも不要で、ZIPのアップロードだけで完結します。