FOLIOPublicationへの投稿
🆒

GitHub EMU導入組織における統制及び部署毎のルール設定

krrrr38
に公開
GitHub
tech

これは何

組織へGitHub Enterprise Managed Users（EMU）を導入しつつ、部署ごとに統制のためのルールを変えるにはということを検討及び導入した話[1]。

また、本記事は FOLIO Advent Calendar 2025 の12/4分の投稿でもある。

GitHub EMUの導入について

GitHub EMUはGitHub Enterprise Cloudの機能であり、企業が自社のIdPと連携してGitHubの認証・プロビジョニング・権限を一括管理出来る仕組み。こちらを導入することにより、組織が管理するIdPとSAML/SCIMにより一括でユーザが管理され、個別GitHubユーザを別管理する必要などがなくなる。

管理側においては自組織の管理するアカウントはSaaSを跨いで自社のIdP側で管理出来ることが望ましいのは言わずもがな。EMUがない場合には、GitHub上での個人アカウントと連携をする必要があった。もちろんそちらを使うことでエンジニアとしての功績を連携出来るといったメリットもあるが、導入組織においてメリット・デメリットは考慮した上での導入が必要となる。

EMUは既存のEnterprise Accountから昇格は出来ずに新規Enterprise Accountを作る必要があるのは、一つの障壁になると思う。また、当時においてはEnterprise Accountに対してRepositoryの移行も基本的には用意されておらず、サポートを得るにはExpert Serviceとの連携が必要になる。我々の場合はGitLabから移行を行ったが、こちらについては自前で移行ツールを作成した。

やりたいこと

GitHub Enterpriseを利用する中では、OrganizationやTeamをどのように作っていくかは今後の組織運営におけるコミュニケーションに影響しうる。プロダクト毎にOrganizationを立てるケースもあれば、機密プロダクトはOrganizationに切り出すといった要件が生まれうる。

今回の導入にあたっては、できる限り情報にはアクセス出来る設計としたく、1つのOrganizationに企業単位の情報は出来る限り集約して、様々なRepositoryは見れる状態とする方針にしている。

一方、任意の人が任意の操作が出来ることは好ましくはないため、多数存在している部署・チームのRepositoryを1つのOrganization内できちんと統制が取れる形に出来るのかというのが肝になる。

EMUの導入によるグループ管理

ここではあまり話すことは無いが、EMUを導入した以上は自社のIdPで管理されているユーザはGitHubユーザとして連携される。またそれ以外にもIdPで管理しているグループを、GitHubのTeamと連携することが出来る。あとはGitHub上で任意のTeamを作成されない状態とした上で、このTeamを用いてGitHub側では権限管理をしていけば良い。

resource "github_emu_group_mapping" "this" {
  for_each  = local.teams
  team_slug = each.value.name
  group_id  = each.value.group_id
}

GitHub Organization における設定

この時点で出てくる課題としては以下の２点になる。

  • Repositoryの数が多すぎて、自らのTeamが管理すべきものがわかりにくい
    • 様々なRepositoryが見えることはいいのだが、何に注力すれば良いかわかりにくい
  • チームによっても統制の幅は効かせたい
    • いわばすべてのrepositoryを厳しくするのではなく、sandbox環境のような場も欲しい

この課題に対して、Organizationの管理側において、以下の方針で進めることとした。

  1. Repository Policyで、Repositoryの名称にはprefixを付与する制限をかける
  2. Repository Rulesetにより、prefix毎にルールを設定する

1️⃣ Repository Policyで、Repositoryの名称にはprefixを付与する制限をかける

前作業として、Repositoryには特定のprefixを必ずつけるルールとしている。これはRepository Policyで設定が可能。

こちらはGitHub管理側の設定とするため、統制を取るために管理側がどのようなRepositoryがあるかをわかる状態となる。また、このprefixに応じてTeam Repositoryの設定さえしてしまえば、自分が所属するチームで取り扱っているRepositoryが https://github.com/orgs/${your_org}/teams/${your_team}/repositories などから確認出来る状態にもなる。

2️⃣ Repository Rulesetにより、prefix毎にルールを設定する

Repositoryには特定のprefixがついているので、このprefix毎にRulesetを作ることが可能になった。

この管理は部室長などに任せることで、部毎のルールに従った統制を効かせることが出来る。ときにはbypassなども設定することで、緊急時における特権を一部のrepositoryに対してのみ追加することなども出来る。

設定自体はブラウザから行うのではなく以下のようなterraformで管理することで、誰がこの権限設定を変更する事ができるのか、といったことまで制御可能だ。

resource "github_organization_ruleset" "teamx" {
  name        = "team-xxx default branch"
  target      = "branch"
  enforcement = "active"
  conditions {
    ref_name {
      include = ["~DEFAULT_BRANCH"]
      exclude = []
    }
    repository_name {
      include = [
        "team-xxx-*", # 特定のprefixを持つrepositoryに対するrule
      ]
      exclude = []
    }
  }
  rules { ... }
}

話していないこと

Roleの話・CODEOWNERSの話・共通action（actionlint/ghalint/...）・移行ツール詳細・他...などありはするが、またいつか。

最後に

FOLIOでは内部統制も意識しながらも、各チームに対する実運用まで見据えた管理が行われています。
もしより詳細な中身を知りたい方などはカジュアル面談などでお話しましょう。

https://corp.folio-sec.com/thespecialone/jobs/

脚注

  1. ちなみにこの話は株式会社FOLIOではなく、株式会社FOLIOホールディングスに導入した話。前者はまたどこかで語られるはず？ ↩︎

FOLIO
FOLIOPublication

Discussion