Google Cloud の IAM で、開発体制や組織の文化に合わせて検討したこと

システムプラットフォーム部で SRE をやっている id:nabeop です。システムプラットフォーム部を一言で表すと、基盤を横断的に見る部署という感じです。

過去の発表などでもたびたび言及していますが、はてなのいくつかのサービスは AWS 上で構築されており、これまで「クラウドに構築する」は「AWS で構築する」とほぼ同義な世界でした。

ただし、AWS 以外も全く使っていなかったわけではなく、小さなプロジェクトや個人では Google Cloud の利用もありました。また最近は、各サービスで技術選択の多様化が進み「Google Cloud 上でサービスを構築する」という選択肢も十分ありえる状態になってきました。

このため、各サービスで Google Cloud の利用が本格化する前に、安心して使えるように IAM (Identity and Access Management) など環境を整備する必要が出てきました。

今回は、複数の開発チームが性質の異なる複数のサービスを Google Cloud で展開するにあたり、開発速度を落とさずに安心して利用できるような枠組みを考える過程で得られた知見をまとめてみようと思います。

はてなにおける開発体制と文化からの要件

はてなでは、toB 向け、toC 向け、受託開発など性質の異なる複数のサービスを、複数のチームが開発・運用しています。ここで注意することは、例えば A というチームでは X と Y というサービスを開発するなど、必ずしも開発チームとサービスが1対1で対応するわけではありません。

また、はてなで働くエンジニアにアンケートシリーズの僕のエントリにもあるように、オープンネスな文化も大事な要素です。

例えば、あるサービスで使われている技術は、実際に動いている様子も含めて、誰でも参照可能な状態になっています。そこから異なるサービスに技術が輸出され、さらに洗練されていくことは、よく目にする光景です。

さらに、はてなでは各チームに技術選択の裁量と責任が任されており、自身のサービスで最適と思われるサービスや技術スタックを選択できるようになっています。

こういったことを考えると、Google Cloud の環境を整備するにあたっては、以下の3点を実現できることが重要になります。

各開発チームの技術選択を妨げず、自主的に運用できる状態にする
他の開発チームのリソースについて、変更はできないものの、様子を観察できる
案件の性質によっては、限られたメンバーのみがアクセスできるリソースが存在することを考慮する必要がある

Google Cloud における権限の考え方

Google Cloud では、リソースなどのアクセス制御は Cloud IAM で実現されています。こういったリソースへのアクセス権限などについて、企業におけるベストプラクティスが以下のドキュメントで公開されています。

エンタープライズ企業のベストプラクティス | ドキュメント | Google Cloud

ここで紹介されているように、基本的に Google Cloud では組織を頂点とした以下のツリー構造で、リソースが配置されます。

組織 -> フォルダ -> プロジェクト -> GCE などのリソース

このとき各種権限では、基本的に上位のリソースで設定されているロールを引き継ぎます。例えば下記のようなツリー構造になっている場合、example.com 組織で設定されているロールは、Project X にあるリソースにも適用されます。一方で、Folder B に設定されているロールは Project X には適用されません。

Google Cloud では、このロールの継承関係を利用することで、各リソースの権限分離を実現できます。

ただし権限によっては、設定できるリソースレベルが限られていることに注意が必要です。例えば「組織のロール管理者 (roles/iam.organizationRoleAdmin)」は組織のレベルでしか設定できませんが、「ロール管理者 (roles/iam.roleAdmin)」はプロジェクトレベルまで設定できます。

要件を満たすリソースツリーと権限分離

Google Cloud には「ロールの継承」という概念があり、そのロールはフォルダ単位で付与できることがわかりました。この性質を利用することで、次のようなツリー構造を作成できます。

あるフォルダに設定した権限は、そのフォルダ以下のプロジェクトやフォルダに同じロールが適用される
下位のフォルダでさらに強い権限を設定することで、特定の階層から上は参照のみなどの弱い権限でアクセスができる

リソースツリーの中で適切なフォルダに適切な権限を設定することで、「はてなにおける開発体制と文化」の最後に述べた3つの要件は満たせそうです。

