G-genの小林です。当記事では、Google Cloud（旧称 GCP）の VPC の基本機能をご紹介します。 はじめに VPC ネットワークとサブネット VPC ネットワーク サブネット イメージ図 VPC の作成モード ルート Cloud NAT VPC ネットワークピアリング 共有 VPC その他 VPC の詳細 はじめに Virtual Private Cloud （VPC）は、仮想ネットワークを構築するためのサービスです。Google Cloud の Compute Engine や Google Kubernetes Engine（GKE）といったサービスを使う上で重要です。VPC に所属するサービスをセキュアに使用するためには、VPC の設計が非常に重要になりますので、基本的な VPC の機能を覚えていきましょう！ また当記事では、Google Cloud と Amazon Web Services（以下、AWS）で類似の機能を並べて紹介します。AWSの VPC は知っているけど、Google Cloud の VPC がわからないという方は是非、参考にしてください。 VPC ネットワークとサブネット VPC ネットワーク VPC ネットワーク は、プライベートな仮想ネットワークです。作成された個々のネットワークのことを指し、単にネットワークと呼ばれることもあります。 Google Cloud の VPC ネットワークの最大の特徴は、 複数のリージョンをまたいだグローバルリソース である点です。AWS の VPC は、単一のリージョンに作成するリージョンリソースですが、Google Cloud の VPC ネットワークは、Google Cloud が提供するすべてのリージョンにまたがります。 また AWS では VPC 作成時に IP アドレス範囲を CIDR 形式で指定しますが、Google Cloud では VPC ネットワークは IP アドレス範囲を持ちません。VPC ネットワークの配下に作成されるサブネットが IP アドレス範囲を持ちます。 参考 : VPC ネットワーク サブネット VPC ネットワークの配下には、Compute Engine VM 等のリソースを配置するネットワーク単位である サブネット を作成します。サブネットは、単一リージョン内に作成するリージョンリソースです。サブネットは、リージョン内のすべてのゾーンにまたがっています。 参考 : サブネット イメージ図 VPC ネットワークとサブネットを模式図にすると、以下のようになります。 Google Cloudネットワーク AWS の VPC をご存知の方のために、AWS の VPC とサブネットの関係を表した図も掲載します。 AWSネットワーク VPC の作成モード Google Cloud では、VPC ネットワークの作成時、サブネット作成モードとして、 自動モード と カスタムモード の2つから選択します。 自動モード を選択すると、Google Cloud が提供するすべてのリージョンに、所定の IP アドレス範囲のサブネットが作成されます。検証用途などの利用に最適です。 一方の カスタムモード は、自動でサブネットは作成されません。ユーザー自ら、リージョンや IP アドレス範囲を指定してサブネットを作成します。本番環境で利用する場合は、こちらが推奨です。 参考 : サブネット作成モード ルート Google Cloud では、パケットをルーティングするための経路として ルート を登録します。AWS ではサブネットごとにルートテーブルを紐づけますが、Google Cloud では VPC ネットワークが1つのルートテーブルを持ち、VPC 内のすべての VM がこのルートテーブルを参照します。 デフォルトで、すべてのサブネット同士が互いに通信できるルートと、インターネットへのルートが作成されます。そのほかのルートはユーザー自身で登録する必要があります。 また、それぞれのルートにはプライオリティを設定します。プライオリティの数字が若いルートから、優先的に評価されます。 ルート 参考 : ルート Cloud NAT 外部 IP アドレスを持たないインスタンスがインターネットへのアクセスをするために利用するのが、 Cloud NAT です。Cloud NAT はフルマネージドの NAT インスタンスです。 CloudNAT なお、AWS の場合は NAT Gateway 作成後に、ルートテーブルで NAT Gateway をターゲットとしたルートを追加する必要がありますが、Google Cloud では必要ありません。 参考 : Cloud NAT の概要 VPC ネットワークピアリング VPC ネットワークピアリング は、2つの VPC ネットワーク同士を接続し、内部 IP アドレスでの接続を可能にする機能です。 AWS と同様、ピアリングは VPC ネットワークを 1:1で接続 します。以下のように、直接ピアリングしていない VPC ネットワーク同士はパケットが到達しません（2ホップ制限、もしくは推移的ピアリングの禁止）。 VPCPeering また、ピアリングする VPC ネットワーク配下のサブネットは、IP アドレス範囲が重複してはいけません。 参考 : VPC ネットワーク ピアリング 共有 VPC 通常、VPC ネットワークは1つのプロジェクトに閉じるリソースです。しかし 共有 VPC 機能を使うと、VPC ネットワークを他のプロジェクトに共有することができます。 以下のようなユースケースが考えられます。 ルート、ファイアウォール、Cloud VPN 等のリソースはネットワーク管理者が集中管理したい VM の管理権限を開発チームに与えるが、ネットワークは設定変更させたくない こういった際に共有 VPC を使うことで、セキュアな権限設計や、ネットワークの一元管理が実現できます。 共有 VPC 参考 : 共有 VPC その他 VPC の詳細 以下の記事では、VPC の仕組みを詳細に解説しています。より詳しく知りたい場合は、参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 小林 あゆみ (記事一覧) クラウドソリューション部 営業チーム AWSエンジニアからGoogle Cloud営業に転向 福井からリモートワーク中 趣味はMonkey125でツーリング、Netflix鑑賞、旅行

