メルペイSREチームの @tjunです。この記事は、Merpay Tech Openness Month 2020 の19日目の記事です。
今日は、メルペイSREチームのオペレーションのために開発して利用している Qray(クレイ) というツールの話をします。
はじめに
メルペイでは、Google Cloud Platform(以下GCP)を利用してサービスを構築し動かしています。
GCPには Cloud Identity and Access Management (IAM) という権限管理の仕組みがあります。IAMを適切に管理して、アカウントに最低限の権限を付与することがクラウドサービスを安全に利用するためには必要なことです。これはSREが持つ本番環境に対する権限についても同様で、できるだけ本番環境に対する権限を持たないようにしておきたいのですが、障害対応など本番環境でのオペレーションが必要になることもあります。必要なときに権限付与をするプロセスが重いと、オペレーションを開始するのが遅れて障害の対応に時間がかかってしまうことになります。
そこでメルペイSREでは、普段は本番環境の編集権限を持たないようにして、必要なときにできるだけ速く権限を付与する仕組みとしてQray(クレイ)を開発しました。Qrayは、Spotifyが開発した gimmeというツールを参考にしています。gimmeという意味を日本語にしたときの「○○くれ」という言葉からこの名前をつけています。
メルペイにおける権限管理
Qrayを説明する前に、Qray以外の部分でメルペイがどのようにアクセス権管理を行っているかを説明します。
アカウント（GCPにおけるUser AccountとService Account両方のことをここではアカウントということにします）に対するIAM管理を適切に行うことで、どのアカウントがどのリソースを閲覧あるいは編集できるのか、コントロールできます。例えば、開発環境のProjectにおいてはエンジニアが閲覧・編集権限を持って自由に開発可能にしておいて、本番環境では権限を絞る、という運用が可能です。
IAMを適切に管理するためにやるべきことは
- コードで管理すること
- 権限の変更にはレビューが必須となっていること
- コードで管理しているものと実際の状態の一致を確認すること
などがあると思います。メルペイにおいては、IAMに限らずGCPのリソースはTerraformで管理していて変更のためには必ずレビューを受けて承認されてからでないと反映できないようになっています。また、GCPの監査ログの機能を使って、不正な操作がないことを確認しています。
また「はじめに」の中でアカウントに最低限の権限を付与することが重要と書きました。開発・運用する立場からすると、強い権限を普段から持っていれば何かあったときに迅速に調査・修正できるのに、と思うかもしれません。しかし、エンジニア一人で本番環境が操作できる状態というのはリスクもあります。開発環境と間違えて本番環境のリソースを削除してしまったり、重いクエリをデータベースに投げてしまったりといったオペレーションミスの可能性があります。何らかの事情でエンジニアがデータベースのデータを不正に抜き取ったり書き換えたりする可能性もありますし、またエンジニアのアカウントが乗っ取られてしまう可能性もあります。
そのため、メルペイでは開発者は本番環境のデータの読み書きできる権限は持っておらず、運用に必要なオペレーションは、社内で開発した専用ツールを使ったりKubernetesのJobの仕組みを使ったりすることで、適切にレビューを受けたり運用の記録が残るような仕組みとなっています。
しかし、障害対応などでツールや自動化でカバーできない例外的なオペレーションが必要となることもあります。そのような場合には、開発者がSREへ依頼してオペレーションを行います。Qrayを利用する前は、SREは依頼を受けて必要に応じてTerraformを書いてPull Requestを出し、承認をもらって作業を行い、終わったらTerraformの設定を戻していました。
このやり方はプロセスとしては正しいのですが、2つの課題がありました。一つは、権限を得るまでに時間がかかるということ。手元で最新のコードを取ってきてTerraformを書いてPushしてPull Requestを作成し、複数あるCIが正常に通るのを待ち、承認をもらってマージして、Terraform がApplyされるのを待つまでに、合計で少なくても5分はかかっていたと思います。
もう一つの問題は、Terraformの設定を元に戻すのを忘れることがあるということです。一通り作業をして各所に連絡などをしているうちに忘れてしまうこともありますし、また問題がすぐ再発するかもしれないからしばらく権限を残しておこう、と考えてそのまま忘れてしまうこともあります。
そこで、この承認のプロセスや監査ログを残す仕組みは維持しながら、より速く権限付与を行い、また自動的に権限が剥奪される仕組みを実現したのがQrayになります。
Qrayの紹介
2019/12/12にGCPでIAM Conditionという機能がPublic Betaとして利用可能となりました。IAM Conditionを使うとIAMの利用に条件をつけることができるのですが、その条件の一つに時刻があります。時刻のConditionを使うことで、今からN分後に使えなくなるIAMを設定することが可能になります。
そこでIAM Conditionを利用して、以下のような手順でIAMの一時的な権限付与ができる仕組みを考えました。
動作手順
- 利用者はQrayにログインして、対象GCP Project、必要なIAM Role、必要な時間（最長1時間）を選択し、理由をリクエスト送信
- Slackにリクエストが通知され、別のSREがそのリクエストの内容を見てQrayにログインし承認または却下する
- 承認結果がSlackに飛ぶので、承認されたら権限を作業を行う
4.（時間経過とともに、付与したIAM権限が無効になる）
Webの画面とSlack通知
アカウントは自身のものしか指定できない。Project, Role, Periodなどを選択し、理由を記入してリクエストを送信します。
Slackのリクエストと承認の通知は、以下のような感じで行われます。
これにより、リクエストの送信から承認までがスムーズに実行できるようになりました。
まとめと今後の課題
メルペイSREにおける一時的な権限付与を実現する仕組みを紹介しました。
Qrayを利用することでこれまで5分以上かかっていたIAMの権限付与が1分程度になり、また自動的に権限が剥奪されることが可能となりました。しかしQrayにはKubernetes Clusterにおける権限管理（RBAC）に対応できていないという課題があります。Microservices Platform Teamがこのあたりの課題を解決してくれそうなので、期待しています。
