見知らぬGCPプロジェクトの利用状況を把握する方法あれこれ
前書き
管理者不在のGCPプロジェクトを渡され､何してるのかを調べて欲しいというタスクを振られたかわいそうな人向けにトリビアルなノウハウを共有します｡
TL;DR
- Asset Inventoryでリソースの総量を把握する｡
- 稼働状況をモニタリング､ログ､Billingなどから把握する｡
- リソース同士の関連をIAMから探る｡
- 引き継ぎはちゃんとやれ｡たのむ｡
前提
本文
本記事では､GCPが提供するコンソールをさっと眺めるだけである程度のざっくりとした構成を概観し､より詳細な調査をするための足がかりを得るノウハウを共有します｡ 各リソースの詳細までは踏み込みません｡
利用するツール
この記事で触れるツールは以下です｡ 順番に説明しますが､実際はこれらのツールを相互に行き来しながら関連を探ることになります｡
- Asset Inventory
- Cloud Monitoring
- Cloud Logging
- APIs & Services
- IAM
Cloud Asset Inventory
Cloud Asset Inventoryは､GCPプロジェクト内のリソースのメタデータを保有し､一覧化や検索が可能なサービスです｡ 利用は無料です｡
Cloud Asset Inventoryを用いることで､どんなリソース(VM, GCS, BigQuery, VPN…)が作成されているのか､それらがどのlocationにあるのかを把握することができます｡
Cloud Asset Inventoryは｢IAM & Admin｣配下から使用でき､以下のように､どのリソースがいくつ作成されているかを一覧できます｡
上の画像では､少なくともGAEのサービスが1つ､BigQueryのデータセットが2つ､VPNが1つとサブネットが多数あるといったことが伺い知れます｡
コンソールからCSVダウンロードも可能です｡
注意点としては､Cloud Asset Inventoryはあくまでリソースがあるかないかの静的な状況で､｢実際に使われているかどうか｣は判別できません｡ ｢実際に使われているかどうか｣は別のツールが必要になります｡
Cloud Monitoring, Cloud Logging, APIs & Services
｢実際に使われているかどうか｣を把握するためのツールとしてはMonitoringとLogging*2とAPIs & Servicesがあります｡ これらはGCPのリソースの利用状況と､なにかしらのイベントが起きていることを詳細に把握できるツールです｡
Cloud Monitoring
ここでも｢Resource dashboards｣という形でリソースの有無が把握できます｡
Cloud Monitoringは代表的なプロダクトについてはGCPが予め作成したダッシュボードがあり､稼働しているプロダクトが表示されます｡ また､気の利いた前任者であれば､カスタムダッシュボードとしてそのプロジェクトで把握したいメトリクスをまとめたダッシュボードを発見できるかもしれません｡*3
Cloud Logging
CloudLoggingは､各コンポーネントが出力したログエントリが集約されていて､なんのプロダクトが活発に動いているかが把握できます｡ 画面上の｢PageLayout｣から｢Log Field｣および｢Histogram｣をペインに表示しておくことで､どのリソースが直近どのような時系列と頻度で動いているかを知ることができます｡
APIs & Services
GCPはリソースの各種操作をAPIを利用して行っており､｢APIs & Services｣はそのAPIの利用状況がわかるダッシュボードです｡
このダッシュボードを参照することで､ヘビーに呼び出されているAPIはなにか､そのプロダクトはなにかを把握し､ワークロードの傾向をつかむことができます｡
IAM
IAMを参照することで､どのアイデンティティ*4が何の権限を持っているかを把握することができます｡
前任者がキチンと設計したかどうかで､IAMが細かく作成されているか､おおざっぱになっているか､あるいはデフォルトサービスアカウント*5一本槍かは異なります｡
付与されている権限だけでなく､Recommenderという機能により､付与された権限のうち､実際には使われていない権限を把握することができます｡ 裏を返せば､実際に使われている権限も確認できます｡
これらの情報から､以下が把握できます｡
クロスプロジェクトの権限付与
GCPは､プロジェクトをまたいだ権限付与が容易に可能な方式です｡ 異なるプロジェクトに属するサービスアカウントから､調査しているプロジェクトに対する権限*8はコンソールから容易に把握できますが､一方でそのプロジェクトのアカウントが他のプロジェクトへの権限を持っている*9ことを知ることは事前の知識がなければ困難です｡ 後者の権限はBigQueryのDWH/マートなどを集約したプロジェクトを参照する方式で頻発するため､DWH/マートを保有するプロジェクト側での統制が重要となります｡
サービスアカウントキーが発行されている場合
GCPは､サービスアカウントキーのjsonを発行することで､GCPサービス外からGCPの機能を利用することができます｡
調査の過程で､このサービスアカウントキーが発行されていることが発覚した場合は､構成の把握の難易度が格段に上がることを覚悟してください｡ サービスアカウントキーは一般に､GCP外のオンプレミスシステム､SaaSやAWSなどのパブリッククラウドで使われ､事前の知識がなければどこで利用されていることを把握することは困難です｡
｢少なくともまだ利用されているかどうか｣は､使用状況のモニタリングから観測することができます｡*10
まとめ
- GCPコンソールだけでも結構わかることはある｡
- Cloud Asset Inventoryはここしばらく開発が活発なようなので要チェキ｡
- いくら頑張っても知識が無い状態から要件定義､基本設計を導き出すことは基本的に不可能なので有識者を探すこと｡*11
*1:roles/Viewer があればなんとかなります｡
*2:ちょっと前までStackdriverと呼ばれていたもの
*3:期待しない方がいい
*4:ユーザアカウント､サービスアカウント､グループなど
*5:公式リファレンスではデフォルトサービスアカウントはプロダクションでは利用しないことを推奨しています｡ https://cloud.google.com/iam/docs/service-accounts?hl=ja#default
*6:そのユーザとコンタクトを取り､ヒアリングすることで一気に道が開ける可能性はある｡
*7:そのサービスアカウントがアタッチされているコンポーネントを簡単に知る方法はまだわかってない
*8:インバウンドって言えばいいのか?
*9:アウトバウンド?
*10:ロギングに接続元IPも出た気がする
*11:本当に運用に必要なドキュメントが何なのかを考える 近藤 誠司. 運用改善の教科書 ～クラウド時代にも困らない、変化に迅速に対応するためのシステム運用ノウハウ (Japanese Edition) (Kindle の位置No.837). Kindle 版.
