テナントとプロビジョニングの方式を決める
起動する前に決めておくこと（証明書の取り方、まだ名簿にない人の受け入れ方、テナントを分けるか）と、テナントごとのサインインの決め方をまとめます。 どれも、あとから変えられます。
| あなたが決めること | Agent Fleet がやること |
|---|---|
| 証明書を公開の認証局から取るか、自己署名にするか | Caddy が Let’s Encrypt から証明書を取る。tls internal なら自己署名にする |
招待制（invite）か、自動の受け入れ（auto）か |
invite は名簿にない人を断る。auto は許可リストを通った人を既定テナントに入れる |
| テナントを分けるか、テナントごとにどの方法を受け入れるか | リクエストのたびに、そのテナントが受け入れる方法かどうかを確かめる |
| テナントが登録した IdP を承認するか | 承認するまで、その IdP のボタンを出さず、セッションも発行しない |
tls internal を使うか
Section titled “tls internal を使うか”Caddy は、公開ドメインの証明書を Let’s Encrypt から自動で取ります。これには公開 DNS と、80・443 番ポートに外から届くことが必要です。
| 状況 | 選ぶもの |
|---|---|
| 公開 DNS を用意できる | 既定のまま（Let’s Encrypt） |
| 社内だけ・閉域で、公開 DNS を用意できない | Caddyfile の代わりの設定（tls internal、自己署名）に切り替える |
| すでに TLS を終端するプロキシが前にある | Caddy のサービスそのものを外す（Caddyfile の代わりの設定 2） |
tls internalではブラウザに証明書の警告が出ます。社内の認証局を配るなどの対応を、別に考えてください- 切り替え方は、runbook の「Quick start」の脚注と Caddyfile にあります
AF_PROVISION を invite にするか auto にするか
Section titled “AF_PROVISION を invite にするか auto にするか”まだ名簿にない人がサインインしてきたときの扱いを決めます。
invite（新しい .env の既定） |
auto |
|
|---|---|---|
| 名簿にない人 | 管理者が 管理 で追加するまで断ります | 許可リストを通れば、既定テナントのメンバーとして受け入れます |
| 誰が入れるかを決めるもの | 名簿。追加された人は、AF_OAUTH_ALLOWED_* に載っていなくても入れます |
AF_OAUTH_ALLOWED_*。これだけが、ほかの人とワークスペースの間に立ちます |
| 向いている使い方 | 誰を入れるかを 1 人ずつ決める | 少人数で、ドメインごと許可する |
- 最初から
inviteで始めてかまいません。SUPER_ADMIN_EMAILSのアカウントは、どのテナントのメンバーでなくても 管理 に入れます - 招待される前の人には「まだ招待されていません」の画面が出て、サインインしているアドレスが表示されます。そのアドレスを管理者に伝えてもらえば、そのまま名簿に足せます
inviteを既定にしているのは、.env.example（と ECS のAfProvisionパラメータ）だけです。Control Plane の既定はautoなので、AF_PROVISIONを書いていない既存の.envは動きが変わりません- 動いている配備を
inviteに切り替えても、いまのメンバーには影響しません。どこかに所属している人は、その名簿が先に読まれます。止まるのは、新しい人の自動の受け入れだけです
テナントを 1 つにするか、分けるか
Section titled “テナントを 1 つにするか、分けるか”| 1 つ（既定） | 分ける | |
|---|---|---|
| 中身 | 全員が組み込みの default テナントに入ります |
テナントごとに、完全に隔離されたワークスペースが割り当てられます |
| 向いているとき | 多くの場合はこれで足ります | 部署の間などで、はっきりした分離が要るとき |
テナントはあとからでも足せます。迷ったら 1 つで始め、必要になってから分けてください。
テナントごとのサインインを決める
Section titled “テナントごとのサインインを決める”テナントを分けたら、管理 → テナントを開く →「サインイン方式」と「サインイン規則」で、テナントごとのサインインを決められます。
| 設定 | 画面 | 何をするか | 効くところ |
|---|---|---|---|
| 受け入れる | サインイン方式 | この方法で、このテナントに入ってよい | ボタンを隠すだけでなく、リクエストのたびに確かめます |
| ボタンに出す | サインイン方式 | 受け入れたまま、このテナントのサインイン画面から ボタンだけ 消す | 表示だけです。外した方法で入った人も通ります |
| 自動参加ドメイン | サインイン規則 | このドメインのアドレスの人は、初回のサインインでこのテナントに参加する | 1 つのドメインに 1 つのテナントだけ |
| 招待できるドメイン | サインイン規則 | メンバーとして追加してよい相手の範囲 | メンバーを追加するときだけ。リクエストのたびには確かめません |
- 「サインイン方式」には、配備の
.envで有効にしている方法（「配備共通」）と、そのテナントが自分で登録した方法が同じ一覧に並びます。行ごとの 2 つのトグルで決めます - トグルを切り替えられるのは配備管理者だけです。 テナント管理者には、同じ一覧が読み取り専用で見えます（サインインの方法を決める）
- 「受け入れる」「ボタンに出す」とも、最後の 1 つは外せません。全部外すと「制限なし」やボタンのない画面になってしまうためです
テナント専用のサインインページ
Section titled “テナント専用のサインインページ”各テナントには専用のサインインページ https://<PUBLIC_DOMAIN>/login/<slug> があり、そのテナントが受け入れる方法のうち「ボタンに出す」ものだけが並びます。
- 新しいメンバーには、この URL を伝えてください。招待のメールは送りません（Control Plane はメールを送るしくみを持ちません）
- slug のない
/loginは、既定テナント（default）のページとして表示されます。既定テナントで「ボタンに出す」を外した方法は、/loginにも出ません - ただし「受け入れる」は
/loginには効きません。/loginは、まだどのテナントにも属していない人（新しい配備管理者、招待される前の人）の唯一の入口だからです。ここで絞ると、既定テナントを絞った時点でボタンのないページになり、データベースを直接直すまで誰も入れなくなります。受け入れの絞り込みは、テナントを決める時点（リクエストのたび）で効いています
自前の IdP を持つテナントを迎える
Section titled “自前の IdP を持つテナントを迎える”テナントによっては、自前の認証元を持っています。Entra ID・Okta・Keycloak のテナントそのものが違う（issuer も client ID も secret も別）、あるいは IdP の代わりに GitHub の組織を使う、という形です。 グループの子会社、統合の途中の会社、業務委託先、自前のディレクトリを運用している部門などでよく起きます。
| 誰が | どこで | 何をするか |
|---|---|---|
| テナント管理者 | テナント設定 →「サインイン方式」→ サインイン方法を追加 | 自社の IdP か GitHub の組織を登録する。行は「承認待ち」になる |
| 配備管理者 | 管理 →「サインイン方法の登録簿」 | 中身を確かめて 承認して有効化 を押す |
.envの編集も Control Plane の再起動も要りません- 配備管理者は、管理 → そのテナント →「サインイン方式」から同じ欄を開くこともできます
- 欄の中身、承認の前に確かめること、GitHub の組織のときの違いは 05 サインイン方式 にあります。テナント管理者側の手順は サインインの方法を決める です
承認は形だけの手続きではない
Section titled “承認は形だけの手続きではない”- 登録しただけでは動きません。承認されるまで、そのテナントのサインイン画面にボタンは出ず、サインインの URL を手で組み立てた人にもセッションは発行されません
- IdP を登録できるということは、その人が誰かを名乗らせる ことができるということです。この配備では人をメールアドレスで見分けるので、その影響は配備全体に及び、誰が配備管理者かにも及びます
- もし管理者が自分の IdP を自分で有効にできたら、あなたのアドレスを名乗るトークン を自分で発行できてしまいます
- 承認はテナントにつき 1 回です。日々の運用はテナントの中で完結します
登録簿をときどき読み直す
Section titled “登録簿をときどき読み直す”「サインイン方法の登録簿」は、空になれば終わるキューではなく、ときどき読み直す一覧です。
- 承認して有効化 と 停止 は、その行から直接できます。承認したものも、承認した人と日時つきで残ります
- IdP は相手の会社が管理し続けるので、セルフサインアップのような設定は承認のあとでも変わりえます。issuer と受け入れるドメインを定期的に見直してください
- 停止は、テナント管理者もいつでもできます。止めるのに配備管理者を待つ必要はありません
複数のテナントに所属する人がいるとき
Section titled “複数のテナントに所属する人がいるとき”テナントが「受け入れる」方法を絞ると、複数のテナントに所属する人が切り替えられなくなることがあります。
例: 山田さんは本社と子会社の両方に所属し、ふだんは本社の Google でサインインしています。子会社が受け入れる方法を自社の GitHub だけに絞ると、次のようになります。
- 山田さんが子会社に切り替えると、「このテナントには別のサインイン方法が必要です。サインインし直してください。」と出ます
- その GitHub を押すと「このメールアドレスは、すでにこのデプロイの別のサインイン方法で使われています。」で拒否されます。同じアドレスでも、Google と GitHub のアカウントは別のサインインだからです
- 山田さんが子会社の GitHub の組織に入っていなければ、なおさら通れません
選べる形は 3 つです。
| 形 | やること | 気をつけること |
|---|---|---|
| (a) GitHub だけを貫く | 山田さんを子会社の GitHub の組織に招く | |
| (b) 本社の方法も受け入れる | 本社の方法を「受け入れる」のままにする | 入れる人は増えません。誰が入れるかを決めるのは名簿です。ただし 自動参加ドメイン を設定しているときは、名簿を自動で作る欄なので確かめてください |
| (c) 本人に紐づけてもらう | 山田さんが、いつもの Google でサインインしたうえで 設定 → 個人設定 → アカウント →「サインイン方法を追加」 を押す。以降はどちらのボタンからでも同じアカウントに入れる | 子会社の GitHub のアカウントをすでに持っている人だけです。同じメールアドレスを名乗る方法どうしでしか紐づけられず、その組織のメンバーであることも必要です。紐づけは入場の条件の抜け道ではありません |
- (b) で、使わない Google のボタンが子会社のサインイン画面に並ぶのが嫌なら、Google の行の「ボタンに出す」だけを外してください。山田さんはこれまでどおり
/loginから入り、テナントを切り替えます - 同じ GitHub のアカウントなら、配備共通の GitHub のボタンとテナントの GitHub のボタンのどちらから入っても、同じ人として扱います
- インストールする
- サインインの方法を設定する
- サインインの方法を決める：テナント管理者の画面
- メンバーを追加する
エージェント向け
この指示をエージェントに送ると、このページを読ませられます。
https://agent-fleet.org/docs/ja/operate/install-decisions/index.md を読んで