GCP IAM 箇条書きまとめ

Google Cloud Identity and Access Management（IAM）を使用して 誰が何をできるかをコントロールします
GCPのお客様はIAMを使用して最小権限を実装し こうした誤りを防ぐことができます GCPの管理レイヤを操作するには ４つの方法があります
ウェブベースのConsole、 SDKとコマンドラインツール、 API、モバイルアプリです
下位層のセキュリティはGoogleが管理します
セキュリティスタックの上位層は 引き続きお客様の管理になります
GoogleはIAMなどのツールを提供して お客様が上位層で任意のポリシーを 実装できるようにしています

VM、Cloud Storageバケット テーブル、BigQueryなどすべてが プロジェクトに整理されます
加えてプロジェクトをフォルダに まとめることもできます
フォルダには他のフォルダも格納できます
組織が使用する全フォルダとプロジェクトは 組織ノードの下にまとめられます
プロジェクト、フォルダ、組織ノードには まとめてポリシーを定義できます
一部のGCPリソースでは 個別にポリシーを定義できます
ポリシーは階層の下位に 継承される
GCPリソースは １つのプロジェクトに属します
プロジェクトはGCPサービスを 使用する際の基本単位です
APIの管理、課金の有効化、 共同編集者の追加と削除などを行います
各プロジェクトは独立した区画であり 各リソースは 1 つの区画にのみ属します
プロジェクトごとに異なるオーナーと ユーザーを作成して個別に管理できます
各GCPプロジェクトに 名前とプロジェクトIDを割り当てます
プロジェクトIDは永続的かつ不変で GCP全体で一意である必要があります
このIDをさまざまなコンテキストで使用して GCPに作業対象のプロジェクトを指示します
プロジェクトには 好きな名前を付けられます
各プロジェクトには固有の プロジェクト番号も割り当てられ さまざまなコンテキストで表示されます
プロジェクトIDは人が読める文字列にします
プロジェクトはフォルダにまとめることができます
フォルダは作業を楽にするためのツールです
フォルダ内のリソースは そのフォルダのIAMポリシーを継承します
フォルダを使用するには 階層の最上位に組織ノードが必要です
社内の全プロジェクトは １つの構造にまとめることができます
ほとんどの企業では リソースの使用状況の確認と ポリシーの適用を一元的に行う必要があります
それを可能にするのが組織ノードです 組織ノードは階層の最上位階層であり 特別な役割を持っています
たとえば 組織ポリシー管理者を指定して 管理者だけがポリシーを変更できるようにします
G Suiteドメインがある場合 GCPプロジェクトは 自動的に組織ノードに属します
そうでない場合は Google Cloud Identityを 使用して作成できます
新しい組織ノードを作成した時点では ドメイン内の全員が引き続き プロジェクトと請求先アカウントを作成できます
新しい組織ノードを作成したら まずこれらの操作を許可する チームメンバーを決定しましょう
組織ノードを作成すれば その下にフォルダを作成して そこにプロジェクトを配置できます
プロジェクトはいつでもフォルダに移せます リソースは親リソースからポリシーを継承します
プロジェクト内のすべてのリソースが ポリシーを継承します
階層の上位で実装されたポリシーが それより下位で付与された アクセス権限を削除することはできません

IAMを使えば特定のリソースへの 操作権限をユーザーに付与できます
IAMポリシーは「誰が」「何を」 「どのリソースに」対して行えるかを定義します
「何を」はIAM役割で定義します IAM役割とは権限の集合です
「誰が」は Googleアカウント、Googleグループ サービスアカウント、G Suite全体、 Cloud Identityドメインのいずれかになります
IAM役割には３種類あります
基本の役割は広範です GCPプロジェクトに適用するとそのプロジェクトの全リソースに適用されます
基本の役割には オーナー、編集者、閲覧者があります
閲覧者はリソースを確認できますが 状態の変更はできません
編集者は閲覧者の権限に加えて リソースの状態を変更できます
オーナーは編集者の権限に加えて リソースの役割と権限を管理できます
オーナーには 支払い / 請求の設定がある
通常 請求管理の担当者には プロジェクトリソースの変更権限は与えません
そのために 課金管理者の役割を付与できます
機密データが含まれるプロジェクトに 複数のメンバーが取り組む場合は注意が必要です
基本の役割では広範すぎるかもしれません
GCP IAMにはよりきめ細かい役割もあります
各GCPサービスには 独自の定義済みの役割があり 役割を適用できる対象が定義されています

Compute Engineの InstanceAdmin役割を持つユーザーは VMに対して特定の操作を行うことができます
たとえば VMの一覧表示、 構成の読み取りと変更、VMの起動と停止です 操作対象のVMは 役割の適用先によって決まります
ここでは 特定のGoogleグループの ユーザー全員がこの役割を持っています
この役割はproject_aの全VMに適用されます
さらにきめ細かい役割が必要な場合は カスタムの役割があります
多くの会社では最小権限のモデルを使って 各メンバーに必要最小限の 権限のみを付与しています
たとえば InstanceOperator役割を定義して 特定のユーザーにCompute EngineとVMの 起動と停止を許可し 再構成は許可しないとします
カスタムの役割を使えばこれを実現できます ただし注意点があります 第一に カスタムの役割を使うことを 明確に決める必要があります
権限の管理が必要になるからです 会社によっては 事前定義済みの役割を選択しています
第二に カスタムの役割を使用できるのは プロジェクトまたは組織レベルのみです フォルダレベルでは使用できません
権限を付与する対象がユーザーではなく Compute Engine VMだとしたら？ その場合はサービスアカウントを使用します
たとえばVMで実行しているアプリのデータを Google Cloud Storageに保管するとします
そのデータへのアクセスは インターネット上の全員に許可するのではなく VMだけに許可します
そこで Cloud Storageに対してVMを 認証するためのサービスアカウントを作成します
サービスアカウントの名前は メールアドレスにします ただし パスワードではなく 暗号鍵でリソースにアクセスします
こちらの例では サービスアカウントにCompute Engineの InstanceAdmin役割が付与されています
VMで実行中のアプリはこのアカウントを使って 他のVMを作成、変更、削除できます
また サービスアカウントの管理も必要です
たとえば Aliceが特定のサービスアカウントで 実行可能な操作を管理するとします
一方 Bobは表示さえできれば十分です サービスアカウントはIDであると同時に リソースでもあるため
IAMポリシーをそれ自体に適用できます サービスアカウントでAliceには編集者の役割を
Bobには閲覧者の役割を付与できます 他のGCPリソースの役割を 付与する場合と同じです
プロジェクト内のVMのグループごとに 異なるIDを付与できます
その結果 グループごとに 異なる権限を管理しやすくなります
また VMを再作成しなくても サービスアカウントの権限を変更できます