GCP - 基本情報

Reading time: 26 minutes

リソース階層

Google Cloudは、従来のファイルシステムに概念的に似たリソース階層を使用しています。これにより、ポリシーや権限のための特定のアタッチメントポイントを持つ論理的な親/子ワークフローが提供されます。

高レベルでは、次のようになります：

Organization
--> Folders
--> Projects
--> Resources

仮想マシン（Compute Instanceと呼ばれる）はリソースです。リソースはプロジェクト内に存在し、他のCompute Instance、ストレージバケットなどと一緒に存在する可能性があります。

プロジェクトの移行

組織なしでプロジェクトを移行することが可能です。必要な権限はroles/resourcemanager.projectCreatorとroles/resourcemanager.projectMoverです。プロジェクトが他の組織内にある場合、最初にその組織から移動するためにGCPサポートに連絡する必要があります。詳細についてはこちらを確認してください。

組織ポリシー

組織のクラウドリソースに対する中央集権的な管理を可能にします：

• 組織のリソースの使用方法に制限を設定するための中央集権的な管理。
• 開発チームがコンプライアンスの境界内に留まるためのガードレールを定義し、確立する。
• プロジェクトオーナーとそのチームがコンプライアンスを破る心配なく迅速に移動できるように支援します。

これらのポリシーは、組織全体、フォルダー、またはプロジェクトに影響を与えるように作成できます。ターゲットリソース階層ノードの子孫は組織ポリシーを継承します。

組織ポリシーを定義するために、 制約を選択します。これは、Google CloudサービスまたはGoogle Cloudサービスのグループに対する特定の種類の制限です。その制約を希望する制限で構成します。

一般的な使用例

• ドメインに基づいてリソース共有を制限する。
• アイデンティティとアクセス管理サービスアカウントの使用を制限する。
• 新しく作成されたリソースの物理的な場所を制限する。
• サービスアカウントの作成を無効にする。

組織のリソースに対する詳細な制御を提供する多くの制約があります。詳細については、 すべての組織ポリシーサービス制約のリストを参照してください。

デフォルトの組織ポリシー

IAMロール

これらはAWSのIAMポリシーのように、各ロールには一連の権限が含まれています。

しかし、AWSとは異なり、ロールの中央リポジトリはありません。その代わりに、リソースはYプリンシパルにXアクセスロールを付与し、リソースへのアクセス権を持つ人を知る唯一の方法は、そのリソースに対して get-iam-policy メソッドを使用することです。
これは問題になる可能性があります。なぜなら、プリンシパルがどの権限を持っているかを知る唯一の方法は、すべてのリソースに対して誰に権限を与えているかを尋ねることだからです。ユーザーはすべてのリソースから権限を取得する権限を持っていない可能性があります。

IAMには3種類のロールがあります：

• 基本/プリミティブロール、これはIAM導入前に存在したオーナー、エディター、およびビューアロールを含みます。
• 事前定義されたロール、特定のサービスに対する詳細なアクセスを提供し、Google Cloudによって管理されます。多くの事前定義されたロールがあり、それらが持つ権限をすべて確認できます こちら。
• カスタムロール、ユーザーが指定した権限のリストに基づいて詳細なアクセスを提供します。

GCPには数千の権限があります。ロールが権限を持っているかどうかを確認するには、こちらで権限を検索し、どのロールがそれを持っているかを確認できます。

また、こちらで事前定義されたロールを検索 各製品によって提供されます。 一部のロールはユーザーに付与できず、サービスアカウントのみに付与されることに注意してください。
さらに、権限は関連するサービスに付与されている場合にのみ有効になります。

また、カスタムロールが 特定の権限を使用できるかどうかを確認できます。

GCP - IAM, Principals & Org Policies Enum

ユーザー

GCPコンソールにはユーザーやグループの管理はなく、それはGoogle Workspaceで行われます。ただし、Google Workspaceで異なるアイデンティティプロバイダーを同期することは可能です。

Workspacesのユーザーとグループには https://admin.google.com からアクセスできます。

MFAはWorkspacesユーザーに強制できますが、攻撃者はトークンを使用してGCPにcli経由でアクセスでき、MFAによって保護されません（ユーザーが生成するためにログインしたときにのみMFAによって保護されます：gcloud auth login）。

グループ

組織が作成されると、いくつかのグループが作成されることが強く推奨されます。これらのいずれかを管理している場合、組織全体または重要な部分が侵害される可能性があります：

デフォルトのパスワードポリシー

• 強力なパスワードを強制する
• 8文字から100文字の間
• 再利用禁止
• 有効期限なし
• サードパーティプロバイダーを通じてWorkspaceにアクセスしている場合、これらの要件は適用されません。

