GitHubの設定をTerraform管理したい

目次

はじめに

セキュリティ的な意識が世の中で注視されているなと思う昨今、GitHubもそこを意識した機能が続々と出ていますね。ActionsのSHA pinningの強制や、Immutable Release あたりは、結構うれしい機能で、みんなも早速使っている印象。

ただ、この辺含めて設定をOwnerがひとつずつ管理するのは難しいし、全てのリポジトリでガバナンスを効かせるのも難しいなと感じてきました。

できれば、IaC管理して、みんなでレビューできる体制にしたく、GitHub の Terraform Provider で、やれそうか調べてみました

この記事では

良さげなユースケースや、注意しないといけないなって思う部分をつらつらとまとめてみます。

できるだけ裏をとって調べていますが、間違っていたら指摘してください。

最初に結論

Terraform Providerを調べてみた感じ、俺はTerraform管理したら嬉しいなと思った。使いたい。

特に、ORG・Repository・GitHub Apps あたりの設定はTerraformで管理できると健全だなと思った。

• OwnerやAdminしか見れない設定を、チーム全員で見れるようになる
• PRレビューを通して合意形成・証跡管理ができる

ただし、最新機能への追従は遅れがち。手動管理との併用になる。

良さげなユースケース

1. GitHub Actionsの設定

Allow XXX org, and select non-XXX org, actions and reusable workflows で、ホワイトリストで許可するアクションを指定する場合、メンバーに依頼をされて都度Ownerが設定することになる。ホワイトリストへの追加は、PRを出してくれてレビューをする形だと、証跡の管理にもなるし良い。 この辺のORGの設定は、ownerを持っていないとそもそも見えないところだから、どんな設定がされているかメンバーからもみれるってところもよい。

次の画像は、リポジトリレベルでの設定だけど、ORGレベルの設定だと、そもそもGitHub Actionsを許可するリポジトリの設定など、他にも都度設定する部分が出てくるので、嬉しいはず。

SHA Pinningの設定は、まだ対応されてないけど、ここもきっといつか対応してくれるはず。(Issueは立っている)

コード例

patterns_allowed の部分がだいぶ嬉しい

resource "github_actions_organization_permissions" "this" {
  allowed_actions      = "selected"
  enabled_repositories = "selected"

  allowed_actions_config {
    github_owned_allowed = true
    verified_allowed = false
    patterns_allowed = [
      "anthropics/claude-code-action@7c5a98d59d2464ae73f453c3e649f5b813374481",
      "golangci/golangci-lint-action@971e284b6050e8a5849b72094c50ab08da042db8",
    ]
  }
}

2. GitHub Appsのインストール

この設定は、Ownerしか見れない部分だから、やっぱりTerraform化して、レビューを通して入れたいところ。 リポジトリが増えるたびに対応が必要になる部分なので、手動管理コストも結構高いはず。

ただし、ここはClassic PATを使う必要があり注意。詳細は後述します。

3. チームの管理

• チーム自体の作成
• チームのリポジトリへのロールのアタッチ
• チームのIdPとの同期接続

個人的にはこのあたり管理が楽になるなって思う。

ただし、IdPのグループのIDとかはハードコードになるし、ownerに集中する作業ではないし、何か標準化したい部分も少ないから、そこまでって組織も多そう。

4. リポジトリの設定全般

ここは、レビューしたい、ownerに集中するのをやめたいってモチベーションよりも、設定を標準化したいって思う箇所かなと思う。

例えば、Repository Rulesetなどは、設定項目が結構多いから、全てのリポジトリを手動でガバナンス効かせるのは結構むずい。 だから、標準設定のモジュールを用意して、ガバナンスを効かせるみたいなのは、結構良いんじゃないかなと思う。

PullRequestがマージされたらブランチ消すやつ、よく設定漏れるけどそういうのも漏れずにできる。地味に嬉しい

5. Organization全体的な設定

Orgレベルの設定は、Owner以外が見れない箇所だから、Terraformで管理してチームで合意した設定にしたい。レビューされて設定されたという証跡も残るので嬉しい

注意点

注意点1: Classic PATを使わないといけないところがある

GitHub Actions上で実行するとなると、Classic PAT、Fine-grained PAT、GitHub App Token の3種類が候補になりますが、基本的にはGitHub App Tokenで対応可能です。基本的にApp Tokenがセキュリティ的にもベストプラクティスだと思うので、これを使うことになると思います。

ただし、GitHub Appsのインストール（github_app_installation_repositories）は Classic PAT が必須となります。

基本セキュリティ的な観点でこれを使いたくないってことが多いと思うので、悲しいところですね。

参考: GitHub Docs - REST API endpoints for GitHub App installations

注意点2: もちろん対応していない機能がある

GitHub Appsの作成

上でGitHub AppsのインストールはTerraform管理できて嬉しいって書きましたが、 作成はGitHub APIが対応しておらず、機能がサポートされていません。 ここは、結構Terraform管理したかったな。

Issueコメントでも指摘されていますね

This part of the API has existed for some time, it can be used to manage app installations, but not apps

新しい機能

あたりまえ体操。 おまけで詳しく触れますが、新しい機能への追従は結構時間がかかっている印象です。 この辺は、機能追加されるまで手動管理をせざるを得ないなという感じです。

主要な未対応機能 抜粋

執筆時点で Terraform リソースが提供されていない機能です。

まとめ

• 設定を標準化してガバナンスを効かせたい
• Ownerしか触れない箇所をIaC化して、チームの合意として設定を反映したい
  • チームメンバーがそもそも見れない箇所を見えるように
  • 証跡管理としたい
  • Ownerの作業負荷と責任をチームで持ちたい
• レビューを通して設定したい

この辺がモチベーションだなと感じました。 単に手動設定をやめたいって話ではなくて、Ownerに責任が一極集中するのを防ぎ、チームで合意形成したい、証跡を残したいっていうのが大きいですね。

新機能のリリースまで時間がかかるっていうのはありますが、OSSにしてくれているんだから、使っている以上コントリビュートしないとですね。

おまけ：機能追従が遅い問題を少し掘ってみる

GitHubのProviderは、公式で開発されているもので、当たり前だけど、GitHub APIを後ろで叩いている。そして、Goで開発されていて、github.com/google/go-githubという ライブラリ を使っています。

GitHub に新機能が追加されても、以下の順で対応されるので、普通に時間かかる。 これは、どのTerraform Providerも一緒そうですね。

1. GitHub API が対応
2. go-github が対応
3. Terraform Provider が SDK を更新
4. Provider 側でリソース実装

go-github のアップデートがしんどそう

さらに go-github は、メジャーバージョンアップ時の breaking change に結構苦労をしていそうです。

go-github v66 → v76 の間に 多数の breaking changeがあって、型定義の変更、API 削除、state migration あたりを頑張っている様子。

なので、go-github更新は メジャーリリース（v7.0.0）でまとめて行う。 → 新しい go-githubがないと新しい機能のAPIを叩けないから、それに引っ張られて対応が遅れる

という感じになっていそうです。

[Milestone v7.0.0 Release] に SHA PinningのPull Request([feat(actions_permissions): sha_pinning_required #2870] ) も載ってますね。