はじめに
普段はSREとして働いていますが、今回の GitHub SSO 導入は SRE の業務とは直接関係なく、社内の『20％ルール』を活用して取り組みました。
本プロジェクトの目的は、社内の開発体験を向上させるとともに、ガバナンスの強化を実現することでした。
導入の背景
抱えていた課題
- GitHub アカウントと個人の紐付けが不明確
- 開発者が個人の GitHub アカウントを利用しているため、誰がどのアカウントを使用しているのかを一元管理できていなかった。
- アカウントの紐付きを得るにはスプレッドシートなどで管理するしかなく、運用コストが高い。
- 退職者のアカウント管理の不備
- 退職後も GitHub アカウントが残り続けるリスクがあり、適切なアクセス管理が困難だった。
- 開発へのアクセスプロセスの非効率性
- GitHub Organization に開発者がジョインするプロセスが依頼ベースかつ手動で、開発着手までのリードタイムが長かった。
これらの課題を解決するため、GitHub SSO（SAML & SCIM）を導入することにしました。
導入によるメリット
- アカウント管理の可視化
- 誰がどの GitHub アカウントを利用しているのか一目で把握できるようになった。
- 会社メールアドレスが紐付き、何時誰が何の操作をしたか判別可能になった。
- 退職者のアカウント自動削除
- SCIM の導入により、退職時のアカウント削除が自動化され、不要なアカウントの放置を防げるようになった。
- 開発環境へのスムーズなアクセス
- GitHub Organization へのセルフジョインにより、開発者の業務着手までのリードタイムが大幅に短縮。
- Invitation のメールを経由せずとも、
https://github.com/orgs/ORGANIZATION-NAME/ssoのリンクを辿れば、開発者が自発的に GitHub Organization に参加できるようになった。
- SCIM の機能により、 Invitation が自動的に送信されるようになり、手動での GitHub Organization へのアカウント追加依頼が不要になった。
SSO導入後の問題
- GitHub 連携ツールの認証問題
- CircleCI
- GitHub SSOを有効化すると、CircleCI が GitHub の OAuth トークンを利用できなくなるため、アクセス権が失われる。
- 解決策として、CircleCI の OAuth 認証を GitHub 上で再認証し、SAML 保護された組織へのアクセスを許可する必要がある。
- CircleCI で管理しているプロジェクトのフォローが解除され、デプロイキーが削除されることがあるため、再設定が必要。
- 似た事象が ZenHub、GitHub Mobile、AWS CodeBuild 等で発生し混乱を招く結果に。
- CircleCI
- Outside Collaboratorの制約
- ArgoCD の権限管理で GitHub Team を使用しているが、Outside Collaborator が GitHub Team を利用できない問題が発生。
今後の展望
- OneLoginの利用者拡大と SSO の義務化
- 現時点では OneLogin が全員に適用されていないため、全員が利用できる環境を整備し、SSOの義務化を検討中。
- 全員が OneLogin のアカウントを持てるようになれば、GitHub 側の設定で SSO を強制化する。
- アカウント管理のさらなる自動化
- 現状は一部手作業でGitHubアカウントと個人を紐づけているため、完全自動化を目指す。
GitHub SSO の導入により、開発体験の向上及び、アカウント管理の統制強化、ガバナンスの向上を実現しました。
今後も継続的な改善を進め、より効率的な管理体制を目指していきます。
Discussion