サービスアカウント

これらは、リソースが持つことができるプリンシパルであり、GCPと簡単に相互作用するためにアクセスできます。たとえば、VMに添付されたサービスアカウントのauthトークンにメタデータからアクセスすることが可能です。
IAMとアクセススコープの両方を使用する際にいくつかの競合が発生する可能性があります。たとえば、サービスアカウントがcompute.instanceAdminのIAMロールを持っている場合でも、侵害したインスタンスにはhttps://www.googleapis.com/auth/compute.readonlyのスコープ制限がかかっている可能性があります。これにより、インスタンスに自動的に割り当てられたOAuthトークンを使用して変更を加えることができなくなります。

これはAWSのIAMロールに似ています。しかし、AWSとは異なり、任意のサービスアカウントは任意のサービスに添付できます（ポリシーを介して許可する必要はありません）。

使用を開始すると、実際にGCPによって自動的に生成されるサービスアカウントがいくつかあります。例えば：

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

ただし、カスタムサービスアカウントを作成してリソースにアタッチすることも可能で、次のようになります：

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

キーとトークン

GCPにサービスアカウントとしてアクセスする主な方法は2つあります：

• OAuthトークン経由：これらはメタデータエンドポイントやHTTPリクエストを盗むことで得られるトークンで、アクセススコープによって制限されます。
• キー：これらは公開鍵と秘密鍵のペアで、サービスアカウントとしてリクエストに署名したり、サービスアカウントとしてアクションを実行するためのOAuthトークンを生成したりすることができます。これらのキーは制限と管理が複雑なため危険です。そのため、GCPは生成しないことを推奨しています。
• サービスアカウントが作成されるたびに、GCPはユーザーがアクセスできないサービスアカウント用のキーを生成します（ウェブアプリケーションには表示されません）。このスレッドによると、このキーはGCPによって内部的に使用され、メタデータエンドポイントがアクセス可能なOAuthトークンを生成するためのアクセスを提供します。

アクセススコープ

アクセススコープは、GCP APIエンドポイントにアクセスするために生成されたOAuthトークンに添付されます。これらはOAuthトークンの権限を制限します。
つまり、トークンがリソースのオーナーに属していても、そのリソースにアクセスするためのスコープがトークンに含まれていない場合、トークンはその権限を（悪用）するために使用できません。

Googleは実際に推奨していますが、アクセススコープは使用せず、IAMに完全に依存することです。ウェブ管理ポータルは実際にこれを強制しますが、カスタムサービスアカウントを使用してプログラム的にインスタンスにアクセススコープを適用することは依然として可能です。

スコープが割り当てられているかどうかは、クエリを実行することで確認できます：

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

前述のscopesは、データにアクセスするために**gcloudを使用してdefaultで生成されたものです。これは、gcloud**を使用する際に最初にOAuthトークンを作成し、それを使用してエンドポイントに連絡するためです。

これらの中で最も重要なスコープは**cloud-platformであり、基本的にはGCP内の任意のサービスにアクセス可能**であることを意味します。

ここにあるすべての可能なスコープのリストを見つけることができますall the possible scopes in here.

gcloudブラウザ資格情報がある場合、他のスコープでトークンを取得することが可能です。次のようなことを行います:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAMポリシー、バインディング、およびメンバーシップ

terraformによって定義されたように、https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iamを使用してGCPでterraformを使用する場合、リソースに対するプリンシパルのアクセスを付与する方法はいくつかあります：

• メンバーシップ: プリンシパルを役割のメンバーとして設定し、役割やプリンシパルに対する制限なしで行います。ユーザーを役割のメンバーとして設定し、同じ役割のメンバーとしてグループを設定し、さらにそれらのプリンシパル（ユーザーとグループ）を他の役割のメンバーとして設定できます。
• バインディング: 複数のプリンシパルを役割にバインドできます。これらのプリンシパルは他の役割にバインドされたり、メンバーであったりすることができます。ただし、役割にバインドされていないプリンシパルがバインドされた役割のメンバーとして設定されると、次回バインディングが適用されると、メンバーシップは消えます。
• ポリシー: ポリシーは権威あるものであり、役割とプリンシパルを示し、その後、これらのプリンシパルは他の役割を持つことができず、これらの役割は他のプリンシパルを持つことができません。そのポリシーが変更されない限り（他のポリシー、バインディング、またはメンバーシップでも）、したがって、ポリシーで役割またはプリンシパルが指定されると、そのすべての特権はそのポリシーによって制限されます。明らかに、プリンシパルにポリシーを変更するオプションや特権昇格の権限（新しいプリンシパルを作成し、新しい役割にバインドするなど）が与えられた場合、これを回避できます。

参考文献

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy