Google Cloud のアクセスに関する問題のトラブルシューティングに使用するユースケース

Last reviewed 2022-09-29 UTC

このドキュメントでは、Google Cloud ツールを使用して、Google Cloud リソースへのアクセスに関連するユースケースをトラブルシューティングする方法について説明します。このドキュメントでは、アプリケーションへのエンドユーザーアクセスのトラブルシューティング方法について説明します。このドキュメントは、Google Cloud でのポリシーとアクセスの問題に関するトラブルシューティングに精通していることを前提としています。トラブルシューティングポリシーとアクセスの問題のドキュメントには、アクセスポリシーを適用できる Google Cloud サービスと、Google Cloud が提供するトラブルシューティングツールが記述されています。

トラブルシューティングのアプローチ

アクセス関連の問題のトラブルシューティングを行う最初のステップは、トラブルシューティングの方法を決定することです。次の図は、アクセスの問題をトラブルシューティングする方法の一つをフローチャートで示しています。このフローチャートは、トラブルシューティングを完了するための適切な権限があるか、必要な権限を持ったユーザーと連携できることを前提としています。

アクセスに関する問題のトラブルシューティングの一つのフローチャート。

この図は、次のステップの概要を示しています。

Google Cloud コンソールと Cloud Shell でユーザーアクセスを確認します。すべてのアクセスが拒否された場合は、監査ログでエラーの重大度のエントリを確認します。
1. エラーの重大度のエントリがある場合は、必要な権限を確認します。
  1. アクセスの問題解決に必要な権限を付与できる場合は、問題を解決します。
  2. アクセスの問題を解決できない場合は、Cloud カスタマーケアにお問い合わせください。
2. エラーの重大度のエントリがない場合は、カスタマーケアにお問い合わせください。
アクセスに問題がない場合は、ネットワークに問題がないかどうかを確認します。ネットワークに問題がある場合は、問題を解決します。
ネットワークに問題がない場合は、割り当て量の配分を確認します。割り当て量の配分に問題がある場合は、所定の手順で割り当てを増やしてから、問題を解決します。
割り当ての配分に問題がない場合は、監査ログでエラーの重大度のエントリを確認します。
1. エラーの重大度のエントリがある場合は、必要な権限を確認します。
  1. アクセスの問題解決に必要な権限を付与できる場合は、問題を解決します。
  2. アクセスの問題を解決できない場合は、カスタマーケアにお問い合わせください。
2. エラーの重大度のエントリがない場合は、カスタマーケアにお問い合わせください。

以降のセクションでは、各トラブルシューティングの手順を完了する方法について説明します。

ユーザーのアクセス権を確認する

Google Cloud コンソールと Google Cloud CLI の両方でユーザーアクセスが拒否されたかどうかを確認します。

影響を受けるユーザーとして Google Cloud コンソールにログインします。
リソースにアクセスしてみます。たとえば、VM を起動できないという報告があった場合は、VM を起動してみます。
Google Cloud コンソールで Cloud Shell を開き、ユーザーがログインしているセッションから次の gcloud CLI コマンドを実行します。このコマンドで、ユーザーが正しい ID にログインしているかどうか、ユーザーが gcloud CLI を使用してリソースにアクセスできるかどうかを確認できます。
```
gcloud auth list
```
出力はユーザーがログインしているアカウントを返します。
上述のコマンドが正しい ID を返すかどうかを確認します。
- 上述のコマンドで誤った ID が返された場合は、正しい ID にログインするようユーザーに求めます。次に、正しい ID を使用している場合でもアクセスに問題があるかどうかを確認します。
- 上述のコマンドで正しい ID が返され、permission denied メッセージが表示された場合は、ユーザーが実行する必要のあるアクションに対して gcloud CLI コマンドを実行します。拒否の詳細を確認するには、--log-http フラグと --verbosity=debug フラグを追加します。
権限に関する問題を特定した場合は、必要な権限を確認するに進みます。

ネットワークの問題を確認する

VPC Service Controls のトラブルシューティングのガイダンスに従って、ネットワークの問題を確認します。VPC Service Controls の拒否エラーメッセージが表示された場合は、問題を解決します。
接続テストを使用して、送信元から宛先までのネットワークパスを確認します。同じネットワークまたはピアリングされるネットワークの 2 つの VM インスタンス間の接続をテストする方法については、VPC ネットワーク内のテストをご覧ください。
ファイアウォールインサイトを使用して、ファイアウォールの構成を確認し、シャドウファイアウォールルールと、アクセスパスに影響する可能性のある拒否ルールを表示します。

割り当て量の配分を確認する

