テクノロジー
【学習メモ】GCPのIAMについて調べてみた
はじめに
GCPのIAMは、AWSのIAMとはまた別の概念を持っています。
そろそろこんがらがってきたので、GCPのIAMについて思考整理のためにまとめてみました。
IAMについて
Cloud IAMとは
アクセスの
①主体
②アクション
③対象リソース
を指定することができます。
⓵ 主体：ユーザ・グループ・アプリ
⓶アクション：特定の権限・操作
⓷対象リソース：Google Cloudサービス
例えば、Compute閲覧権限ユーザをA君がもらうとすると、以下のようになります。
⓵主体：A君のユーザ
⓶アクション：読み取りの権限・操作
⓷対象リソース：Compute Engineリソース
今回は①と②についてまとめてみます。
①主体
リソースに対してアクションを起こす主体のことを総称してメンバーと呼んでいます。
メンバーには以下の種類があります。
メンバー
Googleアカウント
- Gメールアドレスとの関連付けが可能です。※所謂普通のGoogleアカウントのことです。
- GCPを使用するユーザ（開発者や管理者などなど）を指します。
サービスアカウント
- アプリケーションやVMに属するアカウントの事です。
- アプリの様々な論理コンポーネントを表します。
- GCDKのコード実行するときなどに使用されるアカウントです。
- わかりにくいですがGCP Service Accountを理解するを読んだら理解できました。
◦インスタンス・イメージ・アプリコード内に鍵や認証情報埋め込まなくてよいっていうのがポイントっぽいです。→(・・?
('ω')｡oO(たぶん、AWSのIAMロールに近い感じ…)
Googleグループ
- Googleアカウントとサービスアカウントをグループ化できます。
◦まとめてアクセスポリシーの適応などが可能です。
workspaceドメイン
- 「～.com」のような組織のインターネットドメイン名ごとのアカウントです。
- workspaceにユーザを追加することで、Googleアカウントが作成されます。
Cloud Identity
- Google管理コンソールにて、ユーザとグループが管理できます。
- 50ユーザまで無料ですが、GoogleドキュメントやGoogleドライブなど使用できないサービスもあります。
- workspaceドメインに似てます。
②アクション
特定の権限・操作をまとめたものをロールと呼んでいます。
ロールには以下の3つの種類があります。
ロール
基本ロール
GCP側で準備してくれている役割ごとのロールのことです。
以下の3つがあります。
-
閲覧者
◦読み取り専用
◦既存リソースやデータの表示が可能 -
編集者
◦閲覧者権限含む
◦状態を変更するアクションが可能
◦既存リソースの変更
◦アクセスの変更削除 など… -
オーナー
◦編集者権限含む
◦管理者権限
◦メンバーの追加や削除が可能
◦プロジェクトおよびプロジェクト内のすべてのリソースの権限とロールを管理
◦プロジェクトの課金情報を設定 などなど
事前定義ロール
特定のリソースに対するロールのことです。
GCPリソースへのアクセス権を細かく決められるため、他のリソースへの不正アクセスなどを防ぐことができます。
いくつかあるうちの何個か('ω')ノ
- Compute管理者ロール：Compute Engineリソースに対する全アクション許可
- ネットワーク管理者ロール：ネットワークリソースの作成・削除可能
◦※FWやSSLには適応外✖
ストレージ管理者ロール：ディスク・イメージ・スナップショットの作成・削除可能
◦※プロジェクトのイメージ管理者にプロジェクトの編集者ロールを渡したくないな…って時に使える
カスタムロール
カスタマイズが可能なロールになります。
事前定義ロールよりも自分好みの権限の組み合わせにできます。
多くの企業では、 最小権限モデル が採用されているらしいです。
😺ユースケース🤠
インスタンスオペレーターロールを定義！
ユーザにこのロールを付与することで、「VM起動・停止は可能だが再編成はできない」という権限を持ったユーザを発動！
バインディングとポリシー
バインディング
メンバーとロールの紐づけをバインディングと呼びます。
AWSの時はなかった概念の気もするが、強いて言えばterraform使って構築するときのアタッチメントなんちゃらみたいなやつ…？
バインディングでは条件を決めることができます。
条件でインスタンス名等を指定できます。AWSの IAM Policy的な奴だと思います。
ポリシー
バインディングをまとめたものをポリシーと言います。
誰がどのロールを持つかをまとめたものがポリシーです。
リソースは、上の階層（親）からポリシーを継承となります。
IAMポリシーの階層はGoogle Cloudリソースの階層と同じです。
強さで言うと、「制限の緩い親ポリシー＞制限の厳しいリソースポリシー」になります。
親レベルで付与されたアクセス権を子ポリシーで制限はできないです。
って事で最小限で付与していくのがベストプラクティスになるってことですね('ω')
さいごに（かんそう）
権限の分断などが細かくできるので、複雑には見えますが使いこなすとかなりいい感じに開発・運用ができるなと思いました。
特に大人数でいろんな立場の人がいるプロジェクト等ですとかなりいい感じに思います。
ポリシー継承のIAMの決まりなども複雑なので、GCPのリソース階層とIAMの関係についても今後まとめてみたいと思います。
※本記事は2023年12月時点の内容です。
