OneLogin + Terraform によるアカウント管理・権限管理基盤の紹介

昨日のWaTTsonさんの記事は色んな意味で強烈な内容でしたね。未見の人は是非チェックを。今日の記事は少し渋目な感じになります。

はじめに

あらためましてこんにちは、SREの河村(at-k)です。今回のアドカレでは2回目の登板になります。

1回目の1日目の記事では、アドカレのテーマである "基盤" とはなんぞやということを、サービス構成図に照らし合わせて紹介しました。本記事では、freeeにおけるアカウント管理・権限管理についてお話させていただきます。

なお、2日目と5日目に sentokun から紹介された "freee 権限管理基盤を開発するチーム" はfreeeの各プロダクトから利用される基盤サービスを開発するチームで、今回も権限管理ではありますが別件です。今回はfreeersに払い出されるアカウント、例えばAWSのIAM、Webサービスのアカウント、本番環境へのアクセス権限、などの管理に関する話になります。

社員のアカウント・権限管理は、セキュリティや統制はもちろん、コストの適正化、適切なオーナーシップの実現、スコープ管理、そして円滑なDevOpsの推進、といった面でも重要で、また組織規模によってその難しさは大きく異なります。

freeeも、少なくとも私が在籍している期間だけでも社員は倍以上になりました。それとともに変化してきた権限管理の課題と取組について、これまでの歴史と現状、そして今後について書かせていただきます。なお未だ最適解には至っていません。

freeeにおける権限管理の歴史

最初期〜OneLoginの導入

最初期がどうだったかは自分も正確には把握していませんが、過去の形跡を見る限り（個別のUserにAWS IAM Userが払い出されていたり、サービスごとにログイン方法が異なっていたり）、個々人ごと、サービスごとに個別に人力で設定していくという形であったろうと思われます。

そんな中、freeeではOneLoginを導入し、社内アカウント管理の効率化を図ります。これが2018年初頭の模様です (press release、当時のインタビュー記事)。

OneLoginはCIT(情シス)が管理し、SREは主にEngineerにAWS IAM Roleを払い出す形でOneLoginを利用していました。AWS IAM Roleの払い出しは、Engineerから依頼を受けてSREが作業するやり方になっていました。

IaCの導入、Platform化

Engineerが増えてくることで、SREへの権限設定依頼が増えてきました。また、誰が何の設定を、どういう理由でつけたのか、といったコンテキストが残らないこと、また棚卸しのやりづらさも課題になってきました。

これを解決するために、OneLoginのSRE管理部分をIaC化。Engineerは必要な設定をPRで提出し、CODEOWNERであるマネージャがそれを承認する、という業務フローに落とし込みました。SREはCIや共通コンポーネントの整備・開発、またトラブルシュート対応を担当するようになっていきます。これが2020年の9月頃。

実は、本番環境へのアクセス権限管理自体はもっと早い段階からコード管理されていて、PRをマネージャが承認する、上記と同様のフローになっていました。

ちなみに、OneLoginには公式のTerraform providerがあって、基本はこれを使ってIaCを構築しています。ただ、それまでのfreeeの管理方法をそのまま実現するには機能が不足しており、直接PRを送って対処したものもありますが、今は公式からフォークしたproviderを使っています。

利用者の増加と機能追加、見えてきた限界

その後、OneLogin連携するサービスが増え、それらも同様の仕組みに入れ込んでいき、またGithubのRepository管理やTeam管理も組み込み、用途が広がって行きました。また、DatadogやSendgridなどを利用するためにEngineer以外からの利用者も拡大。Githubアカウントを持っていないメンバーからの依頼を受けて設定代行することも増えていきます。

このあたりから、この仕組みの課題、というか限界が見えてきました。具体的な課題は以下に挙げた点です。

OneLoginの性能限界
- 設定の多いTerraform PJでCIを走らせると、Timeout や Too Many Request Error で時々落ちる
- 大量の設定を抱えたRoleをWeb管理画面上で表示できなくなった
- freeeの使い方が荒い(もしくは粗い)のはあるとは思う
組織マスターとの同期問題
- SRE管轄の権限管理とは別管理の組織マスターがあり、それぞれ相互連携していない
- 入社退職は日次で取り込む仕組みがあるが、利用者が増えて、同期ズレに対する品質要求が上がってきた
組織変動に弱い
- 基本的には個人単位での設定になっており、チーム単位での設定がやりづらい、できなくはない
- 組織マスターとの連携が不十分で、異動や組織変更に設定が追従せず、期首や大量入社時期に設定変更祭りが起きる

特に組織マスターとの連携は大きな問題です。ざっくり今のアカウント管理の全体像は以下の図のような感じになります。

プロセスがいくつかの組織にまたがっており一気通貫になっておらず、設定反映までのリードタイムがあり、また組織マスターから基盤にインポートされる情報がユーザーリストのみなので、権限設定の自動化が不十分な状態です。例えばあるチームに異動したら、そのチームが関与するリソースすべてに対して適切な権限でアクセスできるように自動で設定されるようになることが望ましいですが、現状できていません。

今

課題はありつつも運用でやりくりしている状態で、根本解決はできていません。構成を見直してAPI Call数を減らしたり、組織マスターとの同期の自動化を改善したり、CIを改善してUXを良くしたり、といった小技で対処療法を積み重ねている感じです。

ちなみに、そもそもは3年前の開発合宿で私がベースを作ったのが発端で、その後毎年この時期の合宿期間中のみに集中して開発する、という形の個人PJでしたが、良くも悪くもそれなりに育ってしまいました。本記事もfreeeの開発合宿の真っ最中に執筆したもので、記事を書きながら合宿のテーマとして仕組みの改善タスクに取り組んでいます。

これから

そんなわけで、まだ発展途上中でありかつ現在進行系で課題を持っているfreeeのアカウント管理・権限管理の仕組みですが、今後について少し触れてみます。

目指す先

もともとはSREの作業負担を減らす目的で作った仕組みですが、エンジニアだけでなく、社員全体、また業務委託の方も含めた、割りと大きな基盤になっています。そうなると、設定の手間や連携によるリードタイム増加、設定エラー対応などによる生産性への影響は無視できず、また、不適切な設定がされてしまうことによるリスクや、それを防ぐためのレビューのコストも大きくなっていきます。

また、権限は責任境界を明確にするものでもあり、オーナーシップを規定するものでもあります。権限が適切かつ明快になることで、エンジニアは自分たちのプロダクトを効率的に開発・運用するために関心を払うべき対象が明確になり、アクションも取ることができます。また、財務や事業企画チームが直接クラウドサービスのコストダッシュボードを見て事業計画を立てていくこともやりやすくなるはずです。

CIの安定化・高速化、設定のわかりやすさ、そういったものはもちろんとして、業務プロセス全体を俯瞰した上での最適化が重要です。基本的に個々人に許可されるサービス利用や権限は、個人の所属するチームやロール、業務形態、契約によって決まるものであり、これらを管理している組織マスターとアカウント・権限管理基盤が連携、ないしは統合されていることが望ましいと考えられます。

今の仕組みはSREの見える範囲で局所最適化した状態になっており、全体最適な状態にしていくために、今後は労務チームや情シス、サービス利用のオーナーなど、一連のステークホルダーと理想解を模索して基盤を作っていくことが必要だと感じています。

あと自分に属人化している部分が多少あるのでそこを引きはがすべく、freeeのアカウント管理・権限管理を担うオーナーチームを作らないといけない気がしています。