【R&D DevOps通信】Slack BoltとCloud Functionsでデータ基盤アクセス承認システムを開発

こんにちは。研究開発部 Architectグループにてデータエンジニアとしてデータ基盤の開発・運用を担当しているジャン(a.k.a jc)です。直近の記事にてGoogleグループとIAMによるデータ基盤のアクセス制御方法を紹介しました。

本記事では実装の概要を紹介しようと思います。なお、ソースコード・設計図の詳細は公開予定がないので、あらかじめご了承ください。

また、興味のある方は過去のデータ基盤関連の記事も併せてお読みいただければと思います。

システム構成

開発工数を短縮するために、自力でフロントエンドまで開発せずに、Slack上にアプリを開発することにしました。また、データ基盤は主にGCP上に構築されており、サービスアカウントの認証などを簡単化するために、サーバーサイドは2022年8月にGAリリースされたGCPのサーバーレスサービスCloud Functions 2nd gen + CloudSQL (PostgreSQL)という構成を採用しました。

利用者 → Slack App

SlackのAPIを直接叩かず、Slack BoltというSDKを利用しています。理由としては

Slack APIを自力でラッピングする必要がなくなり、Slack Appの開発が簡単になる
時間がかかる処理はBoltのLazy listeners機能（Pythonのみ利用可能）を挟むと、Slack Appの3秒ルールを回避しながら、ユーザ体験を向上できる

また、申請用フォーム、登録情報確認、承認用のメッセージなどのUIはSlackが提供してくれているBlock Kitを利用しているので、簡単な検証はCloud Functionsに上げる必要がなくなります。

api.slack.com

Slack App → Cloud Functions

通常の場合、Cloud Functionsが発火された後、寒い冬に数分間アイドリングして車のエンジンを暖めてから走り始めるのと同じような仕組みで、数秒間アイドリング（初期設定）が設けられています。--min-instancesを設定すると、アイドリング済みの状態を保って、いつでも走れる状態を維持します。逆にそうしないと、利用者が申請フォームを提出した後{'ok': False, 'error': 'expired_trigger_id'})エラーが出ます。この記事で詳しく説明されています。 zenn.dev

Cloud Functions → Google Group → BigQuery

Cloud Functionsは、申請者が承認後に指定されたデータセットと権限を付与するために、BigQuery、Cloud Identity、Cloud Resource Managerの3つのGCP APIを利用します。

BigQuery Slackの申請フォームで表示するためのBigQueryデータセットの名前とラベル一覧を取得します。テーブル内容は不要なため、BigQuery Metadata Viewer権限が適切です。
Cloud Identity 前回の記事に記載されている通り、Googleグループを操作（利用者追加・削除）するために必要です。データセットのGoogleグループに承認システムのサービスアカウントをマネージャーとして追加します。ただし、サービスアカウントはGoogle Workspaceに含まれていないため、Googleグループの管理画面からは追加できず、GCPのUIからIAM→Groupsで追加が必要です。
Cloud Resource Manager IAM権限追加用 (Project IAM Admin)。IAM権限を追加するために(Project IAM Admin)必要です。利用者に付与する権限の詳細は、前回の記事を参照してください。