注意
この記事はタイトルに対して汎用的に使用できるものではありません。
GCPのconfig connectorに関する記事です。
本文に多く「リソース」という言葉が出てきますが、これはGCPのconpute engine, gcs, bigquery, gke, memory store...など様々なサービスを想定して書いています。
config connectorはとても便利ではあるが、、
個人的にはそう信じています！
GKE上からyamlを定義してapplyするだけで、今までconsoleから作成していたリソースを簡単に作成することができます。
ということは、gitでソースコード同様に管理することができます。
これは嬉しいですよね？
これによって、GCPで使用しているサービスに依存してやりにくかったテストなど、開発のプロセスで少し難しく感じているプロセスを解消することができそうです。
ただ、注意も必要だということも私は、障害を起こしてしまったことで学びました。
先ほども記載したように「簡単に作成することができる」ということは、一方で簡単に削除もできてしまいます。
この特徴をちゃんと理解していないと本当に危険な目に遭います。
本番環境で運用しているBigQueryなどをデータごと吹っ飛ばしてしまうかもしれません。
何を起こしてしまったか
今の職場でconfig connectorを使用できないかということで、検証していました。
その中でプロジェクトのIAMを吹っ飛ばしてしまいました。
サービスアカウントを作成して、必要な権限を与えるためのyamlを定義してapplyしました。
コンソールを確認した時、目を疑いました。
全てのIAMがなくなっているのです。
目を疑いましたが、夢ではありませんでした。
既に運用しているアプリケーションに割り当てているサービスアカウントの権限だけでなく、
各サービスのデフォルトのサービスアカウントやサービスエージェントのIAMがなくなってしまっていました。
数分後には、使用しているサービスがアラートをあげ始める事態となりました。
原因
この2つを理解していなかったことが原因でした。
- config connectorの適用スコープと適用時の動作
- config connector独自の削除操作に関するアノテーション
config connectorの適用スコープと適用時の動作
全てのリソースではないですが、一部のリソースではプロジェクト全体で上書きされる形で適用されてしまいます。
私はIAM Policyを使用してIAMを全て吹っ飛ばしてしまいました。
IAMPolicy | Config Connector Documentation | Google Cloud
このexampleのコメントに以下のように記載されています。
# **WARNING**: The bindings here represent the full declarative intent for the project.
# It will fully overwrite the existing policy on the given project.
#
# For finer-grained control over the project's IAM policy, it is recommended
# that the IAMPolicyMember resource be used instead.
#
# This sample assumes the following additional APIs are enabled:
# - compute.googleapis.com
# - container.googleapis.com
# - containerregistry.googleapis.com
# - redis.googleapis.com
#
# Replace ${PROJECT_ID?}, ${PROJECT_NUMBER?}, and ${PROJECT_NAME?} with your desired project ID,
# that project's project number, and your Google Cloud account email respectively.
これを知らずに権限を与えたいサービスアカウントだけ権限を付与するようなyamlを定義して適用させたため、
上書きされてしまい、今まで存在していたサービスアカウント（各サービスのサービスアカウントやサービスジェントも含む）がすべてなくなってしまいました。
ただこのように動作するのはIAM Policyだけのようです。使用する際はドキュメントに記載されているexampleのyamlまでしっかり読んでから動かしてみることを強くお勧めします。
config connector独自の削除操作に関するアノテーション
これは、障害を起こしてしまった際に直接的に作用したものではないですが、その時ちゃんと理解しておらず、もしかしたら他のリソースを動かした時に
このアノテーションによる障害も起こしてしまっていたかもしれないと思い、記載しました。
config connectorは新しくリソースを作成することはもちろんですが、既に作成、運用されているリソースに対してconfig connectorの機能によって
インポートして紐づけることもできます。
既存の Google Cloud リソースのインポート | Config Connector のドキュメント
作成や紐付けたリソースを削除した場合、
もちろんk8sクラスタのリソースから削除されることはもちろんですが、GCP上のリソースからも削除されてしまいます。
本当に必要ないのであればGCP上のリソースから削除されてしまっても問題ないのですが、ケースによってはconfig connectorの紐付けだけ外して
リソース自体は残しておきたい場面があるかもしれません。（リソースに消えてはまずいデータが保管されているのであれば尚更です）
ドキュメントにも赤く警告文として記載されていますが
...
metadata:
annotations:
cnrm.cloud.google.com/deletion-policy: abandon
...
このアノテーションを付けることで、リソース自体を残すことができます。
障害を起こしてしまった時の対応
これは結構特例ですが、
サービスエージェントが失われてしまい、ほとんどのサービスのAPIを使用することができなくなってしまいました。
この消えてしまったサービスエージェントたちは、手作業で復旧しました。
手作業で同じようなIAMを復活させて本当に障害以前のように安定稼働するのか不安でしたが、問題なく動きました。 （後にサポートの方に聞き、状態など確認してもらいましたが問題なく動いているとの連絡をもらいました）
最後に
使用上の注意を正しく読んでお使いください。
以上夏の思い出でした。