ここで問題になってくるのは、Google Cloud におけるリソースのツリー構造の中で、「開発チームと管理者の責任境界をどのように置くか」という点でした。

リソースツリーに責任境界を置く

最終的には下記のようなツリー構造にすることで、前述した3つの要件を満たせると考えました。

このツリーでは、ロールを以下のように設定することが想定されています。

組織のレベルでは、組織を管理するロールのみを設定する
公開可能フォルダでは、基本ロールの「閲覧者 (roles/viwer)」をプロジェクトに対して設定する
秘匿性の高いプロジェクトは、組織の直下に配置する (図の「秘密の案件 A」)
各開発チームに強いロールを設定して、責任境界とする (図のオレンジ色の部分)

オレンジ色の階層に作成するフォルダを「チームフォルダ」と名付け、各開発チーム向けに払い出します。

開発チームは「チームフォルダ」以下のオーナーに

上記のロールを設定することで、責任境界となる「チームフォルダ」より下位のリソースは開発チームがオーナーシップを持ちつつ、先に挙げた3つの要件も満たせます。

開発チームがリソースのオーナーシップを持つということは、具体的には以下を実行できると想定しています。

リソースに対して必要なロールが設定できる
必要に応じてフォルダやプロジェクトを含むリソースを作成できる
サービスアカウントを管理できる

責任境界になるチームフォルダに付与したロール

チームフォルダには、具体的に下記のロールを付与しています。

事前定義ロール
- サービスアカウント管理者 (roles/iam.serviceAccountAdmin)
  - フォルダ管理者 (roles/resourcemanager.folderAdmin)
  - プロジェクト IAM 管理者 (roles/resourcemanager.projectIamAdmin)
- プロジェクト作成者 (roles/resourcemanager.projectCreator)
- プロジェクト削除 (roles/resourcemanager.projectDeleter)
  - プロジェクト移動 (roles/resourcemanager.projectMover)
基本ロール
- オーナー (roles/owner)

Google Cloud のドキュメントでは、基本ロールを極力使わないで、事前定義ロールもしくはカスタムロールを使うことが推奨されています。

しかし、それで開発チームが十分なオーナーシップを持てるのか、いまひとつ自信がなかったため、あえて基本ロールのオーナーを付与しています。これはある程度の運用知見がたまり、本当に必要とされるロールの組み合わせが分かってきたら置き換えることを想定しています。

ロールは Google グループに付与する

ロールを設定する対象は、主に以下の5つから選択することになります。

Google アカウント
サービスアカウント
Google グループ
Google Workspace ドメイン
Cloud Identity ドメイン

はてなでは、全社員に Google アカウントが付与されているため、上記のうち Google アカウント、サービスアカウント、Google グループから選択することになります。

とくにチームフォルダでは、各ロールを付与する対象は個人に紐付いている Google アカウントではなく、開発チームが管理している Google グループを使います。チーム移動などで構成メンバーに変更があった場合に、開発チーム側で Google グループの構成メンバーを変更することで、双方の管理の手間を減らす目的があります。

最後に

今回は、複数のチームによる複数のサービス構築を見据えて、Google Cloud で権限分離を検討したときに考えたことを紹介しました。Google Cloud の運用知見がない状態で検討したので、この内容が正解かどうかに確かな自信はないのが正直なところです。実際に運用することで問題点を洗い出し、より適切な形にしていきたいと思います。

Google Cloud の環境整備では、今回の権限分離のほかに次のような話題もあります。

他の内部ネットワークとの繋ぎ込み
ネットワーク資源の管理
費用管理

このあたりも機会があればエントリにしたいと思っています。

一緒に基盤整備してくれる仲間を募集中！

はてなの SRE では、

複数の異なる性質を持つサービスが使っている全社的な基盤を、よい感じに改善して、各サービスの開発速度を最速にしたい!!
1つのサービスに集中して基盤や運用形態をよい感じに改善して、開発速度を最速にしたい!!

ということを考えて、よりよい基盤構成の検証などをやってます。

我こそは!! という人の応募を待っています。

▶ SRE（Site Reliability Engineer）職転職・中途 – 採用情報
▶ SRE（Site Reliability Engineer）職の新卒採用 – 採用情報

TechWatch