G-genの杉村です。Google Cloud（旧称 GCP）の Cloud Identity-Aware Proxy （以下、Cloud IAP）についてご紹介します。 IAP とは 料金 VM にアクセスするための踏み台として使う 設定方法 VPC のファイアウォール設定 IAM 権限の付与 アクセス方法 SSH の場合 Google Cloud コンソールから gcloud コマンドから SSH ターミナルソフトウェアから リモートデスクトップ（RDP） Chromebook で IAP Tunnel を作成する方法 IAP とは IAPの概念 Identity-Aware Proxy （IAP、または Cloud IAP）は、Google Cloud（旧称 GCP）が提供する フルマネージドのリバースプロキシ です。フルマネージドですので、利用者は IAP を構築したり、運用、保守をする必要はありません。 図のように、IAP を経由して VPC にある各種リソースへアクセスしたり、IAP Connector というコンポーネントをデプロイすれば、オンプレミスのリソースへのアクセスも中継することができます。 参考 : Identity-Aware Proxy の概要 また、IAP は Cloud Run サービス等でデプロイされた、Web アプリケーションに、簡単に認証機構を実装するためにも利用できます。 参考 : Configure Identity-Aware Proxy for Cloud Run 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog なお、IAP は BeyondCorp Enterprise の1つの要素にもなっています。当記事では BeyondCorp Enterprise には触れませんが、ご興味のある方は以下の記事をご参照ください。 参考 : Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog Google Cloud の IAP には様々な機能がありますが、当記事でご紹介するのは Compute Engine のインスタンス（VM）へ、SSH/RDP ログインのための機能です。 料金 IAP の料金は、原則無料です。 ただし、デバイス制限をかけるなど、詳細なアクセス制御をかける場合は BeyondCorp Enterprise の機能となり、有償となります。詳細は以下をご参照ください。 参考 : Identity-Aware Proxy の料金 VM にアクセスするための踏み台として使う セキュリティ上、Compute Engine VM には、できるだけ外部 IP アドレス（External IP address）を付与せずにおきたいものです。外部 IP アドレスがないインスタンスにログインするためには、踏み台サーバを用意する必要があると思われるかもしれません。 しかし、IAP を使えば、 踏み台サーバは不要 です。 VMログインのためのIAP 図のように、利用者はまずインターネット経由（HTTPS）で IAP へアクセスし、トンネルを作成します。このとき、利用者は Google アカウントで認証します。また IAP を利用できるのは、Identity and Access Management（IAM）で適切なロールを付与された人だけです。 VPC のファイアウォールルールでは、IAP の接続元 IP アドレスである 35.235.240.0/20 からの 22/TCP（SSH）もしくは 3389/TCP（RDP）接続を許可します。 参考 : TCP 転送での IAP の使用 これで、利用者は IAP 経由で外部 IP アドレスを持たない VM にログインすることができます。また、外部 IP アドレスを持っている VM へのログインにも、IAP を利用できます。 設定方法 設定方法は簡単です。以下の2つを実施すれば、IAP が利用できます。 VPC のファイアウォール設定 対象インスタンスの存在する VPC ネットワークのファイアウォールの上り（Ingress）ルールで、 35.235.240.0/20 からの 22/TCP（SSH）もしくは 3389/TCP（RDP）接続を許可します。 IAM 権限の付与 IAP を利用させる Google アカウントやグループに、必要な IAM ロールを付与します。 まず、以下の IAM ロールを、プロジェクトのレベルでアタッチします。 Compute 閲覧者（ roles/compute.viewer ）や Compute OS ログイン（ roles/compute.osLogin ）等の compute.instances.get 権限を持つロール さらに、以下の IAM ロールを、プロジェクトレベルまたは VM の IAP トンネルリソースにアタッチします。 IAP で保護された トンネル ユーザー（ roles/iap.tunnelResourceAccessor ） 手順は、以下のドキュメントを参考にしてください。 参考 : TCP 転送での IAP の使用 - IAP TCP 転送のロールを付与する なお利用できるポート番号を制限したり、 Access Context Manager で定義したアクセスレベルを満たしていることをアクセスの条件として追加することもできます。 また先述の プロジェクトのレベルでアタッチ の意味がピンと来ない場合は、以下の記事をぜひご参照ください。 blog.g-gen.co.jp アクセス方法 SSH の場合 Google Cloud コンソールから Google Cloud コンソール画面からの SSH であれば、 VM のコンソールで SSH ボタンを押すだけです。 コンソールのSSHボタン Google Cloud コンソールでは、IAP が利用可能な条件が満たされていれば、自動的に IAP 経由でアクセスしてくれます。 gcloud コマンドから gcloud コマンドでアクセスする場合も簡単です。インスタンスに外部 IP アドレスが付与されていなければ、gcloud compute ssh コマンドを実行するだけで、自動的に IAP 経由でアクセスしてくれます。 gcloud compute ssh ${INSTANCE_NAME} ※ ${INSTANCE_NAME} はインスタンス名に置き換えてください。 対象インスタンスに外部 IP アドレスが付与されている場合でも、明示的に --tunnel-through-iap オプションをつけることで、IAP 経由でアクセスしてくれます。 gcloud compute ssh --tunnel-through-iap ${INSTANCE_NAME} 参考 : TCP 転送での IAP の使用 - SSH 接続のトンネリング SSH ターミナルソフトウェアから Tera Term / PuTTY 等の、使い慣れた SSH ターミナルソフトウェアから IAP を利用することもできます。 まず、以下のコマンドを実行して、localhost と VM の間に IAP 経由でトンネルを作成します。 gcloud compute start-iap-tunnel ${INSTANCE_NAME} 22 \ --local-host-port = localhost:10022 \ --zone = ${ZONE} ※ ${INSTANCE_NAME} はインスタンス名に置き換え ※ ${ZONE} はインスタンスが配置されているゾーン名に置き換え 例: asia-northeast1-b ※ 例では 10022 ポートだが任意のポートで問題ない この後、localhost:10022 に対して Tera Term / PuTTY 等 から SSH アクセスすることで VM へログインすることができます。ただし、事前に VM へ公開鍵の登録が必要です。 リモートデスクトップ（RDP） リモートデスクトップ（RDP）の場合は、いったんクライアントソフトを使って利用者の PC から IAP までトンネルを作成します。前述の「SSH ターミナルソフトウェアから」と同じ要領です。 gcloud compute start-iap-tunnel ${INSTANCE_NAME} 3389 \ --local-host-port = localhost:13389 \ --zone = ${ZONE} ※ ${INSTANCE_NAME} はインスタンス名に置き換え ※ ${ZONE} はインスタンスが配置されているゾーン名に置き換え 例: asia-northeast1-b ※ 例では 10022 ポートだが任意のポートで問題ない このコマンドを実行することで、ローカル PC と IAP の間でトンネルが作成されます。この状態でローカルの 13389 ポートへアクセスすると、IAP へ通信がルートされます。 RDP ツールを開いて localhost:13389 へアクセスすれば、インスタンスへ RDP できます。 参考 : TCP 転送での IAP の使用 - RDP 接続のトンネリング Chromebook で IAP Tunnel を作成する方法 お使いの端末が Chromebook の場合、IAP を利用してトンネルを作成し、SSH や RDP を行う方法について、以下の記事もご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）の Identity and Access Management （略称 IAM）は Google Cloud のアクセス制御を司る仕組みです。本記事では、IAM の基本的な仕組みを解説し、詳細な仕様を解き明かしていきます。 IAM とは ID（アカウント） Google Cloud におけるアカウント管理 AWS の IAM ユーザーとの違い Google アカウント Google グループ サービスアカウント IAM の仕組み IAM とリソースの関係 継承 ロールバインディング（role bindings） 許可と拒否 プリンシパルアクセス境界ポリシー IAM ポリシーの構造 gcloud コマンドによる許可ポリシー編集 IAM ロール IAM ロールとは 基本ロール 事前定義ロール カスタムロール ロールの持つ権限 ロールの探し方 トラブルシューティング 新しい基本ロール サービスアカウント サービスアカウントとは サービスアカウントの利用 サービスアカウントキーの注意点 サービスアカウントの権限借用 サービスエージェント PAM による特権管理 AWS IAM との比較と連携 概要 ID（IAM ユーザー） 概念の違い 用語の違い AWS IAM と Google Cloud IAM の連携 IAM とは Identity and Access Management （IAM）とは Google Cloud リソースに対するアクセス制御を司る仕組みです。 IAM は、Google Cloud リソースに対して、 誰が、どういう条件で、何をできるか を管理します。 ここでの リソース とは、Compute Engine の VM や BigQuery のテーブルなど、Google Cloud のオブジェクトの1つ1つを指しています。これらに対する操作権限を定義する仕組みが IAM です。 参考 : IAM の概要 ID（アカウント） Google Cloud におけるアカウント管理 IAM を理解するには Google Cloud における ID 管理（アカウント管理）を理解する必要があります。 Google Cloud の管理コンソールにログインしたり CLI ツールを実行するためのユーザーアカウントは、Google Cloud では Google アカウント と呼ばれます。 管理用アカウントとして、無償の Gmail アカウントを使うことも、Google Workspace（旧 GSuite）や Cloud Identity といった仕組みで集中管理されたアカウントを使うこともできます。 AWS の IAM ユーザーとの違い Amazon Web Services（以下、AWS）をご存知の方のために、Google でのアカウント管理と、AWS の IAM ユーザーとの違いをご紹介します。 AWS における ID は IAM ユーザー と呼ばれ、 AWS アカウント（テナント）の中で管理されます。つまり AWS では、IAM ユーザー自体もクラウドリソースです。一方の Google Cloud では、アカウントはクラウドリソースではなく、Google Cloud から分離されており、Google Workspace や Cloud Identity といった別サービスで管理されます。 ですから、既に Google Workspace を使っている場合、Google Workspace のユーザーアカウントをそのまま Google Cloud の管理用アカウントとして利用できます。 Google Workspace を使っていない場合は、Cloud Identity というサービス（Free エディションでは50アカウントまで無償）で 組織 を作り、アカウントを管理することができます。 ID 管理の違い Google アカウント Google Workspace でも Cloud Identity でも、アカウント名は john@example.com のようにメールアドレス形式です。 Google アカウントは 1人に対して1個ずつ 、発行されることが原則です。複数人で使い回す共用アカウントを作成してしまうと、「パスワードの漏洩」「インシデントの際に監査ログから実行者が特定できない（それによる内部犯に対する抑止力低下）」などのリスクがあります。 なお、個人の Google アカウント（Gmail アカウント）も Google Cloud 用アカウントとして権限を持たせることが可能です。 ただし企業で Google Cloud を利用する場合は、無償アカウントではなく、 Google Workspace か Cloud Identity の利用が強く推奨 されます。無償 Google アカウントだと、グループによる権限管理や、組織のポリシーなどの強力なセキュリティ機能が利用できないためです。 Google アカウントについての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp Google グループ Google Workspace か Cloud Identity では、 Google グループ （または単に グループ ）を作成して、アカウントをグループに所属させることができます。 グループは admin-grp@example.com のようにメールアドレス形式であり、アカウントと同様に、Google Cloud リソースに権限を紐づけることができます。なおグループは、Google Workspace においてはメーリングリストとしても利用できます。 グループは、Google Workspace（Cloud Identity）の管理コンソール（ https://admin.google.com/ ）や、Google Workspace の「Google グループ」画面（ https://groups.google.com/ ）で管理できるほか、適切な権限を持っていれば Google Cloud コンソールから管理することも可能です。 参考 : グループを作成し、グループ設定を選択する 参考 : Google Cloud コンソールで Google グループを作成して管理する サービスアカウント Google Cloud には サービスアカウント という概念があります。 サービスアカウントは、Google アカウントとは異なり、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud の各種サービスを操作する際は、サービスアカウントに権限を持たせて、サービスアカウントの認証情報で認証・認可を行います。 また、サービスアカウントはGoogle アカウントとは異なり、 Google Cloud リソース です。サービスアカウントはいずれかの Google Cloud プロジェクト内に、リソースとして作成されます。 サービスアカウントの詳細については後述します。 参考 : サービス アカウントの概要 IAM の仕組み IAM とリソースの関係 Google Cloud の IAM で最も重要なのは、 IAM 権限はプリンシパル（主体）とリソースの間に紐づくものである という点です。 リソースとIAMの関係 Google Cloud では、「誰が（Googleアカウント、グループ等。総称してプリンシパルと呼ばれる）」「何をできるか（IAM ロール）」という権限設定情報を、 リソースが持ち ます。個々のリソースが持つこの権限設定を、 IAM ポリシー といいます。 リソースとは Compute Engine VM や、BigQuery データセットなどを指します。Google Cloud プロジェクトもリソースですし、組織もリソースである点に注意が必要です。 後に詳しく記述しますが、一方の AWS では、個々の プリンシパルが 、「何に対して」「何をできるか」という権限設定情報を持ちます。つまり、 主語は IAM ユーザーなどの主体 です。ここが Google Cloud と AWS の大きな相違点です。 継承 上位のリソースに権限を紐づけると、下位のリソースに 継承 （inherit）されます。 例えば、 Google Cloud 組織 のトップノード（組織ツリーの最上位のこと。ルートとも言う）に対して、「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」という権限を紐づけたとします。このとき XXX@example.com さんはその組織の配下にある全てのリソース（フォルダ、プロジェクト、VM インスタンスや BigQuery データセット）にオーナー権限を行使することができます。 一方で、あるプロジェクトに対して「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」という権限を紐づけると、XXX@example.com さんはそのプロジェクト配下にある全てのリソース（VM インスタンスや BigQuery データセット）にオーナー権限を行使することができますが、他のプロジェクトに対しては権限が及びません。 継承 また例えば、ある VM インスタンスにオーナー権限を付与すると、XXX@example.com さんは その VM にだけオーナー権限を行使でき ます。他のリソースを操作したり閲覧することはできません。 この仕組みを理解できれば、 何にどんな権限付与すると、どこまで効果が及ぶのか を理解できます。 参考 : リソース階層を使用したアクセス制御 Google Cloud の組織の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp ロールバインディング（role bindings） Google Cloud の IAM では、前述のように、リソースに対して、誰が何をできるかを設定します。例えばあるプロジェクトに対して「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」のように、権限を紐づけます。この紐づけを ロールバインディング （role bindings）、または単にバインディングと呼びます。binding とは、「紐づき」「結合」といった意味の英単語です。 あるリソースには、複数のロールバインディングを設定できます。例えば、あるプロジェクトに、以下のように複数のバインディングを作成できます。 あるプロジェクトのバインディング一覧 プリンシパル ロール XXX@example.com オーナー（ roles/owner ） YYY@example.com Compute 管理者（ roles/compute.admin ） YYY@example.com ストレージ管理者（ roles/storage.admin ） Google Cloud コンソールで、あるプロジェクトを選択している状態で「IAM と管理 > IAM」画面へ遷移すると表示される一覧は、そのプロジェクトのバインディングの一覧です。ここに設定されたバインディングは、そのプロジェクトの配下にあるすべてのリソースに継承されます。 あるプロジェクトのバインディング一覧 許可と拒否 Google Cloud の IAM では、すべてのリソースは、デフォルトで すべてのアカウントからの操作を拒否 します（ 暗黙の Deny ）。リソースの IAM ポリシーに対してバインディングを追加することで、プリンシパルに対して、アクション実行の 許可 を明示的に与えることができます（ 明示的な Allow ）。 また、 拒否ポリシー （Deny policies）を IAM ポリシー（許可ポリシー）とは別に作成することで、 明示的な Deny を設定することが可能です。ポリシーの評価順は「 明示的な Deny > 明示的な Allow > 暗黙の Deny 」であり、明示的な Deny が最も強いです。 そのためポリシー設計時は、基本的には 「明示的な Allow」を付与するかしないで管理することを基本 とし、どうしても強い権限で拒否したいときだけ、明示的な Deny を使う、といった手法が良いでしょう。 拒否ポリシーは強力なため、安易に使うと後から修正が難しくなる場合があります。拒否ポリシーの設定は必須ではありません。原則はまず許可ポリシー（IAM ポリシー）だけでアクセス制御を設計するよう検討してください。 拒否ポリシーの詳細については以下の記事で解説しています。 blog.g-gen.co.jp プリンシパルアクセス境界ポリシー プリンシパルアクセス境界ポリシー （Principal access boundary policies）は、許可ポリシーと拒否ポリシーに続く3つ目のポリシーです。 自組織のアカウントが、他の Google Cloud 組織のリソースにアクセスできないよう制限をかけることができます。設定は必須ではありません。詳細は、以下の記事を参照してください。 blog.g-gen.co.jp IAM ポリシーの構造 IAM ポリシー（許可ポリシー）の構造もご紹介します。 全てのリソース（組織、フォルダ、プロジェクト、VM インスタンスや BigQuery データセット）は 許可ポリシー を1つだけ持っています。許可ポリシーは、単に IAM ポリシーと呼ばれることもありますが、AWS の IAM ポリシーとは全く別物のため、注意が必要です。 許可ポリシーの構造 許可ポリシーは 1つのリソースが1つだけ 持っています。許可ポリシーはその中に、複数のロールバインディング（または単にバインディング）を持つことができます。 バインディングは「 誰が （Google アカウントやグループ、サービスアカウント等。総称してプリンシパルやメンバーと呼ばれる）」「 何を （IAM ロール）」「 どういう条件のときに （condition）」実行できるのか、という情報を持ちます。 上記の図では、 it-grp@example.com は、組織とその配下のすべてのリソースに対して、オーナー（ roles/owner ）ロールの権限を持ちます。また、 john@example.com は、instance-01 に対してのみ、コンピュート管理者（ roles/compute.admin ）の権限を持ちます。条件（condition）の記述に従い、2025年4月30日に権限は無効になります。 あるリソースの IAM ポリシーを JSON フォーマットで出力すると、以下のようになります。 { " bindings ": [ { " members ": [ " user:jie@example.com " ] , " role ": " roles/resourcemanager.organizationAdmin " } , { " members ": [ " user:divya@example.com ", " user:jie@example.com " ] , " role ": " roles/resourcemanager.projectCreator ", " condition ": { " title ": " Expires_July_1_2022 ", " description ": " Expires on July 1, 2022 ", " expression ": " request.time < timestamp('2022-07-01T00:00:00.000Z') " } } ] , " etag ": " ******** ", " version ": 1 } このように、1つの許可ポリシーの中に、配列で複数のバインディングが入っています。バインディングの中には、どういう条件（condition）で誰が（メンバー）何をできる（IAM ロール）のかが記述されている、ということが分かります。 参考 : 許可ポリシーについて gcloud コマンドによる許可ポリシー編集 ここまで分かれば、コマンドラインツール gcloud で IAM 権限を付与するときは、以下のようにする理由が分かるでしょう。 プロジェクトレベルで IAM 権限を付与するとき gcloud projects add-iam-policy-binding my-project-id --member =' user:test-user@gmail.com ' --role = roles/resourcemanager.projectCreator ` VM インスタンスに IAM 権限を付与するとき gcloud compute instances add-iam-policy-binding my-instance --zone = asia-northeast1-b --member =' user:test-user@gmail.com ' --role =' roles/compute.securityAdmin ' 上記のコマンドでは、各リソースの許可ポリシーに対して add-iam-policy-binding をすることで、バインディングを追加しているのです。 IAM ロール IAM ロールとは IAM ロール とは、Google Cloud リソースへのアクションに対する許可権限をまとめた、 権限セット です。AWS にも「IAM ロール」という用語がありますが、まったく別物ですので、注意が必要です。 ほんの一部の抜粋ですが、Google Cloud の IAM ロールには、以下のようなものがあります。 名称 ID 権限の内容 オーナー roles/owner ほとんどの Google Cloud リソースに対する編集・読み取り Compute 管理者 roles/compute.admin 多くの Compute Engine リソースに対する編集・読み取り ストレージ管理者 roles/storage.admin Cloud Storage バケットやオブジェクトに対する編集・読み取り Storage オブジェクト閲覧者 roles/storage.objectViewer Cloud Storage オブジェクトのデータやメタデータに対する読み取り 上記のようなロールを、許可ポリシーにおいてプリンシパルと紐づけることで、プリンシパルはリソースに対して、ロールに定義された権限を持つことができます。 大きく分けて、IAM ロールには以下の3種類があります。 種類 概要 基本ロール オーナー、編集者、閲覧者の3つ。広範な権限を持つロール 事前定義ロール 特定の Google Cloud サービスに限定された権限を持つロール カスタムロール ユーザーが独自に定義できるロール 参考 : ロールと権限 基本ロール 基本ロール は、オーナー、編集者、閲覧者の3つを指します。基本ロールは、多くの Google Cloud サービスに対して広い権限を持ちます。 オーナー （ roles/owner ）は、ほとんどの Google Cloud サービスに対して、編集や読み取りの権限を持っています。プロジェクトに対してプリンシパルをオーナーロールとして紐づけると、プリンシパルはプロジェクトやその配下のリソースに対して、ほとんどの操作を実行できるようになります。また、リソースの IAM ポリシーを編集する権限もあります。 編集者 （ roles/editor ）は、オーナーと同様、ほとんどの Google Cloud サービスに対して、編集や読み取りの権限を持っています。ただし、IAM ポリシーの編集権限を持たないため、オーナーよりは権限範囲が狭くなります。 閲覧者 （ roles/editor ）は、ほとんどの Google Cloud サービスに対する読み取り権限を持ちます。リソースの状態を変更する権限は持ちません。ただし、Cloud Storage や BigQuery など、機密情報を持ち得るリソースのデータも読み取ることができるため、広い権限範囲を持つことに変わりはありません。 このように基本ロールは、広範な権限を持つため、 最初権限の原則 に従うと、本番環境ではできるだけ利用を控えたほうがよい場合もあります。 参考 : ロールと権限 - 基本ロール 事前定義ロール 事前定義ロール は、Google によって事前定義された、Google Cloud サービスごとのロールです。以下のようなロールが当てはまります。 名称 ID 権限の内容 Compute 管理者 roles/compute.admin 多くの Compute Engine リソースに対する編集・読み取り ストレージ管理者 roles/storage.admin Cloud Storage バケットやオブジェクトに対する編集・読み取り Storage オブジェクト閲覧者 roles/storage.objectViewer Cloud Storage オブジェクトのデータやメタデータに対する読み取り Cloud Run 管理者 roles/run.admin Cloud Run リソースに関するすべての操作 Cloud Run デベロッパー roles/run.developer Cloud Run リソースのデプロイ、閲覧など 事前定義ロールは多くの場合、Google Cloud サービスごとに定義されており、管理者、開発者、閲覧者のロールが容易されていることがほとんどです。本番環境できめ細かい権限管理を行うには、事前定義ロールを使うことが一般的です。 参考 : ロールと権限 - 事前定義ロール カスタムロール カスタムロール は、ユーザーが独自に定義できるロールです。きめ細かい権限管理が必要な場合で、適切な事前定義ロールが存在しない際は、ユーザー独自のロールを定義することができます。 カスタムロールは組織またはプロジェクトに所属するリソースであり、ロールを作成した組織またはプロジェクトにのみ付与できます。 参考 : ロールと権限 - カスタムロール ロールの持つ権限 ロールの中には、 権限 （permissions）が定義されています。例えば、Compute 管理者（ roles/compute.admin ）ロールには、以下のような権限が含まれています。 compute.instances.create compute.instances.get compute.instances.list compute.instances.delete compute.instances.start compute.instances.stop ロールに含まれる権限により、そのロールを付与されたプリンシパルが実行可能なアクションが決まります。 ロールの探し方 事前定義ロールの一覧は、以下のリファレンスドキュメントに記載されています。一連のリファレンスドキュメントでは、Google Cloud サービスごとに IAM ロールが整理されており、またロールが持つ権限（permissions）も記載されています。 参考 : IAM roles and permissions index また各 Google Cloud サービスの公式ガイドには、そのサービスに関連する IAM ロールのドキュメントが用意されています。こちらには、上記のリファレンスよりも詳しいユースケースなどが記載されている場合があります。 参考 : Compute Engine IAM のロールと権限 参考 : Cloud Storage に適用される IAM のロール 参考 : Cloud Run IAM roles また、Google Cloud コンソールの「IAM と管理 > ロール」画面でも、基本ロール、事前定義ロール、カスタムロールの一覧を確認できます。この画面では、ロールの名称、ID、持っている権限を確認することができます。 参考 : Google Cloud コンソール - IAM と管理 > ロール トラブルシューティング Google Cloud リソースへの操作時に権限不足（Permission denied）で操作が失敗した場合は、多くの場合、足りない権限がエラーメッセージに記載されます。 前述のドキュメントを使って、必要な権限を持つロールを探し出して、プリンシパルに付与することで対処します。 以下の記事も参考にしてください。 blog.g-gen.co.jp 新しい基本ロール 2025年5月現在ではプレビューですが、3つの基本ロールが新しいものに刷新されます。将来的には、これらの新しい基本ロールが標準になります。 名称 ID 権限の内容 管理者 roles/admin ほとんどの Google Cloud サービスに対する編集や読み取り 書き込み roles/writer ほとんどの Google Cloud サービスに対する編集や読み取り。ただし IAM 編集を除く 読み取り roles/reader ほとんどの Google Cloud サービスに対する読み取り 参考 : ロールと権限 - 基本ロール 従来の基本ロールと、新しい基本ロールでは、権限の内容はほとんど同じですが、微妙な違いがあります。詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp なお、プレビュー段階のサービスや機能は、サポートや SLA の対象外であるほか、一般公開（GA）までに仕様が変更される可能性があるため、本番環境での利用は推奨されません。新しい基本ロールが一般公開されるまでは、本番環境での利用は控えることが推奨されます。 詳細は以下の記事も参照してください。 blog.g-gen.co.jp サービスアカウント サービスアカウントとは サービスアカウント とは、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud APIs を利用する際は、サービスアカウントを使って認証・認可を行います。サービスアカウントは Google アカウントとは異なり、Google Cloud プロジェクトの中に作成するクラウドリソースです。 サービスアカウントはメールアドレスの形式の名称を持ちます。以下は、サービスアカウント名の例です。 my-service-account@my-project-id.iam.gserviceaccount.com 参考 : サービス アカウントの概要 サービスアカウントの利用 プログラムから API 経由で Google Cloud サービスを操作する際は、以下のいずれかの方法で、サービスアカウントの認証情報を使って認証します。 サービスアカウントキー（JSON 形式等）を読み込ませる プログラムが動作する実行環境（VM 等）にサービスアカウントをアタッチする 前者の方法は、サービスアカウントの秘密鍵を JSON 形式でダウンロードし、実行環境に配置して、それをプログラムから読み込ませる方法です。 後者の方法は、プログラムの実行環境が Google Cloud 環境である場合にのみ使えます。Compute Engine VM や Cloud Run サービス、Cloud Functions 関数などにはサービスアカウントを アタッチ することができます。Cloud SDK（クライアントライブラリ）や gcloud コマンドは、認証情報を明示的に指定しなければ、自動的に実行環境にアタッチされたサービスアカウントの認証情報を利用します。 参考 : サービス アカウントとして認証する サービスアカウントキーの注意点 サービスアカウントキーを利用するプログラムの実行環境が Google Cloud 環境であれば、前掲の2つの方法のうち、 後者の方が強く推奨 されます。 サービスアカウントキーは JSON 形式のテキストファイルであり、漏洩の危険性があります。キーファイルが漏洩すれば、サービスアカウントが持つ権限を自由に行使して、Google Cloud 環境への侵害が可能になってしまいます。 後者のサービスアカウントをアタッチする方法であれば、キーの漏洩はありません。 参考 : 他に有効な方法がない場合にサービス アカウント キーを使用する また、組織のポリシー機能により、サービスアカウントキーの発行自体を禁止させることも可能です。以下の記事も参照してください。 blog.g-gen.co.jp サービスアカウントの権限借用 サービスアカウントの応用技として、 権限借用 があります。 他のプリンシパル（Google アカウントや他のサービスアカウント）からサービスアカウントの権限を借用して Google Cloud API を実行することが可能です。詳細は以下の記事も参考にしてください。 参考 : サービス アカウントに有効期間の短い認証情報を作成する 以下の記事では Terraform のセキュアな利用のためにサービスアカウントからの権限借用を活用する例を紹介しています。 blog.g-gen.co.jp サービスエージェント サービスエージェント は、Google Cloud サービスが内部的に用いる、特別なサービスアカウントです。プロダクトの API を有効化したときなどに自動的に作成されるため、ユーザーが意識することはあまりありませんが、初期設定時や仕組みの構築の際に、サービスエージェントに対して権限の付与が必要になることがあります。 参考 : Service agents サービスエージェントについては、以下の記事で詳細に解説しています。 blog.g-gen.co.jp PAM による特権管理 Privileged Access Manager （PAM）は、承認フローを通して時限付きの権限管理をするための仕組みです。IAM の1機能として無料で提供されています。 所定の承認者が承認したときに作業者に IAM 権限が付与され、設定時間が経過すると、権限が自動的に剥奪されます。「ジャスト・イン・タイム」な権限管理が可能になる仕組みです。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp AWS IAM との比較と連携 概要 この章では、Google Cloud の IAM の仕組みをより正しく理解するため、AWS の IAM との違いに着目して解説します。また、AWS との IAM の連携方法についても紹介します。 AWS を利用したことがなく、これから利用する予定も無い方は、読み飛ばしても問題ありません。 ID（IAM ユーザー） マネジメントコンソールにログインしたり、 CLI ツールを実行するための ID は、 AWS では IAM ユーザー と呼ばれ、 AWS アカウント（テナント）の中で管理されます。 Google Cloud の ID が、Google Cloud とは分離されており、Google Workspace や Cloud Identity で管理されることとは対照的です。 概念の違い AWS IAM では IAM ポリシーで権限セット（できること）を定義し、それを 権限主体 （IAM ユーザーやグループ。総称して プリンシパル ） に紐づけ ます。 別の言葉で言うと、「どのリソースに対して」「何ができるか」という権限定義を 人に 紐づけるのです。 これは Google Cloud の IAM が、「誰が」「何をできるか」を リソースに 紐づけるのとは考えが異なります。 用語の違い IAM ポリシー、IAM ロールといった用語は両クラウドで共通していますが、意味は大きく異なっています。混同しないように気を付けましょう。 意味 AWSでの用語 Google Cloud の用語 権限セット IAM ポリシー IAM ロール 権限を実行する IAM 主体（人間） IAM ユーザー Google アカウント 権限を実行する IAM 主体（サービス） IAM ロール サービスアカウント IAM 主体をまとめるグループ IAM グループ Google グループ 個々のリソースが持つ権限設定 (対応概念なし) IAM ポリシー AWS IAM と Google Cloud IAM の連携 Google Cloud の IAM には Workforce Identity および Workload Identity という仕組みがあります。これらの仕組みでは、OpenID Connect（OIDC）や SAML 2.0 を使って、外部の ID プロバイダ（IdP）と Google Cloud の IAM を連携させることができます。 人間のユーザー向けの連携機能が Workforce Identity、プログラムなどワークロード向けの連携機能が Workload Identity です。 これらの仕組みを使うと、Google Cloud 側から AWS の IAM Role を信頼することで、Google Cloud への API 実行を認可することができます。 詳細は以下を参照してください。 参考 : ワークロードの ID 参考 : Workforce Identity の連携 また、以下の当社記事で実際に AWS から Workload Identity によって Google Cloud へ認証・認可させた実例を紹介しています。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it