GCP上では誰もが同じ権限に、そして開発者全員が一時的に権限付与できるツール「granter」について

July 16, 2021 shinofara SRE

こんにちは、マネーフォワードケッサイ（以下MFK）SREチームのshinofaraです。今回は権限の仕組みを見直した話と、それを実現する為に開発したgranterというツールについてお話したいと思います。 また今回granterのcore部分をmfkessai/granter_coreとして公開しています。

granter登場以前の世界

MFKでは、2017年の創業時からGoogle Cloud Platform(以下GCP)とGoogle Workspace（当時はG Suite）を選択して利用してきました。

GCPの Cloud Identity and Access Management (IAM)では、Workspaceで作成した個人のアカウントだけでなく、Groupに対して権限を付与する事ができます。 弊社ではGCPのリソース管理には、Deployment Managerを採用しておりますが、IAMに関しては依頼ベースで操作するなどして、割と泥臭く管理してる状態でした。

IaC化するかスクリプトを書くか後回しにし続けている状態であり、運用でカバーというトイルと認識しつつも受け入れてしまっている状態でした。 そのため、もしSREが面接や休みだったら緊急対応が行えないというリスクもそこにはあったと思います。

granter登場に合わせて設計し直した権限設定

  1. CTOやSREだからで強い権限を付与するのをやめ、開発者は全員同じ権限グループに統一しました。またグループ以外に権限を付与することも廃止としました
  2. グループはシンプルに以下の通りとなりました
    1. gcp.service.developer@
      1. オブザーバビリティや一定のリソースの参照権限だけ付与しています。Cloud SQLの接続権限などは対象外
    2. gcp.service.owner@
      1. それぞれのプロジェクトでオーナ権限を付与しています。しかし常時メンバー数は0です。もしオーナ権限を求める機会があればグループにメンバーを追加して利用します。追加方法は後半でお話します

上記の通り整理した事で、エンジニアの入社した際にはdeveloperに追加するだけでOKな状態になりました。更に後ほどお話するgranterの登場で付与作業などのトイルが減り権限周りを意識する事は大幅に減りました。今後組織の形の変化に応じて見直すタイミングも出てくるかと思いますが、当分の間は区切る予定なくいけそうです。

そして作成したgranterとは何者でなにができるのか

ここまでのお話でgranterとはどのような物か、想像されているかもしれませんが、簡単に書くと「権限を一時的に与える君」になります。 granterは、以下の思想に基づいて開発を行いました。

  1. 依頼を受けて承認ではなく、事前承認する形に
    1. これまでの依頼フローで何を保障したかったのかを整理した所、「誰に」「何を」「いつ」「なぜ」付与したのか。そしてそれは妥当な権限付与なのかを保障したいという事が見えてきました。そこで考え方を変えて事前に付与可能な権限を決めて、granterを使用時にはSlackに通知を、そしてBigQueryに履歴を蓄積してあとから検索できる状態にしました
  2. プロジェクト毎に付与できる権限を変更可能に
    1. 例えばデータ基盤系と事業系では求める権限が異なるため、設定を分離して管理、そして付与可能権限の変更は、CTO承認が必要な状態にしてます
  3. 権限剥奪処理も自動で
    1. 現在のIAMにはIAM Conditionsという機能が存在しています。それを利用してデフォルトで15min（もちろん申請時に変更可能）で権限が無効化されるようになりました
    2. IAM Conditionsでは無効になるだけで、IAMの設定には残り続けてしまう為、毎日掃除するJOBをActionsで実行しました
  4. サーバを持たない
    1. Slack Commandなども考えましたが、Form的なUIが欲しいだけなので、Github Actionsのworkflow_dispatch で権限付与手続きを行えるようにしました

Github Actionsのworkflow_dispatchを使って手続きを行う画面

付与に成功した場合のSlack通知

許可されている権限であれば、付与可能です。

付与に失敗した場合のSlack通知

許可していない権限を通してしまってはポリシー違反なので、もちろん禁止してます。

そして今回公開した、granter_coreとは何ものか

