【共有 VPC】サービスプロジェクトの GCE へサービスアカウントを付与する際の権限
はじめに
こんにちは。
クラウドエースの中野(大)と申します。
今回は Google Cloud の 共有 VPC のサービスプロジェクトの GCE へサービスアカウントを付与する際の権限について説明します。
この記事を執筆しようとした理由
共有 VPC を使用しているお客様から弊社への技術的な問い合わせで、サービスプロジェクトの管理者がサービスプロジェクト上の GCE へサービスアカウントを付与する際にエラーが発生したため、ホストプロジェクト上で、サービスプロジェクトの管理者に「サービスアカウントユーザー」の権限を付与したいとの問い合わせが来ました。
その際の回答について様々な方へ共有したいと思い、本記事を執筆しようと思いました。
共有 VPC とは
まず共有 VPC について軽くおさらいします。
共有 VPC は、組織内の複数のプロジェクトで共通の VPC ネットワークを使用できるようにする機能です。これにより、ネットワークリソースの集中管理と、プロジェクトごとのリソース管理の分離が可能になります。
共有 VPC の権限について
共有 VPC では、ホストプロジェクトが共有 VPC ネットワークを管理し、サービスプロジェクトがそのネットワークを使用してリソースをデプロイします。そのため、両プロジェクトで必要な権限は明確に分かれています。
ホストプロジェクトの権限
ホストプロジェクトは、共有 VPC ネットワーク全体の管理責任を持ちます。主な権限は以下の通りです。
- 共有 VPC の有効化と管理
- 共有 VPC ネットワークの作成、削除、変更
- サブネット、ルート、ファイアウォールなどのネットワークリソースの管理
- サービスプロジェクトの接続と切断
- IAM 権限の管理
- サービスプロジェクトに対する共有VPCネットワークへのアクセス権限の付与
- プロジェクトレベル、または、サブネットレベルでのアクセス制御
ホストプロジェクトの管理者は、組織のネットワークポリシーに基づいて、サービスプロジェクトのアクセスを細かく制御できます。
サービスプロジェクトの権限
サービスプロジェクトは、ホストプロジェクトが提供する共有 VPC ネットワークを使用して、VM インスタンスなどのリソースをデプロイします。主な権限は以下の通りです。
- 共有 VPC ネットワークの使用
- 許可されたサブネット内でのリソースのデプロイ
- 内部 IP アドレスを使用したリソース間の通信
- 自身のリソースの管理
- デプロイした VM インスタンスなどのリソースの起動、停止、削除
- 自身のリソースに対する IAM 権限の管理
サービスプロジェクトの管理者は、ネットワーク設定に影響を与えることなく、独立してリソースを管理できます。
問題点
今回問い合わせであった問題点として、ホストプロジェクト上で、サービスプロジェクトの管理者に「サービスアカウントユーザー」の権限を付与するという点です。
プロジェクト IAM でロールを付与してしまうと、「サービスプロジェクトの管理者がホストプロジェクトで管理している全てのサービスアカウントを利用できてしまう」状態になってしまいます。
そのため、今回の目的である「サービスプロジェクト上の GCE で使用するサービスアカウントのみを使用する」よりも広い権限を付与してしまい、サービスアカウントの最小限の権限を与える原則からは外れてしまいます。
対応策
サービスプロジェクトの管理者へ、ホストプロジェクトで「Compute ネットワークユーザー」、サービスプロジェクトでは「Compute 管理者（または GCE 管理系のロール）」、「サービスアカウントユーザー」権限を付与することでサービスプロジェクト上の GCE へサービスアカウントを付与することが可能です。
ホストプロジェクトの IAM 画面
サービスプロジェクトの IAM 画面
上記の関係性を図で表すと以下のようになります。
ホストプロジェクトとサービスプロジェクトの「サービスプロジェクト管理者」は同一のユーザです。
ホストプロジェクトの「サービスプロジェクト管理者」にはCompute ネットワークユーザー、サービスプロジェクトの「サービスプロジェクト管理者」にはCompute 管理者とサービスアカウントユーザーを付与します。
この権限を付与してサービスプロジェクト上の新規で作成する GCE インスタンスへサービスアカウントが付与できるか確認します。
サービスアカウント（今回は test-instance）を設定し、GCE インスタンスを作成します。
サービスアカウントが付与された GCE インスタンスが作成できていることを確認します。
既存の GCE インスタンスのサービスアカウントが変更できるかも確認してみます。
間違えて GCE インスタンスへデフォルトのサービスアカウントを付与してしまったことを想定してサービスアカウントの変更ができるか確認します。
インスタンスの編集からサービスアカウントをデフォルトのものから「test-instance」へ変更します。
保存をクリックします。
サービスアカウントが「test-instance」へ変更されていることを確認します。
これで既存の GCE インスタンスのサービスアカウントも変更できることが確認できました。
対応策について記載しましたが、今回のお客様からの事例の場合、サービスアカウントはホストプロジェクトで管理されていました。
そのため、ホストプロジェクト側のサービスアカウントに、「サービスアカウント利用者」ロールを付与することで最終的な解決を実施しました。
まとめ
サービスプロジェクトの管理者がサービスプロジェクト上の GCE インスタンスのサービスアカウントを変更する際に付与する権限について執筆してきました。
改めて、共有 VPC 環境下でサービスプロジェクトの GCE インスタンスにサービスアカウントを付与するには、以下の権限設定が必要です。
-
ホストプロジェクト
- サービスプロジェクトの管理者に対して Compute ネットワークユーザー のロールを付与
-
サービスプロジェクト
- サービスプロジェクトの管理者に対して Compute 管理者 または GCE 管理系 のロールを付与
- サービスプロジェクトの管理者に対して サービスアカウントユーザー のロールを付与
これらの権限を付与することで、サービスプロジェクトの管理者は、ホストプロジェクトのネットワークリソースに影響を与えることなく、GCE インスタンスにサービスアカウントを付与できます。
また、記事内でも記載しましたが、サービスプロジェクトの管理者やサービスアカウントには最小限の権限を付与することが推奨されます。
この記事が、共有 VPC 環境における権限設定の理解に役立ちましたら幸いです。
Discussion