ネットワーク関連の問題が見つからない場合は、割り当て量の配分を確認します。割り当て量に関する問題が発生していると思われる場合は、必要に応じて、定義されたプロセスに従って割り当て量を増やします。

監査ログを確認する

ログエクスプローラを使用して監査ログファイルを確認します。ログエクスプローラでは、ログエントリの重大度の要約を確認できます。エラーログの重大度は、API 呼び出しが失敗すると記録されます。たとえば、ユーザーが Cloud Storage バケットを作成しようとしたものの、storage.buckets.create を呼び出す権限がない場合はエラーが記録されます。

ログエントリの概要には次の情報が含まれます。
- ターゲットリソース名
- プリンシパル（リソースにアクセスしようとしているユーザー）
- プリンシパルが実行しようとした API 呼び出し

必要な権限を確認する

プリンシパルに必要な権限が付与されていない理由を確認するには、Policy Troubleshooter を使用します。

チェックでアクセス権が認められていない場合は、Policy Troubleshooter が提示しているロールを確認します。
Policy Analyzer を使用して、プリンシパルが拒否したリソースに対する他のプリンシパルのアクセス権を確認します。
適切なロールへのバインディングがある Google グループにプリンシパルの ID を追加します。

カスタマーケアに問い合わせる

上述のトラブルシューティングの手順をすべて試しても問題を解決できない場合は、カスタマーケアにお問い合わせください。トラブルシューティングガイドのカスタマーケアへのエスカレーションの説明に従って、可能な限り多くの情報を提供してください。

トラブルシューティングのユースケースの例

このセクションでは、上述のトラブルシューティングの手順で特定のユースケースをトラブルシューティングする方法について詳しく説明します。すべてのユースケースで、Google Cloud のポリシーとアクセスに関する問題のトラブルシューティングで説明されているトラブルシューティングツールを使用する適切な権限が必要です。

以下の使用例は、Google グループを使用してユーザーアクセスを管理することを前提としています。Google グループを使用して権限を付与すると、アクセスを大規模に管理できます。Google グループの各メンバーは、そのグループに付与された Identity and Access Management（IAM）ロールを継承します。この継承により、個々のユーザーに IAM のロールを付与する代わりに、グループのメンバーシップを使用してユーザーのロールを管理できます。

デベロッパーにコンピューティング管理者ロールを付与できない場合にロール委任者が行うトラブルシューティング

ロールの委任者として、特定のロールをデベロッパーに付与できない理由を確認する必要があります。自分のチームに加わったデベロッパーには Compute Admin のロールを付与しています。Compute インスタンス管理者ロールを付与しようとしましたが、拒否されました。

フローチャートに沿ってユーザーアクセスを確認し、監査ログをチェックすることで、これが権限の問題であることがわかります。

ロールを付与するには、resourcemanager.projects.setIamPolicy 権限が必要です。この権限は、次のロールの一部として付与できます。

組織管理者ロール（roles/resourcemanager.organizationAdmin）
フォルダ IAM 管理者ロール（roles/resourcemanager.folderIamAdmin）
プロジェクト IAM 管理者のロール（roles/resourcemanager.projectIamAdmin）

ロール委任者に resourcemanager.projects.setIamPolicy 権限が割り当てられているかどうかを確認するには、Policy Troubleshooter を使用します。権限の割り当てが解除された場合は、次の点を確認してください。

取り消しを行った可能性がある IAM 提案が適用されているかどうかを確認します。
前回にロールを付与できたことがわかっている場合は、現在からその日時までのログを確認し、適用されたポリシーを変更した setIam 呼び出しがあったかどうかチェックします。
Policy Analyzer を使用して、どのプリンシパルに resourcemanager.projects.setIamPolicy が設定されているかを確認します。Policy Analyzer は、ロール委任者がグループから削除されたかどうかの確認に役立ちます。

デベロッパーが BigQuery にアクセスできない場合に Cloud 管理者が行うトラブルシューティング

クラウド管理者が、デベロッパーの 1 人が BigQuery データセットに対してクエリを実行できなくなった理由を確認する必要があります。

このユースケースをトラブルシューティングするには、まずユーザーアクセスを確認して関連する問題を解決します。それから、ネットワークに問題がないか確認します。この例では、ID またはネットワークの問題はなく、権限の問題があることを前提としています。

権限の問題をトラブルシューティングするには、まずチームメンバーの権限を確認します。不一致が見つからない場合は、ログを確認して潜在的な問題を特定します。ログで問題が見つからない場合は、カスタマーケアにお問い合わせください。

チームメンバーの権限を確認する

