こんにちは。SRE部データ基盤チームの塩崎です。ZOZOテクノロジーズではGCPの管理を各プロジェクトのOwnerに任せていた時期が長く続いていましたが、今期から全社的なGCP管理者を立てることになりました。本記事では新米GCP管理者である僕が全社的なGCPの管理をする上で遭遇した事例を紹介します。時には泥臭い方法で、時にはプログラムの手を借りて自動化をし、数々の難題に対処しました。
GCPのリソース階層について
具体的な事例紹介の前に、GCPのリソース階層を説明します。多くのGCP利用者からは、プロジェクトが最上位のリソースであるように見えますが、実はそれ以上の階層が存在します。以下の図をご覧ください。図の通り、プロジェクトの上位リソースとしてFolder、Organizationという2つのリソースが存在します。
Folderはプロジェクトの論理的なまとまりを作るもので、組織の階層構造を反映するのがベストプラクティスとされています。AWS Organizationsを使ったことがある方は、Organizational Unitに近いものだとお考えください。
OrganizationはGCPにおける最上位リソースです。Google Workspaceのドメインと対応しており、両者の間でアカウント情報などが連携されます。ZOZOテクノロジーズの場合は、親会社であるZOZOと共通のGoogle Workspaceドメインに所属しており、それが唯一のOrganizationです。
また、GCPの権限に関する重要な概念として、「継承」というものがあります。上位リソースに対して付与した権限が、自動的に下位リソースにも伝搬するというものです。つまり、最上位リソースであるOrganizationのAdministrator権限があれば、その配下の全てのGCPプロジェクトを操作できます。これ以降のGCP管理者としての業務は、Organization Administrator権限を使って行います。
MyFirstProject大量発生
最初に紹介する事例は、MyFirstProjectの大量発生です。Organization Administrator権限を入手した直後にプロジェクト一覧の画面を見て絶句しました。MyFirstProject、MyProject、QuickStartなどの名前のプロジェクトが約100個ありました。これらのプロジェクトはGCPのチュートリアルを行うためのもので、既に不要になっているものがほとんどでした。
対処
各プロジェクトの作成者に連絡をし、削除を依頼しました。チュートリアル用途がほとんどでしたので、一定の期間に返答がない場合は、GCP管理者側でプロジェクトを削除しました。なお、この当時はまだgcloudコマンドに慣れていなかったため、Webコンソールで1つ1つ、プロジェクトのOwnerを確認していました。
原因
この件の原因の1つは、GCPの公式チュートリアルの中にプロジェクトの作成が含まれていることです。チュートリアルの最後にはプロジェクトの削除について書かれていますが、実際には多くの人が削除を忘れていました。
再発防止
再発防止として、プロジェクト作成権限の見直しを行いました。GCPの初期状態では、Organizationに所属する全員がプロジェクト作成権限（Project Creatorロール）を持ちます。そのため、これを社内で数名のみに絞りました。
なお、この操作によってサポートケースを起票できなくなるという問題が発生してしまったので、同様の対応をする場合は以下の記事も参照ください。
退職者の権限が残っていた
次は、退職者の権限が残っていたという事例です。何気なく各プロジェクトのCloud IAM一覧を見ていたところ、懐かしい名前を発見しました。数ヶ月前に退職した人のアカウントでした。
GCPのアカウント情報はAzure ADとの間でSAML連携されており、退職のタイミングでAzure AD側が無効化されます。そのため、退職後もアクセスできていたということはないのですが、望ましい状態ではありません。
対処
MyFirstProject大量発生の対応と同様にWebコンソールで1つ1つ確認することは非現実的だと考え、退職者の洗い出しバッチを作成することにしました。
ZOZOとZOZOテクノロジーズの従業員情報はKintoneで保管されているので、まずはKintoneから退職者情報を取得します。KintoneのAPIクライアントとして以下のライブラリを使いました。
Cloud IAMの情報はgcloudコマンドで取得しました。プロジェクトレベルの権限は以下のコマンドで取得可能です。コマンドの出力結果がYAMLなので、その出力結果をRubyで処理してKintoneから取得した結果と突き合わせを行いました。
なお、上のコマンドではプロジェクトレベルの権限しかチェックされないことに注意する必要があります。つまり、BigQueryのデータセットや、GCSバケットなどのリソースレベルの権限は見逃されてしまいます。そのため、追加で以下のコマンドの結果と退職者情報の突き合わせを行いました。
以下のように、scopeをOrganization全体にすると、リソースレベルの権限も全て確認できます。
gcloud asset search-all-iam-policies --scope='organizations/<Organization ID>' --query='policy:*'
原因
退職者の権限削除が各GCPプロジェクトの管理者に任されており、運用レベルに「ムラ」が生じていたことが原因でした。退職者管理は、全GCPプロジェクトで共通に行うべき運用作業です。
再発防止
再発防止として、GCP全社管理者で一律して退職者権限を削除するバッチを作成しました。月次でこのバッチを実行し、前月の退職者権限を自動的に削除しています。
GCPのリソース階層（完全版）
最後の事例紹介をする前に、改めてGCPのリソース階層について触れます。実は、この記事の冒頭で説明したリソース階層には一部の情報が不足しています。それは課金系リソースに関する情報です。
課金系のリソースはプロジェクトやサーバーなどとは異なるリソースツリーを持っています。ここで重要なリソースはBilling AccountとPayments Profileの2種類です。これらは同時に作成されることが多いため、同一視されがちですが、厳密には異なるものです。
Billing Accountはプロジェクトで発生した料金の請求先アカウントです。プロジェクトと直接関係を持つのはBilling Accountであり、このリソースはGCPの中にあります。そのため、Organization Administratorの権限でOrganization内の全てのBilling Accountを操作できます。なお、Billing Accountは監査のため削除できません。
一方のPayments Profileは、GCP外のリソースです。全てのGoogleサービスの支払いを管理するリソースで、支払い方法（クレジットカード番号・銀行口座）や請求先住所・氏名などは、このPayments Profileによって管理されています。Billing Accountとは異なり、Payments Profileは削除可能です。
Billing Account大量発生
最後に紹介するのは、Billing Account大量発生です。全社のGCPの請求額を確認しようとCloud Billingの画面を確認したところ、数十個のBilling Accountを発見しました。各Billing AccountのAdministratorに確認をしたところ、MyFirstProjectを作成する際に間違ってBilling Accountを作成してしまったようです。また、この時にPayments Profileも作成してしまったようでした。この誤って作成されたPayments Profileには個人の住所・クレジットカード情報などが登録されていました。
Payments Profileは原則本人しか見えず、加えてクレジットカード情報はマスク化されているものの、組織のGCPで保持すべきでない情報です。なお、幸いにも全てのBilling Accountに紐づくプロジェクトは無料試用枠の中でのみ使われていたため、課金は発生していませんでした。
対処
Billing AccountとPayments Profileで対処法が異なるので、それぞれ説明します。
先の通り、Billing Accountは削除できないという特徴があります。そのため、誤って作成されたBilling Accountに対しては、以下を行いました。Billing AccountはGCP内部のリソースなので、これらの操作は全てOrganization Administrator権限で実行可能です。
- 作成者の権限削除
- 名前を【使用禁止XX】に変更
- Billing Accountの閉鎖
次にPayments Profileを説明します。Payments Profileは削除可能ですが、GCP外のリソースのため、Organization Administrator権限をもってしても削除できません。そのため、1つ1つ、作成した本人から権限を委譲してもらいながら以下の手順に従って削除をおこないました。Payments Profileを削除することで、クレジットカード情報や住所氏名などの個人情報も削除されます。
原因
この原因はMyFirstProject大量発生と同様です。請求アカウントの作成権限が全員に与えられていたことが原因でした。
再発防止
再発防止のため、請求アカウントの作成権限をGCP全社管理者の数人に限定しました。プロジェクト作成権限を持っている数人と同じメンバーです。
まとめ
新米GCP管理者として遭遇した数々の事例を紹介しました。ここ数ヶ月でいくつもの負債を返済し、マイナスをゼロにするため奮闘しました。今期は守りの運用に終始してしまいましたが、来期はもっと攻めの運用をできればと思っています。
ZOZOテクノロジーズではGCPの運用に興味のある方、運用作業を自動化して楽したい方を募集中です。ご興味のある方のご応募お待ちしております。
