[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パブリッシャーロール
は自動で付与された。
ロール割当権限も持っているため、割当も同時に自動でやってくれたと推測。
今後もこの手の罠にハマりそうなので、権限周り気をつけよう。