OktaでGitHubをシングルサインオンをやってみた
どうも kajinari です。
GitHubをOktaと連携したくて調査してた時に、Github Enterprise Server（オンプレミスのやつな）の記事はいくつかあったのですが、シングルサインオン（SSO）やってみた体験を言及しているブログが少なかったので、書いてみることにしました。
皆さんの何かの助けになれたら幸いです。
なぜシングルサインオンを？
当然ながら、GitHubはプロダクトコードを管理しているため、最も漏洩をさけたいツールです。また全社的に課題管理にも利用されており、GitHubのRepositoryを眺めているだけで、プロダクトの次の方向性なども見えてくる事もありえるワケです。
そのため、大きく以下の二点を実施するのが目的でした。
- アカウント管理（招待・削除）の自動化
- 確かな本人認証を徹底したい
アカウント管理について
基本でありますが、人による管理にはミスが発生しうるものなので、自動化するに越した事はないと考えています。
GitHub特有の要因として、 GitHub ID が会社で管理している物では無いという事実に目を向けなければなりません。会社から付与したメールアドレスや氏名で検索することができず、ユーザ側でニックネームの様なIDを取得しているからです。
チームが大きくなっていくについて、「このGitHub ID って誰だっけ？」と、一発で分からなくなります。
これを回避するには、全員のGitHub IDを取得して台帳に保存しておく。
何かしらのハウスルールを設けて、その徹底を実施する。などが必要になり、これらを徹底するにはかなりの労力を有する必要があります。
OktaでSSOをすることで、これらの作業を自動化できるのは大きなアドバンテージです。
確かな本人確認について
OktaをIdPにする事で、IDとパスワード以外にも、生体認証、二要素認証による確認を徹底することができます。それもリスクベースで複数の認証を組み合わせることができ、本人認証を確実にできます。
また、Okta側の認証ログと付き合わせることで、監査ログが確実に取得できるようになったのも大きな改善点です。
GitHub Enterprise とは？
Serverバージョン と Cloudバージョン
SAML シングルサインオンをサポートしているプランです。サーバー版とクラウド版の２種類あります。
Serverバージョンは、オンプレミスでサーバーを準備をして、GitHubのアプリケーションをデプロイして、インフラの管理を自社で実施したい時に採用します。
Cloudバージョンは、GitHub Teamと同様インフラをGitHubで管理してくれるサービスです。今回はサーバー・インフラの運用負荷・工数を懸念して、クラウド版を利用しました。
Enterpriseを契約すると
以下のようなURLで、Organizationの１つ上のレイヤの様な管理画面が提供されます。
https://github.com/enterprises/{company_name}
Organizationを複数持てるようになる。
Organizationを複数所持できるようになります。
複数Organizationにメンバーが重複所属しても、ライセンスシートは重複消費されず、一人分の消費で済むようになります。
例えば、OSS用のOrganizationの作成等ができるようになります。プロダクトコードと完全に分離できるし、別なポリシーで運用できるようになるので、おすすめです。
各Organization毎のリポジトリ作成や、アウトサイドコラボレーター招待などのポリシーも統合管理する事ができるようになります。引き続き各OrganizationのOwnerに委任することも可能です。
Oktaと連携してみた
連携アプリケーションはどれを選ぶ？
OktaのアプリケーションをGitHub Enterpriseで検索してみると、2つのテンプレートがあり、それぞれ出来ること（Capabilities）が違ってるのが分かります。( GitHub Team もあるけど、一旦これは無視して大丈夫）
Github Enterprise Cloud — Enterprise Accounts | Okta
Github Enterprise Cloud — Organization | Okta
Github Enterprise Cloud — Enterprise Accounts の Group Push は何するもの？
Githubの説明によると、Orgへの割り当てに使用するもののようです。
設定で使用したエンタープライズアカウントがアクセスできるOrgを、それぞれOkta上にグループとして作成し、Oktaユーザーをグループに割り当てる。
かなりの数のOrganizationがある場合は、このテンプレートを選択するのが良さそうですね。EnterpriseのレイヤでSAML設定すれば、所属しているOrganization全てに適用されます。
今回の現場では、Organizationの数が少なかったため、Github Enterprise Cloud — Organizationを採用しました。
Organizationが増えるたびに、SAML設定が必要になりますが、Okta Workflowを利用して自動化を推進したかったのも理由のひとつです。（まだ、何もやってないけどｗ）
SAML設定はすんなり終わった
Oktaのセットアップガイド通りに、特に難しい箇所は無く設定できました。
事前にテストしたい場合は、検証用のGitHub Organizationを持っておくと良いです。Enterpriseだと気にせず作成できますしね。
Enterprise前に検証したい場合は、GitHub Japanと交渉すれば環境を準備してくれるかもです。
設定後に、 SSOリカバリーコードが出力されます。これはIdPと疎通が取れなくなった時の代替えログイン手段なので、セキュアに保存しておきましょう。
シングルサインオン設定した後
アカウントのプロビジョニング
GitHubへのプロビジョニング（アカウント作成）、デプロビジョニング（アカウント削除）の自動化はできるようになりました。アカウント管理の手間が大幅に削減できるようになりました。
Teams への自動アサイン
GitHub IDを取得できず、今詰まっています。GitHub Teamsへのプロビジョニングの自動化の手法がわかれば教えて下さい。現在も検討中。
追記
プロビジョニング方法をがわかったので、実際やってみました。
各アカウント毎にシングルサインオンを適用する
このような画面が出てきて、各人でOktaによる認証を有効にしなければなりません。
有効にすると SSO Linked というステータスになります。
SSOを必須化にするには
Organizationの単位で、SSOを必須化することもできます。必須化すると、 SSO Linked していないユーザは、OrganizationからRemoveされてしまうので、多くの人がLinkedしたら実行すると良さそうです。
SSHキーや、アクセストークンの払い出ししている場合
主に社内の開発者が何かの自動化やインテグレーションをしている時に発生するケースです。認証系のトークンをIdP経由での認可に切り替えて行く必要があります。
この現場では、数が多くて割と大変でした。 orz
シングルサインオン化した後、想定できていなかった事
GitHubの認証と連携しているサービスとの連携
CircleCI、ZenHubなどの連携サービスの挙動がおかしくなる事象が発生した。共にログイン & ログアウトするなど、認証をリフレッシュしてもらうことで解消した。
ZenHubは、Installed Applicationの項目で再認証したら治った。
Google Cloud Platform で GitHub連携しているのがコケた
GCPのCloud Build などで、
- Masterブランチへのマージをトリガーに動いてる処理が失敗したり。
- 新しいリポジトリを選択できなくなりました。
これもGitHubの認証トークンをGCP側でキャッシュしており、それをリフレッシュすれば、解決する問題でした。
リフレッシュする方法が分からず、長引いてしまったorz
一時的に、GCP上にGitHubの認証トークンを持っていないユーザで再設定を実施するなどで対応しました。
結論的には、以下のページでGitHub リフレッシュすることで解決することができました。
最後に
GitHubとOktaを連携して、経験した事はざっとこんな感じでした。このブログで何かしらの参考になってくれたら嬉しいです。
他に、こういうのどうなるの？とか質問あったら、Twitterで質問しれくたら嬉しいです。 記憶が呼び起されて、この記事を更新したいと思います。
SSOして、何よりアカウント管理の徹底が機械的に自動的になったのは本当感動的な改善なので、チームが小さいウチに実装するのをおすすめします！
