このページでは、Identity and Access Management（IAM）のロールと権限、Cloud SQL インスタンスでの使用方法について説明します。
はじめに
このページでは、特に Cloud SQL に関連する IAM の側面について説明します。IAM とその機能の詳細については、Identity and Access Management をご覧ください。特に、IAM ポリシーの管理に関するセクションをご覧ください。IAM を使用すると、Google Cloud プロジェクトのリソースにアクセスできるユーザーを制御できます。リソースに適用される一連のアクセスルールは、IAM ポリシーと呼ばれます。プロジェクトに適用される IAM ポリシーは、ユーザーがプロジェクト内のすべてのリソースに対して行うことができる操作を定義します。
IAM でのメンバーとは「誰」であるかを指します。メンバーは個々のユーザー、グループ、ドメイン、さらには一般大衆であることもあります。メンバーにはロールが割り当てられ、そのロールによってメンバーに Cloud SQL、および Google Cloud 全般での操作を実行する権限が付与されます。各ロールは、1 つ以上の権限をまとめたものです。権限は IAM の基本単位です。各権限により、特定の操作が許可されます。Cloud SQL で使用可能なロールと権限の一覧については、Cloud SQL の IAM ロールと Cloud SQL の IAM 権限をご覧ください。
アカウントを使用して Cloud SQL インスタンスに接続する場合は、アカウントに Cloud SQL > クライアントのロール（roles/cloudsql.client）が必要です。このロールには、接続に必要な権限が含まれています。
アカウントにロールを追加するには、Console で [IAM と管理] > [IAM] ページの順に移動します。ロールに含まれている権限を確認するには、[IAM と管理] > [ロール] の順に移動します。
Cloud SQL は、Cloud SQL と他の Google Cloud プロダクト間の認証にサービス アカウントを使用します。サービス アカウントは credentials を JSON 形式で提供します。これは Console からダウンロードし、さまざまなシナリオで認証に使用できます。
Cloud SQL Auth Proxy での Cloud SQL のロールと権限
Cloud SQL Auth Proxy を使用して Compute Engine インスタンスから Cloud SQL インスタンスに接続する場合は、Compute Engine インスタンスに関連付けられたデフォルトの Compute Engine サービス アカウントを使用できます。
Cloud SQL インスタンスに接続するその他のアカウントと同様に、サービス アカウントには Cloud SQL > クライアントのロールが必要です。
サーバーレス オプションを使用した Cloud SQL のロールと権限
Google Cloud サーバーレス オプションには、App Engine、Cloud Run 関数、Cloud Run などがあります。これらのオプションからのアクセスを認可するには、サービス アカウントを使用します。サービス アカウントは、特定のプロジェクト内のすべての Cloud SQL へのアクセスを許可します。アプリケーションまたは Cloud Run functions の関数を作成すると、このサービスによってこのアカウントが作成されます。アカウントを確認するには、[IAM と管理] > [IAM] ページに移動して、該当するサフィックスを使用して検索します。
| サーバーレス オプション | サービス アカウントのサフィックス |
|---|---|
| App Engine | @gae-api-prod.google.com.iam.gserviceaccount.com |
| Cloud Run functions | @appspot.gserviceaccount.com |
| Cloud Run | compute@developer.gserviceaccount.com |
Cloud Storage での Cloud SQL のロールと権限
Cloud SQL のインポート機能とエクスポート機能は連携して動作します。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。このため、これらのオペレーションに使用するサービス アカウントには、Cloud Storage に対する読み取り権限と書き込み権限の両方が必要です。
- Cloud Storage にデータをインポートし、Cloud Storage からデータをエクスポートするには、Cloud SQL インスタンスのサービス アカウントにプロジェクトで設定された
storage.objectAdminIAM ロールが必要です。インスタンスのサービス アカウント名は、Google Cloud コンソールのインスタンスの [概要] ページで確認できます。 gcloud storage buckets add-iam-policy-bindingコマンドを使用して、バケットのサービス アカウントにこの IAM ロールを付与できます。- IAM ロールと権限の設定については、IAM 権限の使用をご覧ください。
- 詳細については、Cloud Storage の IAM をご覧ください。
IAM グループ認証を使用した Cloud SQL のロールと権限
IAM グループ認証を使用する場合は、グループを作成します。このグループを使用して、Cloud SQL インスタンスへのアクセスとデータベース権限を管理できます。
次の表に、IAM グループ認証の管理に必要なロールを示します。
| アクション | ロール |
|---|---|
| グループを作成、表示、管理する。 |
|
| IAM グループ メンバーシップ変更ログを表示する。 |
|
| プロジェクト レベルで IAM 権限を付与、表示、設定する。 |
|
| フォルダレベルで IAM 権限を付与、表示、設定する。 |
|
管理者は、各グループに Cloud SQL のロールや、個別の Cloud SQL の権限を付与できます。各グループのメンバーはロールと権限を継承します。
Dataplex のインテグレーションに関する Cloud SQL のロールと権限
Dataplex の Cloud SQL メタデータへのアクセス権を付与するには、ユーザーに roles/cloudsql.schemaViewer ロールを付与するか、cloudsql.schemas.view 権限をカスタムロールに追加します。
詳細については、Dataplex Catalog を使用して Cloud SQL リソースを管理するをご覧ください。
プライベート Cloud SQL インスタンスにアクセスする権限
BigQuery などの別の Google Cloud サービスが Cloud SQL インスタンスと通信して、データにアクセスし、プライベート接続でこのデータをクエリする必要がある場合、サービスは Virtual Private Cloud（VPC）内のプライベート IP アドレスではなく内部経路を使用します。VPC レベルの構成、ファイアウォール ルール、ルートポリシー、ピアリングの切断によってトラフィックを制御または制限することはできません。
代わりに、Cloud SQL でインスタンスの構成フラグを使用して、データベースにアクセスするほかの Google Cloud サービスに対して、この内部パスをオンまたはオフにするかどうかを制御します。
権限を制御して取り消す
BigQuery などの別の Google Cloud サービスがプライベート Cloud SQL インスタンスにアクセスしようとすると、サービスは cloudsql.instances.connect IAM 権限を持つ正当な ID を提供する必要があります。
通常、サービスがこれを実現するには、次の 2 つの方法があります。
- ユーザーの認証情報の転送。サービスは、ユーザーの IAM ID を Cloud SQL に転送して、インスタンスにアクセスする権限を評価できます。このシナリオでは、Cloud SQL が正常に接続できるように、ユーザーに十分な IAM 権限が必要です。
サービス アカウントの使用。BigQuery などのサービスは、事前構成されたサービス アカウントを使用して Cloud SQL インスタンスに接続できます。この場合、サービス アカウントに十分な IAM 権限が必要です。
たとえば、BigQuery と Cloud SQL 間の連携接続では、BigQuery Connection API が有効になると、
service-{PROJECT_NUMBER}@gcp-sa-bigqueryconnection.iam.gserviceaccount.comという名前のサービス アカウントが作成されます。このサービス アカウントには、cloudsql.instances.connectとcloudsql.instances.getの 2 つの Cloud SQL 権限があります。BigQuery は、これらの権限を使用して、内部パスを介してプライベート Cloud SQL インスタンスにアクセスします。
この内部パスを使用できる人の権限を制御するには、BigQuery などの Google Cloud サービスが Cloud SQL インスタンスへの接続に使用するユーザーの IAM ID に対して、IAM 権限の付与と取り消しを行うことができます。BigQuery 内での権限の付与と取り消しの詳細については、Cloud SQL へのアクセスの設定をご覧ください。
他のシナリオでの Cloud SQL のロールと権限
Cloud SQL は他の Google Cloud プロダクトやツールと連携します。これらの操作を行うには、シナリオによって異なる特定のロールと権限も必要です。Cloud SQL のドキュメントには、以下の各ケースに対する詳細な要件が記載されています。
- 外部アプリケーションから Cloud SQL に接続する。
- 顧客管理の暗号鍵（CMEK）を使用する。
- VPC Service Controls の管理に必要な IAM ロール
- Google Kubernetes Engine で実行中のアプリケーションから Cloud SQL インスタンスに接続するには、サービス アカウントの JSON 鍵ファイルの Secret を作成する必要があります。
プロジェクトで IAM を使用する
以下のセクションでは、プロジェクトで基本的な IAM タスクを行う方法について説明します。
次のタスクを完了するには、resourcemanager.projects.getIamPolicy と resourcemanager.projects.setIamPolicy の IAM 権限が必要です。
プロジェクト レベルのポリシーにメンバーを追加する
Cloud SQL のロールの詳細については、IAM ロールをご覧ください。
コンソール
- Google Cloud コンソールの [IAM と管理] ページに移動します。
- 上部のバーにある [プロジェクト] プルダウン メニューで、メンバーを追加するプロジェクトを選択します。
- [追加] をクリックします。[プロジェクトへのメンバー、ロールの追加] ダイアログが表示されます。
- [新しいメンバー] フィールドで、アクセス権を付与するエンティティの名前を指定します。
- [ロールを選択] プルダウンで、メンバーに適切なロールを付与します。Cloud SQL リソースに影響するロールは、[プロジェクト] と [Cloud SQL] サブメニューに表示されます。
- [保存] をクリックします。
gcloud
プロジェクト レベルの IAM ポリシーを追加するには、gcloud beta projects add-iam-policy-binding を使用します。
プロジェクトの IAM ポリシーを表示する
コンソール
- Google Cloud コンソールの [IAM と管理] ページに移動します。
- 上部バーにある [プロジェクト] プルダウン メニューで、ポリシーを表示するプロジェクトを選択します。
- プロジェクトの権限を表示するには、次の 2 つの方法があります。
- メンバー別の表示: 個々のメンバーに関連付けられた [ロール] 列を表示して、各メンバーのロールを確認します。
- ロール別の表示: 個々のロールに関連付けられたプルダウンを使用して、ロールを持つメンバーを確認します。
gcloud
プロジェクトの IAM ポリシーを表示するには、gcloud beta projects get-iam-policy を使用します。
プロジェクト レベルのポリシーからメンバーを削除する
コンソール
- Google Cloud コンソールの [IAM と管理] ページに移動します。
- 上部のバーにある [プロジェクト] プルダウン メニューで、メンバーを削除するプロジェクトを選択します。
- 権限が [メンバー] 別に表示されていることを確認し、削除するメンバーを選択します。
- [削除] をクリックします。
- 表示されたオーバーレイ ウィンドウで、[確認] をクリックします。
gcloud
プロジェクト レベルの IAM ポリシーを削除するには、gcloud beta projects remove-iam-policy-binding を使用します。
ベスト プラクティス
IAM を使用するには、他の管理設定と同様、アクティブ管理を有効にする必要があります。他のユーザーがリソースにアクセスできるようにするには、各ユーザーにどのようなロールを与えるか、必ず把握しておく必要があります。プロジェクト管理、使用パターン、組織の所有権が次第に変化し、プロジェクトの IAM 設定の変更が必要になる場合があります。特に、大規模な組織や大人数のグループで Cloud SQL を管理している場合はその可能性が高くなります。アクセス制御の設定の評価や計画を行う際には、次のベスト プラクティスを念頭に置いてください。
アクセス権を付与する際は、最小権限を与えることを原則にします。最小権限の原則は、リソースへのアクセス権を付与するためのセキュリティ ガイドラインです。最小権限の原則に基づいてアクセス権を付与する場合、割り当てられたタスクを実行するために必要なアクセス権のみをユーザーに付与します。
自分が知らないユーザーに
setIamPolicy権限を持つロールを付与しないようにしてください。setIamPolicy権限が付与されたユーザーは、権限を変更してデータを制御できます。setIamPolicy権限があるロールは、オブジェクトとバケットに対する管理権限を委任する場合にのみ使用します。リソースの管理権限を委任してください。管理者権限を持つユーザーがグループから離れても、他のチームメンバーがリソースを引き続き管理できるようにする必要があります。一般に、これを実現するには次の 2 つ方法があります。
- プロジェクトの Cloud SQL 管理者のロールを個人ではなくグループに割り当てます。
- プロジェクトの Cloud SQL 管理者のロールを少なくとも 2 人のユーザーに割り当てます。
次のステップ
- アクセスの制御の詳細を確認する