Cloud Logging シンクの書き込みID仕様変更について

こんにちは、クラウドエースの阿部です。
こちらの記事では、Cloud Logging シンクの書き込み ID 仕様変更について解説しようと思います。

概要

2023年5月31日に Cloud Logging のリリースノートに掲載されました。なお、仕様変更は2023年5月22日から行われていたようですので、ある意味サイレントな仕様変更になっていたようです。

具体的には、Cloud Logging シンク作成時に自動的に作成されるサービスアカウント(書き込み ID)の形式が以下のように変更されました。

変更タイミング	書き込み ID の仕様
2023年5月22日より前	Cloud Logging シンク毎にユニークな ID を作成
2023年5月22日以降	シンクが所属するリソースで共通のID を作成

5月22日より前の、Cloud Logging シンク毎にユニークなIDは、以下のようなサービスアカウント形式になっていました。

作成リソース	書き込みID(サービスアカウント)形式
プロジェクト	p{PROJECT_ID}-{UNIQUE_ID}@gcp-sa-logging.iam.gserviceaccount.com
フォルダ	f{FOLDER_ID}-{UNIQUE_ID}@gcp-sa-logging.iam.gserviceaccount.com
組織	o{ORG_ID}-{UNIQUE_ID}@gcp-sa-logging.iam.gserviceaccount.com

※ {ORG_ID} {FOLDER_ID} {PROJECT_ID} {UNIQUE_ID} はそれぞれ数字のみの文字列

それが、以下のような形式に変更されていました。

作成リソース	書き込みID(サービスアカウント)形式
プロジェクト	service-{PROJECT_ID}@gcp-sa-logging.iam.gserviceaccount.com
フォルダ	service-folder-{FOLDER_ID}@gcp-sa-logging.iam.gserviceaccount.com
組織	service-org-{ORG_ID}@gcp-sa-logging.iam.gserviceaccount.com

※ {ORG_ID} {FOLDER_ID} {PROJECT_ID} はそれぞれ数字のみの文字列

5月22日以降の書き込み ID は、これまで存在していた {UNIQUE_ID} の部分がなくなり、各リソースのIDのみに統一されています。

変更による影響

影響は特にありません。
5月22日より前に作成された Cloud Logging シンクの書き込み ID は、あえて削除して作り直すといったことをしない限り、5月22日以降も不変です。包含フィルタや除外フィルタ設定を修正しても書き込み ID は変更されないことを確認しました。
5月22日以降に新しく作成した Cloud Logging シンクの書き込み ID は新しい形式になりますが、Cloud Consoleやgcloud CLI、API等で書き込み ID を取得してから IAM に設定するはずですので、ほとんどのユーザーは意識せず変更後の書き込み ID をそのまま使っていると思います。

書き込み ID はプロジェクトやフォルダ毎に同じものが払い出されるため、考えようによっては効率的に設定できるとも言えます。

Terraform による実装時の注意点

Terraform で設定する際は少しだけ注意する必要があります。
Terraform で Cloud Logging シンクを設定する場合は以下のように Cloud Logging シンクリソース、シンクの destination に指定するリソース(Cloud Storage 等)、destination リソースの権限許可を行う iam_member 、と3つのリソースを使って設定を記述すると思います。

サンプル設定

# var.project_id is set Google Cloud Project ID

resource "google_logging_project_sink" "test" {
  name        = "logging-sink-test"
  destination = "storage.googleapis.com/${google_storage_bucket.logging_bucket.name}"
  filter      = null

  unique_writer_identity = true
}

resource "google_storage_bucket" "logging_destination_gcs" {
  name          = "${var.project_id}-logging-sink-test"
  location      = "asia-northeast1"
  storage_class = "STANDARD"
  force_destroy = true
}

resource "google_project_iam_member" "logging_destination_gcs_object_creator" {
  project = var.project_id
  member  = google_logging_project_sink.test.writer_identity
  role    = "roles/storage.objectCreator"
}

これまでは、シンク毎にユニークだったため、google_project_iam_member はシンク毎に作成する必要があるので特に問題ありません。
しかし、5月22日以降は、1つのプロジェクト内で同じサービスアカウントになるため、これまでのノリで google_project_iam_member を設定すると、Terraform 上は異なるリソースなのに実際は同じ ID の設定を複数作ることになり、 IAM 設定がコンフリクトする可能性があります。

よって、 google_project_iam_member でまとめて設定しているケースにおいては、重複した設定にならないように注意して記述する必要があります。

なお、以下のようにリソース IAM で個別設定しているケースではコンフリクトしないと思いますので、特に気にする必要はありません。

サンプル設定

# var.project_id is set Google Cloud Project ID

resource "google_logging_project_sink" "test" {
  name        = "logging-sink-test"
  destination = "storage.googleapis.com/${google_storage_bucket.logging_bucket.name}"
  filter      = null

  unique_writer_identity = true
}

resource "google_storage_bucket" "logging_destination_gcs" {
  name          = "${var.project_id}-logging-sink-test"
  location      = "asia-northeast1"
  storage_class = "STANDARD"
  force_destroy = true
}

resource "google_storage_bucket_iam_member" "logging_destination_gcs_object_creator" {
  bucket = google_storage_bucket.logging_bucket.name
  member = google_logging_project_sink.test.writer_identity
  role   = "roles/storage.objectCreator"
}

まとめ

唐突にリリースノートで公開された仕様変更ですが、冷静に仕様を確認してみるとそこまで深刻になるような変更ではありませんでした。
とは言え、こうして整理してみないと不安になる人間なので、整理できてよかったなと思います。

関連ブログ

https://zenn.dev/cloud_ace/articles/20230529-week_release_note#cloud-logging