Cloud Identity and Access Management（Cloud IAM）の基本的なコンセプト
- メンバー
- ロール
- ポリシー
- リソースに対してどのようなアクセス権（ロール）を誰（メンバー）に許可するのかを定義する場合、ポリシーを作成して、そのポリシーをリソースに接続します。
たとえば、前述の図の Cloud IAM ポリシーでは、userid@gmail.com で識別されるエンドユーザーを App Engine 管理者ロール（roles/appengine.appAdmin）にバインドしています。このポリシーをプロジェクトに適用すると、そのプロジェクトでの App Engine 管理者ロールがユーザー userid@gmail.com に付与されます。このユーザーは、App Engine でプロジェクト レベルのアプリの構成と設定をすべて表示し、作成または更新できます。
ID に関するコンセプト
- サービス アカウント
サービス アカウントは、個々のエンドユーザーではなく、アプリケーションのアカウントです。Google Cloud にホストされているコードを実行すると、そのコードは指定したアカウントとして実行されます。利用するアプリケーションの個別の論理コンポーネントを表すために必要な数だけ、サービス アカウントを作成できます。 - Google グループを使用すると、ユーザーの集合に対してアクセス ポリシーを簡単に適用できます。
- G Suite ドメイン
- ビジネスに対応した Gmail、ドキュメント、ドライブ、カレンダー
- これまでの Gmail アプリの便利さはそのままに、ビジネス用の管理機能を追加し、広告を非表示にしました。@gmail.com を独自のドメインに置き換えて、[ユーザー名]@example.com や sales@example.com のようなビジネス用のメールアドレスを作成しましょう。
アクセス管理に関する概念
-
プロジェクト内のすべての Cloud Storage バケットへのアクセスを許可するには、個々のバケットごとではなく、プロジェクトへのアクセスを許可します。プロジェクト内のすべての Compute Engine インスタンスへのアクセスを許可するには、個々のインスタンスごとではなく、プロジェクトへのアクセスを許可します。
-
多くの場合、権限は REST API メソッドと 1 対 1 で対応しています。つまり、Google Cloud の各サービスには、各 REST API メソッドに対して関連付けられている権限のセットがあります。そのメソッドの呼び出し元は、そのメソッドを呼び出すための権限を所有している必要があります。たとえば、Pub/Sub を使用し、topics.publish() メソッドを呼び出す必要がある場合は、そのトピックに対して pubsub.topics.publish 権限が必要になります。
-
ロールは権限のコレクションです。ユーザーに直接権限を付与することはできません。代わりに、ロールを付与します。ユーザーにロールを付与すると、そのロールに含まれているすべての権限がユーザーに付与されます。
Cloud IAM ポリシー
Cloud IAM Policy オブジェクトで表現されます。Cloud IAM Policy オブジェクトは、バインディングのリストで構成されます。Binding は、members のリストを role にバインドします。
-
role: メンバーに付与するロール。role は、roles/service.roleName の形式で指定します。たとえば、Cloud Storage には roles/storage.objectAdmin、roles/storage.objectCreator、roles/storage.objectViewer などのロールがあります。
-
members: このドキュメントの ID に関するコンセプトで説明している 1 つ以上の ID で構成されたリスト。メンバータイプは接頭辞で識別できます。たとえば、Google アカウントには user:、サービス アカウントには serviceAccount:、Google グループには group:、G Suite または Cloud Identity ドメインには domain: が付いています。次のサンプルコードでは、メンバー user:ali@example.com、serviceAccount:my-other-app@appspot.gserviceaccount.com、group:admins@example.com、domain:google.com に storage.objectAdmin ロールを付与します（各メンバーには所定の接頭辞が付いています）。user:maria@example.com には objectViewer ロールを付与します。
次のサンプルコードは、Cloud IAM ポリシーの構造を示しています。
{
"bindings": [
{
"role": "roles/storage.objectAdmin",
"members": [
"user:ali@example.com",
"serviceAccount:my-other-app@appspot.gserviceaccount.com",
"group:admins@example.com",
"domain:google.com"
]
},
{
"role": "roles/storage.objectViewer",
"members": [
"user:maria@example.com"
]
}
]
}
サービス アカウント
サービス アカウントのタイプ
- ユーザー管理サービス アカウント
Cloud Console を使用して新しい Google Cloud プロジェクトを作成するときに、プロジェクトで Compute Engine API が有効になっていると、デフォルトで Compute Engine サービス アカウントが作成されます。これはメールアドレスで識別できます。
PROJECT_NUMBER-compute@developer.gserviceaccount.com
- プロジェクトに App Engine アプリケーションが含まれている場合、デフォルトでは、デフォルト App Engine サービス アカウントがプロジェクト内に作成されます。これはメールアドレスで識別できます。
PROJECT_ID@appspot.gserviceaccount.com
- プロジェクト内でサービス アカウントを自分で作成する場合は、サービス アカウントに名前を付けます。次の形式のメールアドレスが割り当てられます。
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
Google が管理するサービス アカウント
例として、メールアドレスで識別できる Google API サービス アカウントが挙げられます。
PROJECT_NUMBER@cloudservices.gserviceaccount.com