こんにちは、コーポレートエンジニアの伊藤(ito2)です。PX部門 IT本部 コーポレートエンジニアリンググループに所属しています。
PXは、人事、採用、労務、広報、社内ITからなる部門で、人事はプロダクト開発と同じ、従業員と考えるのではなく、ユーザーと捉えようという考えから「People Experience(PX)」と名乗っています。社内ITについても同じ文脈で活動しており、ユーザー体験を重視するメンバーが集まっています。
コーポレートエンジニアリンググループでは、デバイス、ネットワーク、SaaS活用、社内アプリケーション開発など、各々の強みを活かして、エンジニアリングの力で社内の課題に日々向き合っています。
私はこのグループのマネージャーをする傍ら、SaaSの管理や新規プロジェクトの企画などを担当しています。その中で先日、GitHub OrganizationをOktaのSAML認証に移行し、合わせてSCIM統合を行いました。
本記事では、プロダクト開発で使用されているGitHubについて、部門横断でコーポレートエンジニアがOkta連携する際に考慮したこと、また、つまづいたことを中心に書いていこうと思います。
SAMLとSCIMで実現できること
SAML:組織内の情報にアクセスするときに追加の認証をかけられる
GitHubというサービスでは、個人が所有するアカウントを、会社のOrganizationのメンバーとして招待する仕組みになっています。 この仕組みのおかげで、組織が変わっても同じアカウントを使い続けられるというユーザー側のメリットがある反面、情報セキュリティ上の懸念が生じてしまいます。GitHubにログインさえできれば、プライベートの環境からも組織の情報にアクセスできてしまうからです。
OrganizationにSAML認証を設定すると、組織内の情報、例えばプライベートリポジトリにアクセスするときは、IdPによる追加の認証が求められるようになります。 これにより、ユーザーが意図してSAML認証を行わない限り、組織内の情報を漏洩させるリスクを負わなくて済むようになります。 また、SAML認証の条件としてデバイスコンテキスト等を設定すれば、会社が貸与するPCからのみ組織内の情報にアクセスできるといった制限をかけられるようになります。
SCIM:メンバーの追加削除をIdPから一元管理できるようになる
SCIM連携を設定すると、Okta側にユーザーを追加するだけでGitHub Organizationへの招待メールがユーザーに送られるようになります。 また、Oktaからユーザーを削除すれば、GitHub Organization側のメンバーが自動的に削除されますので、退職時のユーザー削除漏れも防止できます。
SAML, SCIM移行前に検討しておくこと
メンバー追加・削除のワークフロー
SCIM連携するとGitHub側のUIからはメンバーを追加削除できなくなります。
正確には追加はできるのですが、SAML認証できないとプライベートリポジトリにアクセスできないです。また、削除もできるのですが、IdP側にユーザーが残っているとOrganizationに再参加できてしまいます。
そこで今回は、Slackワークフローを使ってOktaのユーザーを追加できる仕組みを用意しました。
OktaのアカウントがないOrganizationメンバーの処遇
STORESでは、Oktaのアカウントがないメンバーはほぼいませんでしたが、必要に応じてOrganizationのOutside Collaboratorとして招待すればSAML対応は不要です。
また、歴史的な経緯等でOrganizationのメンバーになっているbotアカウントがいくつかありましたが、GitHub Appへの移行をお願いしています。(現在進行系)
SAMLを有効にするだけなら、botアカウントを含む既存のSAML未対応のメンバーはOrganizationから削除されることはありません。ただし、新規メンバーにはSSOが強制されます。(SSOへの移行期間みたいな扱い)
つまり、OktaのアカウントがないメンバーがいたとしてもSAML移行は開始できるという感じです。
SAML認証を強制すると、botアカウントを含むSAML未対応のメンバーがOrganizationから自動的に削除されてしまうので注意が必要です。
SAML移行したユーザーの既存のSSHキー、Personal Access Token(PAT)、GitHub Appsが再認可するまで無効になってしまう
既存のSSHキー、Personal Access Token(PAT)、GitHub Appsの再認可が必要になる理由は、SSOセッション上で各種権限を発行する必要があるというセキュリティ上の制約によるものです。
GitHubと連携するツール類が動かなくなると業務に支障が出ますので、SAML移行後に再認可が必要になることは手順書とともに事前にアナウンスしました。
移行作業のつまづきポイント
SCIMのAPI統合がエラーになって詰んでしまった
OktaからGitHub OrganizationへのSCIM APIアクセスを許可するために、OrganizationのOwnerにOktaのOAuth Appをインストールする必要があります。この際、既に他のOrganization向けに同じOAuth Appをインストール済みだとアクセス許可に失敗してしまうようでした。
GitHubアカウントに登録されているOKTA SCIM Integration Appを一度Revokeし、リトライすると成功しました。
計画より切替作業の時間が延びてしまうと焦りつつ、あれこれ考えて30分ほどで解決できました。。
このエラー、検証環境でSCIM連携を試していると遭遇してしまうので注意したいところです。
GitHub Apps、OAuth Appsの再認可が必要になるため、認証周りで想定外に連携が止まるサービスがあった
実はSAML移行作業の1回目は切り戻しとなりました。想定外に連携が止まるサービスがあったため復旧を優先させようという判断になったためです。
切り戻しを踏まえて、事前検証をどのように行うか社内で検討しましたが、すべての連携サービスで事前に検証を済ませるのは工数的に難しいとなったため、問題が起きても切り戻さずに各連携サービス側で認証を再設定しようと事前に合意形成してから移行作業をリトライしました。
コーポレートエンジニアからはGitHubと連携するサービスの詳細は見えていないため、当事者を巻き込んだ事前のコミュニケーションが重要になると思います。
Slackへの通知が届かない問題
移行後、一部のリポジトリとチャンネルでSlackへの通知が届かない問題が発覚しました。
subscribeのコマンドは成功するが実際には通知が届かないという問題だったため、バグだろうということでサポートに問い合わせました。
Slackのワークスペース全体でsubscribeが解除されることを承知で、GitHub側のSlack Appや、Slack側のGitHub Appを再インストールしても問題は解消しなかったという涙なしには語れない試行錯誤の末、最初にfeaturesオプションを指定しない素のsubscribeを実行すれば通知が届くようになることがわかりました。
通知が届かない登録方法
/github unsubscribe org/repository /github subscribe org/repository issues, pulls, commits, releases, deployments, reviews, comments
通知が届く登録方法
/github unsubscribe org/repository /github subscribe org/repository /github subscribe org/repository issues, pulls, commits, releases, deployments, reviews, comments
ちなみにこの問題、2週間後に再度試したところ、上記の通知が届かない登録方法でも通知が届くようになっていました。
問い合わせたときはサポート窓口でも再現し、GitHubのエンジニアリングチームにエスカレーションしてもらっていたのですが、解消後に質問しても先方は特に対応はしていないということだったので、今でも原因はわかっていないです。
SCIM連携済みメンバーの割合を上げていく方法
SAML未対応のユーザーについてはSCIM連携でユーザー削除できないため、メンバーの削除漏れが生じないよう、早めに全メンバーにSAML対応してもらうのが良さそうです。
一方で上述の通り、SAML認証を強制すると、botアカウントを含むSAML未対応のメンバーがOrganizationから自動的に削除されてしまうので注意が必要です。
実は、SAMLが強制されていないOrganizaitonであっても、参加時にはSAML認証が求められます。また、Organizationから削除されても再参加はすぐにできるという仕組みを利用して、SAML未対応のメンバーに絞って一旦Organizationから追い出すことで、botを除く全メンバーをSCIM連携させることができそうだと考えています。
まとめ
OktaとGitHub Organizationの連携は、公式ドキュメントが充実しているのでわかりやすいです。
ただ、実際に移行してみないとわからない問題もいくつかありましたので、今回ブログにまとめてみました。
この記事がお役に立つ場面があれば幸いです。
宣伝:社内IT分野のソフトウェアエンジニアを募集しています
実はこの記事に出てくるシーケンス図はすべてGemini Advancedを使って生成したものです。
まったく手直ししませんでしたが、大きな間違いはないですね。
STORESのコーポレートエンジニアは、自分たちの日々の仕事はもちろん、社内ITの観点から業務へのAI活用を積極的に進めています。
その中で、今、ソフトウェア開発ができる仲間を探しています。
この記事を読んで、少しでも社内ITの仕事に興味を持ってくださった方がいらっしゃいましたら、ぜひジョブディスクリプションのページをご覧いただければと思います。