概要
OktaとGitHub Enterprise CloudをSAML連携させるために、Oktaのアプリ統合カタログにある「Github Enterprise Cloud - Enterprise Accounts」を使ってSSO(シングルサインオン)を実現しました。
実現できたこと
プライベート環境と仕事環境の切り分けが可能になった
GitHubでは、Enterprise Managed Usersという仕組みを利用している場合を除き、個人アカウントを使用して会社のGitHub環境に参加します。そのため、GitHubにログインすれば、時間や場所、デバイスに関係なく仕事環境にアクセスすることが可能です。しかし、これは労務管理とセキュリティの観点で問題がありました。
SAML連携後は、個人アカウントに従来の認証方法でサインインした後、仕事環境へアクセスするためにOktaで追加認証を行う必要があります。これにより、個人アカウントに制限を加えることなく、プライベート環境と仕事環境の切り分けができました。
ここからは実装のお話です。
連携に使うアプリ選び
OktaとGitHub Enterprise Cloudを連携する場合、以下2つのアプリで迷うことになると思います。
簡単に説明すると、連携アプリ1個に対して、Organization 1個が連携するか、Enterprise Account 1個と配下のOrganization全てが連携するかという違いです。
Enterprise Accountsとの連携を選んだ理由
1. 複数のOrganizationがあり、増減する可能性があった
ROUTE06では、全社員がGitHubを使って仕事をしています。すでに、アクセス権で分けられたOrganizationが複数あり、今後も組織の成長に合わせて増減する可能性がありました。Enterprise Accountsと連携することで、配下のOrganization全てにSAML連携を適用することができます。
2. GitHubの設定を、Terraformでコード管理していた
ROUTE06では、GitHubの設定をTerraformを用いてコード管理する仕組みが運用されており、チームやリポジトリへのアクセス権管理はTerraformが担っていました。そのため、OktaではSAML連携により、会社のGitHub環境へアクセスできるユーザーを管理できれば十分だったのです。
3. Oktaの管理権限を制限しなくて良い
Organaizationと連携するアプリでSAML設定を構築すると、プロビジョニングが出来るようになります。これはROUTE06にとってデメリットでした。情シスがOktaを操作することで、アクセス権が無いはずのOrganizationにアクセス権を持たせることが出来きてしまいます。もしそういう実装をしてしまった場合、Oktaでカスタム管理者を作成し、アクセス可能なアプリとグループをホワイトリスト形式で設定することとなり、手間のかかる運用となるところでした。
SAML連携による影響
1. GitHubアカウントに会社メールアドレスの追加が必要
GitHubアカウントにはメールアドレスを複数追加することが可能です。SAML認証のために、Oktaアカウントのメールアドレスと同じメールアドレスをGitHubアカウントに追加する必要がありました。
2. ブラウザでGitHubにアクセスする場合のみ、24時間ごとに一度認証が必要
ブラウザからGitHubにアクセスする場合のみ、24時間ごとに1回SAML認証が必要です。後述するGitHub関連ツールやSlack・メール通知は、SAML連携後に一度認証しておけば再認証不要です。
余談ですが、セッションの継続時間をカスタマイズする機能があるようです。ただし、Oktaでは現在この機能はサポートされていないようでした。
Okta は現在、GitHub Enterprise Cloud での SAML 認証中に SessionNotOnOrAfter 属性を送信しません。 詳しい情報については、Okta にお問い合わせください。 ref: GitHub Docs - セッションの継続期間とタイムアウト
3. GitHub関連ツールは、利用者本人による再認証が必要
| ツール | SSO 有効化による影響 | 対処法 |
|---|---|---|
| GPG key | コミットに "Verified" マークがつかなくなる | https://github.com/settings/keys にアクセスして再認証する |
| GitHub App | 特に無し | 問題が生じた場合は、報告・相談する |
| GitHub CLI | GitHub Actions で利用している場合 ローカルで利用している場合 |
GitHub Actions で利用している場合の対処法: PAT の対処法に準ずる ローカルで利用している場合の対処法: gh auth login で再認証する |
| OAuth App | 連携サービスが GitHub にアクセスできなくなる | 各自が外部サービス側の UI から再認可する |
| Personal Access Token (PAT) | PAT によって可能となっていたすべての操作ができなくなる | https://github.com/settings/tokens または https://github.com/settings/tokens?type=beta から該当する PAT を再認可する |
| SSH key | private repo に対して読み取り・書き込みができなくなる | 各自が https://github.com/settings/keys にアクセスして再認可する |
4. SlackへのGitHub通知は再連携が必要
SlackへのGitHub通知設定は、設定者以外も行うことができます。一人が複数チャンネルの通知設定を行っていた場合、どれか一つのチャンネルで再連携を行うとその人が設定していた他のチャンネルも通知が復活します。やや厄介だったのは、通知が届いてからしか再連携を行うことができない点です。また、SAML連携から数時間後に接続が切れ、対象のリポジトリで何か動きがあった際にこの通知が届きます。（つまり通知が1個ロストする）
5. GitHubアカウントでサインインして利用するサービスは再サインインが必要
GitHubモバイルを例にすると、SAML連携が実施された時点で仕事環境のGitHubが非表示になり通知も途切れます。サインアウトし、再度サインインすることで、SAML認証が有効なOrganizationが表示されるようになります。
6. パブリックリポジトリでも社員はSAML認証しないと見えなくなる
OrganizationでSAMLが有効になっている場合、パブリックリポジトリであっても社員はSAML認証を経なければパブリックリポジトリを閲覧することができません。外部のユーザーに影響はないため、パブリックリポジトリとしては機能します。
終わりに
今回は、OktaとGitHub Enterpise CloudをSAML連携した際のポイントをまとめました。
SAML連携による影響の部分は、他のIDaaSとGitHub Enterprise Cloudを連携する場合も共通のはずです。
この記事が何かしらの参考になれば幸いです。