チームメンバーの権限を確認するには、デベロッパーに最後にクエリを正常に実行できた日時を確認します。次に、デベロッパーチームのメンバーが以前にクエリを実行できたかどうか、また、ユーザーがクエリを実行できたかどうかを確認します。チームメンバーがクエリを実行できない場合は、ログを確認するに進みます。

チームメンバーがクエリを実行できる場合は、次の操作を行います。

両方のデベロッパーに付与された IAM 権限をチェックし、権限の違いを確認します。権限を確認するときは、以下の点をチェックしてください。
権限に違いがない場合は、次のセクションのログを確認するに進みます。権限が異なる場合は、次の操作を行います。
1. 両方のチームメンバーが同じ Google グループに属しているかどうかを確認します。
  - 同じ Google グループにない場合は、そのグループに属している必要があるかどうかを確認します。
  - 以前に同じ Google グループに属していた場合は、グループ管理者に連絡して、変更された理由を確認します。
権限の問題に対処したら、デベロッパーがクエリを実行できるかどうかを確認します。
- デベロッパーがクエリを実行できる場合は、問題を解決します。
- デベロッパーがクエリを実行できない場合は、次のセクションのログを確認するに進みます。

ログを確認する

チームメンバーがクエリを完了できない場合や、権限の問題に対処しても問題が解決しなかった場合は、ログをチェックして、デベロッパーが最後にクエリを完了した後に変更された内容を特定します。

最後に正常に完了したタスクのログの表示場所を決めます。この例では、ログは BigQuery にエクスポートされます。
エクスポートされたログに対して、BigQuery でクエリを実行します。
1. デベロッパーが最後にアクセスした日付を含む 1 つのクエリを実行して、状況を確認します。
2. リクエストが失敗した時間、同じクエリを実行します。
ログで問題が確認された場合は、必要な権限を確認するで説明したように、Policy Troubleshooter と Policy Analyzer を使用して問題を解決します。
それでも問題が解決しない場合は、カスタマーケアにお問い合わせください。

デベロッパーに必要な GKE に対する権限

デベロッパーが、Pod の開始、削除、更新ができない理由、またアクセス権のある Google Kubernetes Engine（GKE）クラスタで Deployment を作成できない理由を確認する必要があります。kubectl コマンドラインツールで呼び出しを実行するときに、どのプリンシパルが使用されているのか、現在どの権限が付与されているのかわかりません。

デベロッパーが Pod を開始、削除、更新したり、GKE クラスタに Deployment を作成するために必要な IAM ロールは、Google Kubernetes Engine デベロッパーロール（roles/container.developer）です。このロールは、GKE クラスタが存在するプロジェクトで付与する必要があります。

このユースケースをトラブルシューティングするには、まずユーザーアクセスを確認して関連する問題を解決します。ID を検証したら、kubectl ツールが適切なクラスタを指すように構成されていることを確認します。kubectl ツールで使用される ID が正しいことや、kubectl ツールが正しいクラスタを指していることを確認する方法については、kubectl のクラスタアクセスの構成をご覧ください。この例では、ネットワークや割り当て関連の問題はなく、権限の問題があることを想定しています。

権限の問題のトラブルシューティングを開始するには、監査ログをチェックして、デベロッパーから最後に行われた正常な操作と、問題が最初に報告された時刻との間に行われた変更内容を確認します。

デベロッパーが以前にアクセス権を持っていた場合、同じ操作を行える権限を持つチームメンバーが操作を完了できるかどうかを確認します。チームメンバーにアクセス権がある場合は、Policy Analyzer を使用して、チームメンバーに設定するアクセス権を判断します。ベストプラクティスに従うには、両方のデベロッパーに同じグループメンバーシップと権限を設定する必要があります。
1. 権限が同じで、どのデベロッパーもリソースにアクションを実行できない場合は、アクセスに影響を及ぼす可能性のある IAM の推奨事項が適用されているかどうかを確認します。
2. 権限が異なる場合は、違いが発生した原因を調べます。
  1. 監査ログで、デベロッパーが最後にタスクを正常に実行できた日時を確認します。ログを、最後に試行した後で処理できなかった時間と比較します。
  2. IAM 推奨事項を確認して、推奨事項を適用します。
検証できる別のチームメンバーがいない場合は、必要な権限を確認するの説明のように、Policy Troubleshooter と Policy Analyzer を使用します。詳しくは、次のリソースをご覧ください。
それでも問題が解決しない場合は、カスタマーケアにお問い合わせください。

セキュリティ管理者がデベロッパーにアクセス権を付与できない場合のトラブルシューティング

セキュリティ管理者が、デベロッパーが特定のアクションを実行できなかった理由を確認する必要があります。ユーザーに必要以上のアクセス権が付与されないようにするには、どのようなロールをどこに割り当てたらよいでしょうか。

このシナリオでは、デベロッパーに以下の操作を行う権限が必要です。

Cloud Storage バケットにオブジェクトをアップロードする。デベロッパーがバケット内の既存のオブジェクトを表示、削除、上書きすることはできません。
開発プロジェクトでインスタンスを開始する。

デベロッパーが行う必要があるタスクを実行するために必要な権限を確認するには、Policy Troubleshooter と IAM ロールのリファレンスページを使用します。この例では、デベロッパーに以下の権限を含むロールを付与する必要があります。

デベロッパーがインスタンスを停止および起動できるようにするには: compute.instances.start と compute.instances.stop
デベロッパーが Cloud Storage バケットにオブジェクトをアップロードできるようにするには: storage.objects.create

以下のロールは、上述の権限を含み、最小権限の原則を遵守しています。

デベロッパーがオブジェクトをアップロードできるバケットのバケットレベルで、ストレージオブジェクト作成者のロール（roles/storage.objectCreator）を付与します。
デベロッパーが割り当てたプロジェクトのプロジェクトレベルまたはデベロッパーによる再起動に必要なインスタンスで、Compute インスタンス管理者のロール（roles/compute.instanceAdmin）を付与します。

一般的に、インスタンスの管理にはディスクの追加などの操作が必要になる場合があります。その場合、最小権限の原則を遵守しながら、roles/compute.instanceAdmin ロールを使用して必要な権限を与えることができます。

アプリケーションが Cloud Storage に書き込むことができない場合に Cloud 管理者が行うトラブルシューティング

クラウド管理者が、GKE で実行されるアプリケーションで Cloud Storage に書き込めなくなった理由を確認する必要があります。

このシナリオでは、GKE で実行されるアプリケーションを以下のように構成する必要があります。

指定したバケットにおいて、アプリケーションはオブジェクトの追加、更新、削除を行うことができます。
このアプリケーションは、組織内の他のバケットにアクセスできません。

次のトラブルシューティングのアプローチでは、推奨されている Workload Identity を使用していることを前提としています。Workload Identity では、Google サービスアカウントとして機能するように Kubernetes サービスアカウントを構成することができます。Kubernetes サービスアカウントとして実行中の Pod は、Google Cloud APIs にアクセスするときに自動的に Google サービスアカウントとして認証されます。

この例では、クラスタの Workload Identity に使用している Google サービスアカウントに適切な権限が付与されていることを確認します。アプリケーションのタスクの実行に必要な権限を確認するには、Policy Troubleshooter と IAM ロールのリファレンスページを使用します。権限を構成して検証する手順は次のとおりです。

Workload Identity で使用している Google サービスアカウントに、次の権限を割り当てます。
1. オブジェクトの一覧表示、作成、表示、削除など、アプリケーションがオブジェクトを完全に制御できるバケットに、Storage オブジェクト管理者のロール（roles/storage.objectAdmin）を付与します。
2. Google サービスアカウントの権限を借用するように Kubernetes サービスアカウントを構成するには、IAM ポリシーバインディングを設定します。
```
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
  次の値を置き換えます。
  - PROJECT_ID: プロジェクト ID
  - KSA_NAME: リクエストを行っている Kubernetes サービスアカウント
  - KUBERNETES_NAMESPACE: Kubernetes サービスアカウントが定義されている Kubernetes Namespace
  - GSA_NAME: Google サービスアカウント
プロジェクトに対する iam.serviceAccounts.setIamPolicy 権限を設定します。
- Kubernetes サービスアカウントに次のアノテーションを追加します。
```
iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID
```
Google サービスアカウントに適切な権限があり、Workload Identity が正しく構成されていることを確認します。
1. アプリケーションでオブジェクトのフルコントロールが許可されているバケットで、バケットの IAM ポリシーを表示し、Google サービスアカウントに roles/storage.objectAdmin ロールが付与されていることを確認します。
2. 権限が正しくない場合は、Google サービスアカウントに必要な権限を付与するようにポリシーを修正します。
Workload Identity が正しく構成されていることを確認するには、Kubernetes サービスアカウントにバインディングがあることを確認します。
```
gcloud iam service-accounts get-iam-policy \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
出力は次のようになります。
```
- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser
```
バインディングが正しくない場合は、上述の手順を繰り返して、サービスアカウントに権限を割り当ててください。

次のステップ

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。