🐙

GitHub Enterprise Cloud導入メモ：プラン選定とOrganization設計

に公開
GitHub
情シス
SSO
Okta
コーポレートエンジニア
tech

📝
この記事は、GitHub Enterprise Cloud（Enterprise with personal accounts） を導入する際に押さえておくべきポイントをまとめたメモです。

1. 選択できる運用モデルは2種類

GitHub Enterprise には、大きく次の2つの運用モデルがあります。

A. Enterprise with personal accounts

個人で作成した GitHub アカウントを、そのまま Organization に紐付けて管理します。

  • メリット
    • 既存の GitHub アカウントを継続利用できる
    • コントリビューション履歴などもそのまま残る
  • デメリット
    • username などを一律で指定して管理できない
    • IdP 連携やポリシーの適用粒度が Organization 単位になりやすい

B. Enterprise with managed users（EMU）

IdP からのプロビジョニング経由で、組織がアカウントを発行し、従業員に付与します。

  • メリット
    • IdP（Identity Provider）からアカウントを統制して作成できる
    • username を指定して管理できる
  • デメリット
    • 従業員が作成した GitHub アカウントは利用できない
    • コントリビューション履歴などが引き継げない
    • 退職などで離れる場合、アカウント削除の運用になりやすい

どちらにした？

A（Enterprise with personal accounts） を採用しました。

  • これまで「個人アカウントを Organization に連携」する運用だったため、継続性が高い
  • EMU ほど強い統制が必要な状況ではないという判断

以降の内容は A（personal accounts）の環境 での話です。

2. Enterprise と Organization の関係

2-1. 構造

Enterprise 環境は、ざっくり言うと Enterprise配下に複数の Organization がぶら下がる構造です。
Enterpriseの中にOrganizationはいくつでも用意できます。

2-2. Organization の数

管理面を考えると、一つのEnterprise内のOrganization数は少ない方が良いです（詳細は後述）。
公式にも「まずは少数の組織から始める」趣旨の記載があります。

戦略を立てる際に、少数の組織から始めるとよいでしょう。…
必要に応じて追加の組織を作成できます。

https://docs.github.com/ja/enterprise-cloud@latest/admin/concepts/enterprise-best-practices/organize-work#組織を意図的に作成する

2-3. Organizationを分ける判断基準

「Organizationを増やすと運用コストが増える」前提のうえで、それでも分ける価値があるのはどんなときか、の判断基準です。

  • 監査・セキュリティ要件が異なる
    • 監査対象になり、より厳格に管理したいリポジトリがある
  • 権限を細かく適切に管理したい
    • Enterprise ではカスタムロールで権限を設計できるため、適切な最小権限を実現しやすい
  • 誤アクセスのリスクを減らしたい
    • プロダクトのソースコードにアクセス不要な人が、アクセスできる環境を避けられる

弊社では上記の理由から、監査の対象となりセキュリティ面をしっかり管理したいプロダクト関連のリポジトリのみを切り出す 方針としました。（結果、2つのOrganizationを管理することになった）

3. SAML SSOの設定

3-1. personal accounts 環境 × SCIMプロビジョニングを使う場合

personal accounts 環境 かつ SCIMプロビジョニングを使う場合は、Organization ごとの SAML SSO 構成が必要です。

※SCIMプロビジョニングを使わない場合は、personal accounts 環境でも Enterprise一括のSAML SSO設定を選べるケースがあります。

3-2. Organizationの数だけIdP側の管理が複雑になる

IdP 側に Organization の数だけアプリケーションを用意する必要があるため、純粋にOrganizationが多ければ多いほど管理・運用のコストが上がります。

3-3. 検証メモ：Organization間の行き来

それぞれでSAML SSO設定を行ったOrganizationへアクセスするためには、「両Organizationで一度認証済み」かつ「セッションが切れていない」場合、追加認証なしで行き来できる挙動でした。

※設定やセッション状況により変動します。

4. Enterprise の中に Organization を設置する方法

前述の通り、Enterprise 環境では Enterprise 配下に Organization があって初めて運用が成立します。

Organization を用意する方法は大きく3パターンです。

公式ドキュメント

https://docs.github.com/ja/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise

4-1. Enterpriseの中に新しくOrganizationを作成する

シンプルに新規作成する方法です。

4-2. 既存OrganizationをEnterpriseに招待する

Free / Team など、Enterprise 化の前から存在する Organization を、リポジトリやメンバーごと Enterprise 配下へ移せます。

※EMU環境の場合、既存の Organization を Enterprise に追加することはできません。

4-3. 他のEnterprise環境からOrganizationを移転する

双方の Enterprise Owner 権限がある場合、Enterprise → Enterprise で Organization を移転することができます。

5. OktaにGitHubアプリが多くて迷う問題

Okta のアプリカタログで「GitHub」と検索するとたくさん出てきて焦ります、、
間違えるとうまく設定できないので注意です。

5-1. どのアプリを選ぶ？

  • GitHub Enterprise Cloud を personal accounts で運用
  • かつ Organization ごとに SSO 設定をする

この場合は、GitHub Enterprise Cloud - Organization を選択します。

5-2. つまずきポイント

設定画面で Organization 名 を入力する項目があります。

例：https://github.com/organizations/ORG_NAME
ORG_NAME の部分が Organization 名 です！

6. 導入メモ感想

実はこれを書いている段階では導入直前で、検証も大詰め！といったところです。

弊社では200名強がGitHubを利用している状況であり、かなり大掛かりなプラン移行のためドキドキの導入計画です。

実際に導入した後、どんなトラブルが起こったかなど後日談を書く予定ですので楽しみにしていただければと思います！

何事もなく導入完了できますように。。。

Discussion