[GCP]LogRouter+PubSub経由でログのSlack通知しようとしてハマった話

このエントリーをはてなブックマークに追加

特定のログをLogRouter/PubSub経由でSlack通知しようとしてハマったお話

結論

LogRouterに紐づくサービスアカウント(Write identity)にPubSubパブリッシャーロールを忘れずに付与する

やろうとしたこと

特定のログをSlack通知したくなったので、LogRouter+PubSub+Cloud FunctionsでSlack通知機能を作成。
※LogRouterとPubSubトピックの作成権限は持っているアカウントで作業

起きたこと

LogRouterとPubSubをそれぞれ作成し、Cloud FunctionsでPubSubトリガーの関数を作成。
その後通知対象のログを出力するも、Cloud FunctionsにLogRouter/PubSubからログが流れてこない。

PubSubトピックでテストメッセージ送信すると、関数が動くのでPubSubトリガーには問題なし。
悩みながら公式ドキュメントにこんな記述が。

https://cloud.google.com/logging/docs/export/configure_export_v2#dest-auth

エクスポート先へのオーナー アクセス権がある場合は、次の方法でエクスポート先にサービス アカウントを追加します。
Cloud Pub/Sub の場合は、シンクの書き込み ID をトピックに追加し、Pub/Sub パブリッシャーのロールを付与します。

Pub/Sub パブリッシャーのロールを付与します。

LogRouterに紐づくサービスアカウントへ作成したPubSubトピックのPub/Subパブリッシャーロール付与すると、LogRouterからPubSubにログが流れCloud Functionsの関数が実行されるように。

こうなった原因

作業アカウントがPubSubトピックのロール割当権限(pubsub.topics.setIamPolicy)を持っていなかったことが原因
LogRouterとPubSubトピック自体は正常に作成できていたので、ロール割当だけができていないとは。。

ちなみに、管理者権限アカウントで試しにLogRouter/PubSubトピックを作成したところ、Pub/Subパブリッシャーロールは自動で付与された。
ロール割当権限も持っているため、割当も同時に自動でやってくれたと推測。


今後もこの手の罠にハマりそうなので、権限周り気をつけよう。