プロジェクト内で事前定義された IAM ロールにユーザーを割り当てる
今回は、こちらをまとめていく。
まず、IAMとは？
GCPリソースに対するアクセス権を取りまとめるサービス。
このIAMを通して、GCPのリソースへアクセスする。
Cloud IAM の仕組み
Cloud IAM では、誰（ID）がどのリソースに対してどのようなアクセス権（ロール）を持つかを定義することにより、アクセス制御を管理します。たとえば、Compute Engine の仮想マシン インスタンス、Google Kubernetes Engine（GKE）クラスタ、Cloud Storage バケットはすべて Google Cloud のリソースです。リソースの整理に使用する組織、フォルダ、プロジェクトもリソースになります。Cloud IAM では、リソースに対するアクセス権を直接エンドユーザーに付与することはありません。複数の権限をロールにまとめて、認証されたメンバーに付与します。
とのこと。
IAMの大事な要素
・メンバー
→ 権限を付与される対象のこと。Googleアカウント、サービスアカウント、Googleグループ、G Suite、Cloud Identityドメイン。
・ロール
→ 権限のコレクション。メンバーにロールを付与すると、ロールに含まれる全ての権限が付与される。
・ポリシー
→ メンバーとロールのセット。
Cloud IAM には、３種類のロールが存在する。
・基本ロール
→ オーナー、編集者、閲覧者のロールが該当する。 これらのロールは、全ての Google Cloud サービスで様々な権限を持つため、使用を控えるべし
・事前定義ロール
→ 基本ロールよりも、細かな権限設定が可能。事前にGCP側で権限の範囲を定めている。
・カスタムロール
→ 事前定義ロールでは、満たせない、より細かな権限設定が可能。
余談だが、GCPのリソース階層についてもまとめる
リソース階層とはなんぞや？
→ リソースの階層。GCPのリソースの構成要素は、組織、フォルダ、プロジェクト、サービスとある。こやつらの階層のこと。
階層としては
組織
↓
フォルダ
↓
プロジェクト
↓
サービス
となる。
注意点として、フォルダは、組織が存在する場合にしか、作成できない。
フォルダはプロジェクトのグループ化の目的があり、部毎にフォルダを作成し、その中でいくつかのプロジェクトを構える。みたいなことも可能。
グループ化して嬉しいのは、一律の権限を複数のプロジェクトに与える、などのシーン。
IAMでは、このリソース階層の考え方が大切。
各リソースに対して、ポリシーを定めることで、効率的に権限設定が可能。
下層のリソースは、上層のリソースに割り当てられた権限を引き継ぐ。
最後に
間違っていたら教えてください。