MFKでは以下の機能全てがgranterと呼ばれるリポジトリに存在しています。

  1. GCPのプロジェクト毎に異なるgranter_core用のConfigと専用の実行用Actions
  2. 定期的にgranterで設定した権限を掃除するActions
  3. さらにgcp.service.owner@ などのグループに対して有効期限ありでメンバー追加できるActions

ではmfkessai/granter_coreとは何者なのかというお話をできればと思っておりますが、こちらはActionsやコマンドラインから実行可能な付与するためのスクリプトとなっています。 もしActionsで動かしたいといった場合には、exampleも公開しておりますので、こちらを参考頂ければと思います。

謝罪

リポジトリ公開時点では、社内のコードを分離しただけになりますので、以下のような課題が存在しています。

  1. 可読性より社内ツールとしてある程度動くことが保障できればよかったので、プロトタイプを少し育てた感のあるコードになってます
  2. MFK内ではActionsで利用前提だったため、一部Actionsと名のついた架橋変数を求めたりしています

おまけ

Audit logとしてBigQueryにどうやってためているのか

- name: Record History
  env:
    PROJECT_ID: <YOUR PJ>
  run: |
    datetime=$(TZ=-9 date '+%Y-%m-%dT%H:%M:%S%z')
    echo "{ \"actor\":\"${{ github.actor }}\",\"account\":\"${{ github.event.inputs.account }}\",\"project\":\"${IAM_PROJECT}\",\"role\":\"${{ github.event.inputs.access }}\",\"period\":\"${{ github.event.inputs.period }}\",\"datetime\":\"${datetime}\", \"purpose\":\"${{ github.event.inputs.purpose }}\"}" > history.json
    bq load \
    --project_id=<YOUR PJ> \
      --autodetect \
      --source_format=NEWLINE_DELIMITED_JSON \
      activity.set_iam_policy \
      ./history.json

granter実行後などにこちらを実行するとAudit logを残す事ができます。

Group版のgranterって？

$ gcloud identity groups memberships add --group-email [email protected] --member-email [email protected] --expiration 1h

昔はgcloudには存在しなかったGroupですが、Google Workspaceの進化に合わせて、このあたりのデータもGCP経由で操作できるようになってきています。

granterの前と後とこれから

一度、開発者数名に権限何ほしいですか？と聞いたことがあるのですが「調査時などにあればいいだけで、通常は最低限しかいらないです」と言われた事があります。極端な例ではありますが、全員オーナ権限を付与した状態の方がある意味生産性は高くなると思います。しかし得られるメリットよりリスクの方が大きくなるためその判断は選択しませんでした。とはいえ強い権限があることで調査などを爆速で行う事にもつながるため、欲しいけど要らないという状態でした。

またSRE視点から見るとむしろ強い権限は手放したい、そして権限依頼をわざわざしてもらうのも申し訳ないし直ぐに反応できないことで、結果的にお客様に不利益を与え続けてしまうのでなんとかしたい。そして権限付与と剥奪作業はただただトイルという状態でもありました。

granterの登場後は付与や剥奪作業が殆どなくなり、常時強い権限を持つ必要もなくなったことで、SREにとってもとてもいい状態になったんじゃないかなと感じています。

こちらは社内の声の一部です。 この通りgranterが動詞として使われたり、他の場所でも使いたいと言っていただけたりなど、反響はいい感じかなと思ってます。またgranterはOSSやSaaSのおかげで実現できている仕組みでもあるため、それをOSSとして還元する事で弊社以外の場所で活躍してほしいと思い公開する事にしました。

SNSなどで、granterという言葉を見かける日を楽しみにしようと思ってます。

最後に

そんなマネーフォワードケッサイでは、現在「SRE」「Backend」「PdM」「Data Engineer」を大募集しています。 https://mfkessai.co.jp/corp/recruit#corp_recruit_engineer

granterについてでも大丈夫ですし、これらを取り巻く開発文化についてでも大丈夫です。少しでも話しを聞いてみてもいいかなと思っていただけましたら、ぜひCTOである篠原や、弊社のエンジニアとカジュアルにお話をさせて頂ければとても嬉しく思います。

少し長くなってしまいましたが、今後もこれまで弊社として当たり前と思って行ってきた事を、実現したいことは何かを考えDXを向上させていければと思っています。

RECENT ENTRIES
ARCHIVES
ABOUT