はじめに
こんにちは！ SRE (Service Reliability Engineering) の tada です。
SaaS の権限管理ワークフローの整備 #1 の続きになります。 今回は権限管理ワークフローの中で GitHub にフォーカスをあてて、ワークフローの運用負荷を削減したお話をしたいと思います！
GitHub の運用
SaaS の権限管理ワークフローの整備 #1 でお話ししたように、GitHub の管理や保守は SRE で行っています。 さまざまな依頼対応を行っており、以下のようなものがあります。
- Organization Member の管理
- Team の管理
- Team Member の管理
- Repository の管理
- Repository の Collaborator の管理
- Repository の Outside Collaborator の管理
- GitHub Copilot Seat の管理
基本的に現在ではすべて Terraform 管理されており、Pull Request を作成することで、CI/CD により Apply が行われるようになっています。
Repository の作成
この中の Repository の管理について深掘りをすると、Repository の作成も Terraform 管理で行っています。 Repository の作成まで Terraform 管理にすると、管理が大変、Repository を作るだけでワークフローを経由する必要がある、という問題点がありますがこれには背景がありました。
プロダクト開発センターでは GitHub を Team Plan で契約して利用しているのですが、Team Plan では作成する Repository の Visibility を private に制限することができません。
Organizations using GitHub Enterprise Cloud can also restrict members to creating private repositories only.
プロダクト開発センターでの開発は基本的に社内向けサービスの開発であり、public Repository を作成することはほぼなく、原則的に private Repository となります。
ここで懸念されるのは、Repository の作成を許可していた場合に、誤って public Repository で作成してしまい、それに気付かぬままプロダクションコードがコミットされ公開されることです。 作成に細心の注意を払う、定期的や自動的に public Repository が作成されていないかチェックするなどの予防策を行うこともできますが、やはり人間はミスをするものです。
なので、そのようなインシデントリスクは極力未然に回避をしておきたく、Organization の設定で Repository の作成を拒否した上で、このような形を取っていました。
運用負荷
上記であげた対応の一覧の中で一番数が多いのがやはり Repository の作成になります。
そのため、Repository を作成する依頼側も Repository を作成したい！と思ってから作成されるまでにタイムラグが発生しますし、SRE としても Pull Request を捌いたりするのがそれなりなノイズとなっていました。
この様な、まさにトイルと呼ぶに相応しいこの問題を解消できないかと検討することになりました。
GitHub Actions による代替
そこで目を付けたのが GitHub Actions です。
GitHub Actions は様々なトリガーを持てますが workflow_dispatch トリガーを指定することで、GitHub の UI 上から Workflow を起動できるようになります。
When a workflow is configured to run on the workflow_dispatch event, you can run the workflow using the Actions tab on GitHub, GitHub CLI, or the REST API.
もともと Repository を Terraform 管理していたのは、Repository の Visibility を担保するのが目的であり、別の手段で担保できるのであれば Terraform 管理する理由はそこまで無いと考えていました。
Actions 内で Repository を作成すること自体は簡単です。 Runner Image には GitHub CLI も含まれているので、GitHub CLI で REST API を呼び出せばいいです。
もちろん、API を呼び出すには Token が必要になりますが、もともと Terraform の Apply 時に Repository を作成できたりするレベルの GITHUB_TOKEN が必要だったため、GitHub App を作成し、Actions 内で一時 Token を払い出して処理を行うようにしてありました。 同様に払い出した一時 Token を API に渡すことで認証も問題ありません。
あとは Repository 作成の API を呼び出す時に visibility を private に明示しておけば、余計なワークフローを介さずに、private Repository のみ自由に作成できる様になります！
導入よる効果
まだ GitHub Actions による Repository の作成の運用に切り替えて少ししか経ってないので、確かなことは言えませんが、GitHub に関する SRE への依頼の数は Repository の作成分減りますし、依頼者側としても余計な依頼作業がなくなるのは嬉しいポイントだと考えています。
また、検証などで Repository を作成しようとしても今までは依頼を通さなければ、という障壁によって Repository などに残さないなどのケースもあったかもしれませんが、その障壁がなくなることで Repository の作成、コードや知見の共有が活性化されるのではとも考えています！
権限管理まわりはまだまだ課題や、自動化、工数削減できるような部分も多いにあると思うので、次回の記事でも取り組みを紹介していきます！