GitHub の Teamメンバーの追加・削除をOktaを使って自動化した。
どうも kajinari です。
今回のエントリーも Okta 関連のエントリーです。
GitHub と Oktaを連携したら、アカウント作成、削除の自動化ができるようになりました、「アカウント招待して下さい！」という不毛なやり取りが無くなりました。
次のステップとしては、GitHub Enterprise Cloud において、Teamのメンバーの自動化をしたくなったので、色々調べたのでその経験についてシェアさせて頂きます。
チーム同期の自動化機能
GitHubのマニュアルはこちらです。重要なところを解説致します。
利用するための条件
- シングルサインオンの設定が完了している。
- 対応しているIdPは、Okta または Azure Active Directory。
- 対象のOrganizationは、SAMLシングルサインオンを必須にする必要がある。
- ベータ機能の位置付け。利用開始するにはGitHubへの依頼が必要
- Teamがネストされている場合、利用できません。
機能の詳細は
- IdPグループのメンバーとGitHub Teamを同期してくれます。
- ひとつのGitHub Teamに対して、最大５つまでIdP側のグループと同期できます。
- 1時間に1度、同期される。GitHubに反映されるまで、最大で59分必要な時がある。
- GitHub Teamにマッピングできる最大のIDPのグループメンバー数は、5,000 まで。
ひとたび有効化してしまうと、Slackのユーザーグループと同じチーム名で同じメンバーのGitHub Teamができるようになります。
複数SaaSを使うのが当たり前な現代では、このように同じグループを異なるSaaSで同じ様に使えると、とても便利です。
また、SaaS毎に細かなメンバーやグループ名の違いを、人が吸収しなくてよくなるため、細かいことですが、脳みそのリソースを無駄に使われないで済むので、良きです。
チーム同期の設定手順
GitHubのマニュアルは、少し説明が足りてないと思ったので、付記させていただきます。
“Team synchronization（Teamの同期）”を有効化する
有効化するためには、GitHubへサポートリクエストを依頼する必要があります。
SSWS TokenとURL
マニュアルには、以下の記述があります。
Organization 名の下で、有効な SSWS トークンと Okta インスタンスの URL を入力します。
SSWS Token
Oktaで発行するAPI Tokenになります。
余談だけど、SSWSが結局何の略なのか分からんかったｗ
発行手順は以下の通りです。
- Okta管理画面の
Security➔API➔Tokensに遷移する Create Tokenを押下し、適当な名前を入力するTokenが発行されるので、Copy する。SSWS Tokenのフィールドに貼り付けます。
余談ですが、OktaのAPIへアクセスするときは、 Authorization ヘッダーに SSWS を頭に付与して使います。
例 Authorization: SSWS 00QCjAl4MlV-WPXM...0HmjFx-vbGua
もう一つ余談ですが、Oktaのアクセストークンは、一定期間利用されないままだと、そのまま無効化されるのは、素晴らしいなぁと思いました。
URL
Okta管理画面のURLを入力すると良いです。https://{TenantName}-admin.okta.com
これで初期セットアップは完了です。 既存チームの設定でIdPのSync対象を設定します。
どのチームでSyncするか設定する
チームの設定画面に移動し、適当なチームの Settings ➔ General に遷移すると、 Identity Provider Groups という設定箇所が増えているのを確認できます。
ここでIdP側のグループを選択することで、IdPグループとSyncすることができます。
同期の確認は、Audit Logで確認できる。
Team Sync を設定した箇所にフィルターが設定済みのリンクがあります。
追加・削除されるのがわかります。
同期される Team のメンバーに関する要件
マニュアルには、このように記載がありました。
Synchronizing a team with an identity provider group — GitHub Docs
- The person is a member of the organization on GitHub.
- The person has already logged in with their user account on GitHub and authenticated to the organization or enterprise account via SAML single sign-on at least once.
- The person’s SSO identity is a member of the IdP group.
自分の環境では、IdP経由でアカウント作成したメンバーは確実に同期対象になっていました。 この場合、途中からSSOを実装した場合において、一度Org.から削除して、再度IdP経由でプロビジョニングが必要になってしまいます。
それはかなりしんどい要件になるので、更に検証して仕様を確認したいと思っています。 もしこうしたら良いよ。って情報をお持ちの方は教えて下さい。
GitHub Enterprise とIdP連携によるプロビジョニングの将来的な方向性
GitHubの公開ロードマップによると、
「Enterprise Managed Users (Private Beta)」がリリースを予定しているそうです。
上記記載内容をよく読むと、普段利用しているパーソナルなGitHubアカウントとは別に、GhE Cloud 専用の完全マネージドなGitHubアカウントが作成できるようになるみたいです。 一昔前のGitHub Enterprise Server みたいですね。
EMUは、Public なGitHub Repository には、読み取り専用でのアクセスができるものの。コントリビュートできないアカウントになり、いわゆる草が生えない状態になります。
完全なSCIMによるTeam Sync、アカウントの作成、削除、管理が実現できアドバンテージもあるものの、開発者との調整が必要になりそうです。
まだプライベートベート版なので、GAするまでに、気になるポイントが改善されているのを期待しつつ、リリースを待ちたいと思います。
