Skip to content
My Docs

Gigaのdevhostにおける認証

This content is a draft and will not be included in production builds.

Gigaのステージング環境では、管理画面や開発環境へのアクセス時に認証が必要となる。2026年2月時点においてdevhost環境はLambda@Edgeを使った認証に対応していないが、開発環境やステージング環境は移行済みとなっているはず。

この仕組みはIPアドレスの範囲を使って許可する機能も持っている。

関連リポジトリ

Section titled “関連リポジトリ”

何がどのように関わるのかはGiga関連のリポジトリと関係性を参照。

構築

Section titled “構築”

hatena/giga-terraformリポジトリで構築されている。

階層としてはこのような。

  • environments: 環境ごとの設定がある
    • (環境名): production や staging などの環境名でディレクトリが分かれている
      • medias:
        • (メディア名): jump_plus などのメディア名でディレクトリが分かれている
          • main.tf: おそらく最初に読み込むHCLファイル
      • mirage-ecs: ブランチ単位でサブドメインを割り当てるプロキシサービスの設定
  • modules:
    • compute:
    • storage:

内部では、ALB建てたりドメイン作ったりするところはhatena/sre-standard-terraform-module/mirage-ecs-devhostに依存している。

デプロイ

Section titled “デプロイ”

まず認証処理をするためのLambda関数がhatena/giga-auth-at-cloudfrontリポジトリに存在する。これの main ブランチが更新されたとき、on-push-main.ymlからwf-create-release-pr.ymlが動作して、hatena/giga-ecsに環境ごとのJSONファイルを更新するプルリクエストが作られる。

上記のプルリクエストをマージするとon-push-master-giga-auth-at-cloudfront.ymlワークフローが動作する。これは内部でaws-cloudfront-edge-functions-associatorを使っていて、更新されたバージョンでLambda関数が置き換わる。細かい実装は省略するが、最終的にLambda関数の設定を新しいバージョンで書き換えている。

import {
  type CacheBehavior,
  type DefaultCacheBehavior,
} from "@aws-sdk/client-cloudfront";


type Behavior = DefaultCacheBehavior | CacheBehavior;


const desiredConfig = structuredClone(config);
const behavior = desiredConfig.DefaultCacheBehavior;
const viewerRequestItem = behavior.LambdaFunctionAssociations?.Items?.find(
  (item) => item.EventType === "viewer-request",
);
viewerRequestItem.LambdaFunctionARN = lambdaARN; // ここにrevisionが含まれる

処理の流れ

Section titled “処理の流れ”

2026年2月時点

graph LR
    UA --> ALB --> mirage --> devhost

移行後の予想図

graph LR
    UA --> CloudFront --> ALB --> mirage --> devhost

まずDNSだけど、ブランチごとのサブドメインはどうやって登録する？ → *.devhost.gigaviewer.com のAレコードが登録されていて、これがALBに向いている

ALBはどこで作ってる？ → mirage-ecs モジュールの中で sre-standard-terraform-module.git//mirage-ecs-devhost モジュールを呼び出している

ワイルドカードドメインはどこで作ってる？ → migrate-ecs-devhost モジュールのresource.aws_route53_record.ecs_tasksで作ってる

mirageはどうやってタスクにルーティングしている？ →設定ファイルがS3にあるが、たぶんコンテナ自体は事前に作ってある →あってる、devhost ラベルが付いたとき Giga-Usagi リポジトリのcreate-mirage-devhostワークフローでコンテナイメージのビルドとECSタスク定義を作成している →そのうえで、Mirageのlaunch APIを使ってサブドメイン名とタスクを紐づけている

上記のコードはCloudFrontの viewer-request でフックして起動するもの。

giga-terraform

古い情報

Section titled “古い情報”

BASIC認証は Giga-Usagi リポジトリに入っているが、これは最終的にLambda@Edgeの関数で置き換えられるはず。