排查 Google Cloud 访问权限问题的用例

Last reviewed 2022-09-29 UTC

本文档介绍如何使用 Google Cloud 工具排查 Google Cloud 资源访问相关问题的用例。本文档未介绍如何排查最终用户对您的应用的访问权限问题。本文档假定您熟悉 Google Cloud 上的问题排查政策和访问权限问题。问题排查政策和访问权限问题文档介绍可强制执行访问权限政策的 Google Cloud 服务和 Google Cloud 提供的问题排查工具。

问题排查方法

在排查访问权限相关问题时，第一步是确定如何排查问题。下图提供一种排查访问权限问题的方法的流程图。该流程图假设您拥有完成问题排查步骤的适当权限，或者您可以与具备所需权限的用户合作。

一种排查访问权限问题的方法的流程图。

上图概述了以下步骤：

  1. 在 Google Cloud Console 和 Cloud Shell 中验证用户访问权限。如果访问全部被拒绝，请检查审核日志中是否存在错误严重性条目。
    1. 如果有错误严重性条目，请检查所需权限。
      1. 如果您可以授予解决访问权限问题的权限，请解决问题。
      2. 如果您无法解决访问权限问题，请与 Cloud Customer Care 联系。
    2. 如果没有错误严重性条目，则请与客服团队联系。
  2. 如果没有访问权限问题，请检查是否有网络问题。如果您发现了网络问题，请解决问题。
  3. 如果没有网络问题，则检查配额分配。如果发现配额分配问题，请按照相应流程增加配额，然后解决问题。
  4. 如果没有配额分配问题，请检查审核日志中是否有错误严重性条目。
    1. 如果有错误严重性条目，请检查所需权限。
      1. 如果您可以授予解决访问权限问题的权限，请解决问题。
      2. 如果您无法解决访问权限问题，请与客服团队联系。
    2. 如果没有错误严重性条目，则请与客服团队联系。

以下几个部分详细介绍如何完成每个问题排查步骤。

验证用户访问权限

使用 Google Cloud 控制台和 Google Cloud CLI 检查用户访问权限是否被拒绝：

  1. 以受影响的用户身份登录 Google Cloud 控制台。
  2. 尝试访问资源；例如，如果用户报告他们无法启动虚拟机，请尝试启动虚拟机。

  3. 在 Google Cloud 控制台中，打开 Cloud Shell，然后从用户登录的会话运行以下 gcloud CLI 命令。此命令可帮助验证用户是否登录了正确的身份，以及是否可以使用 gcloud CLI 访问资源。

    gcloud auth list

    输出会返回用户登录的账号。

  4. 检查上述命令是否返回正确的身份。

    • 如果上述命令返回错误的身份，请让用户登录正确的身份。然后，确定在使用正确的身份时访问权限是否仍是问题。
    • 如果上述命令返回正确的身份，并且您收到 permission denied 消息，请针对用户希望完成的操作运行 gcloud CLI 命令。如需详细了解拒绝，请添加 --log-http 和 --verbosity=debug 标志。

  5. 如果您确定权限相关问题，请跳至检查所需权限。

检查网络问题

  1. 根据 VPC Service Controls 问题排查指南检查是否有网络问题。如果您看到 VPC Service Controls 拒绝错误消息，请解决问题。
  2. 使用 Connectivity Tests 检查从来源到目标的网络路径。如需了解如何测试相同或对等互连网络中的两个虚拟机实例之间的连接，请参阅在 VPC 网络中进行测试。
  3. 使用防火墙数据分析检查防火墙配置，以显示所有设为阴影的防火墙规则以及可能影响访问路径的任何拒绝规则。

检查配额分配

  • 如果找不到任何网络相关问题，则检查您的配额分配。如果似乎是配额相关问题，请按照定义的流程增加配额（如果适用）。

查看审核日志

  • 使用日志浏览器检查审核日志文件。日志浏览器提供日志条目严重性摘要。当 API 调用失败时，系统会记录错误日志严重性；例如，如果用户尝试创建 Cloud Storage 存储分区，但无权调用 storage.buckets.create，则系统会记录错误。

    日志条目摘要提供以下详细信息：

    • 目标资源名称
    • 主账号（正尝试访问资源）
    • 主账号尝试执行的 API 调用

检查所需权限

如需调试主账号没有所需权限的原因，请使用政策问题排查工具：

  1. 如果检查表明未授予访问权限，请查看政策问题排查工具指明包含该权限的角色。
  2. 使用政策分析器查看可以访问主账号被拒绝访问的资源的其他主账号。
  3. 将主账号的身份添加到与相应角色绑定的适当 Google 群组。

与客服团队联系

如果您已完成上述问题排查部分，但无法解决问题，请与客服团队联系以获取帮助。在问题排查指南部分上报给客服团队中所述，提供尽可能多的信息。

问题排查用例示例

本节深入说明如何使用前面的问题排查步骤对特定用例进行问题排查。对于所有用例，您必须拥有适当的权限才能使用 Google Cloud 上的问题排查政策和访问权限问题中所述的问题排查工具。

以下用例假定您使用 Google 网上论坛管理用户访问权限。使用 Google 网上论坛授予权限，可以大规模管理访问权限。Google 群组的每个成员都会继承已授予该群组的 Identity and Access Management (IAM) 角色。这种继承方式意味着您可以使用群组的成员资格来管理用户角色，而无需向各个用户授予 IAM 角色。

角色委托人排查开发者对 Compute Admin 角色的访问权限问题

作为角色委托人，我需要了解为什么不能向开发者授予特定角色。我会在新开发者加入我的团队时定期授予 Compute Admin 角色。今天，我尝试了授予 Compute Instance Admin 角色，但遭到拒绝。

遵循流程图验证用户访问权限并检查审核日志，您可以确认这是权限问题。

如需授予角色，您需要 resourcemanager.projects.setIamPolicy 权限。您可以在以下角色中授予此权限：

  • Organization Administrator 角色 (roles/resourcemanager.organizationAdmin)
  • Folder IAM Admin 角色 (roles/resourcemanager.folderIamAdmin)
  • Project IAM Admin 角色 (roles/resourcemanager.projectIamAdmin)

如需确定角色委托人是否已分配 resourcemanager.projects.setIamPolicy 权限，请使用政策问题排查工具。如果不再分配权限，请检查以下内容：

  1. 检查是否应用了可能已取消政策的 IAM 建议。
  2. 如果您了解上次可以授予角色的时间，请查看从当时到现在这段时间的日志，查看是否发生了任何可能已更改所应用政策的 setIam 调用。
  3. 使用政策分析器检查哪些主账号具有 resourcemanager.projects.setIamPolicy。政策分析器可帮助验证是否已从群组中移除角色受托人。

Cloud 管理员排查开发者对 BigQuery 的访问权限问题

作为云管理员，我需要了解为什么其中一位开发者无法再针对 BigQuery 数据集运行查询。

如需排查此用例的问题，请先验证用户访问权限并解决任何相关问题。然后检查是否有网络问题。此示例假定您已确定没有身份或网络问题，但存在权限问题。

如需排查权限问题，请先检查团队成员权限。如果找不到任何差异，请检查日志以确定潜在问题。如果您在日志中未找到任何问题，可以联系客服团队寻求帮助。

检查团队成员权限

如需检查团队成员权限，请询问开发者上次能够成功运行查询的时间。然后确定该开发者团队中以前是否有人能够运行查询，以及该人员是否仍可成功运行查询。如果没有团队成员可以运行查询，请继续检查日志部分。

如果有团队成员仍可以运行查询，请完成以下步骤：

  1. 检查授予这两个开发者的 IAM 权限，并确定这些权限是否不同。查看权限时，查找是否有以下内容：
  2. 如果权限有所不同，请继续下一部分：检查日志。如果权限有所不同，请完成以下步骤：
    1. 检查两个团队成员是否在同一 Google 群组中。
      • 如果不属于同一个 Google 群组，请确定它们是否应该相同。
      • 如果他们此前在同一个 Google 群组中，请与群组管理员联系，以确定更改的原因。
  3. 解决权限问题后，检查开发者是否能够运行查询。
    • 如果开发者能够运行查询，请解决问题。
    • 如果开发者无法运行查询，请继续下一部分：检查日志。

检查日志

如果所有团队成员都无法完成查询，或者解决权限问题未能解决问题，您可检查日志以确定自开发者上次能够完成查询以来可能发生了哪些变化。

  1. 确定在何处查看上次成功完成的任务的日志。在此示例中，系统会将日志导出到 BigQuery。
  2. 针对 BigQuery 中导出的日志运行查询：
    1. 运行一个查询，其中包含开发者最近一次成功访问的日期，以便了解成功情况。
    2. 在请求失败时运行相同查询。
  3. 如果日志中存在可识别的情况，请使用政策问题排查工具和政策分析器解决问题，如检查所需权限部分中所述。
  4. 如果仍无法解决问题，请与客服团队联系。

开发者需要 GKE 的权限

作为开发者，我需要了解为什么我无法在我可访问的 Google Kubernetes Engine (GKE) 集群中启动、删除或更新 Pod 或者创建部署。我不确定使用 kubectl 命令行工具进行调用时使用的是哪个主账号，或我拥有哪些权限。

允许开发者在 GKE 集群中启动、删除或更新 Pod 或者创建部署的 IAM 角色是 Google Kubernetes Engine Developer 角色 (roles/container.developer)。应在 GKE 集群所在的项目中授予此角色。

如需排查此用例的问题，请先验证用户访问权限并解决任何相关问题。验证身份后，请确保将 kubectl 工具配置为指向正确的集群。如需了解如何确保 kubectl 工具使用的身份正确无误，且 kubectl 工具指向正确的集群，请参阅为 kubectl 配置集群访问权限。此示例假定您已确定没有网络问题或配额相关问题，但存在权限问题。

如需开始排查权限问题，请检查审核日志，了解开发者最近一次成功完成操作与首次报告问题之间所发生的变化。

  1. 如果开发者之前拥有访问权限，请检查是否还有权执行相同操作的团队成员是否仍可以完成这些操作。如果团队成员有访问权限，请使用政策分析器帮助确定团队成员具有哪些访问权限。如果您遵循最佳做法，则两个开发者应具有相同的群组成员资格和权限。

    1. 如果它们的权限相同，并且开发者都无法针对资源执行操作，请检查是否已应用可能会影响访问权限的 IAM 建议。
    2. 如果它们的权限不同，请调查差异的原因：
      1. 检查审核日志，了解开发者上次可以成功执行任务的时间。将日志与最近尝试执行但无法完成任务的时间进行比较。
      2. 检查 IAM 建议并应用任何建议。

  2. 如果没有其他团队成员可用于验证，请使用政策问题排查工具和政策分析器，如检查所需权限中所述。如需了解详情，请参阅以下资源：

  3. 如果仍无法解决问题，请与客服团队联系。

安全管理员排查开发者访问权限问题

作为安全管理员，我需要了解开发者为何无法执行操作。最佳角色以及分配给该角色的位置是什么，以便该角色提供的访问权限不超出用户需求？

在这种情况下，开发者需要能够执行以下操作：

  • 将对象上传到 Cloud Storage 存储分区。开发者不能查看、删除或覆盖存储分区中的现有对象。
  • 在其开发项目中启动实例。

如需了解执行开发者需要执行的任务所需的权限，请使用政策问题排除工具和 IAM 了解角色参考页面。在此示例中，您需要向开发者授予包含以下权限的角色：

  • 如需允许开发者停止和启动实例，请授予：compute.instances.start 和 compute.instances.stop
  • 如需允许开发者将对象上传到 Cloud Storage 存储分区，请授予：storage.objects.create

以下角色包括上述权限并遵循最小权限原则：

  • 在允许开发者将对象上传到的存储分区的存储分区级别，授予 Storage Object Creator 角色 (roles/storage.objectCreator)。
  • 在开发者分配的项目的项目级或开发者需要能够重启的实例中，授予 Compute Instance Admin 角色 (roles/compute.instanceAdmin)。

通常，管理实例可能还需要诸如添加磁盘等操作。在这种情况下，roles/compute.instanceAdmin 角色可能是一种授予所需权限同时仍遵循最小权限原则的适当方法。

Cloud 管理员排查应用无法写入 Cloud Storage 的原因问题

作为云管理员，我需要了解在 GKE 上运行的应用无法再向 Cloud Storage 写入的原因。

在此场景中，在 GKE 上运行的应用需要配置如下：

  • 在指定存储分区上，应用可以添加、更新和删除对象。
  • 应用无法访问组织中的任何其他存储分区。

以下问题排查方法假定您使用的是 Workload Identity（我们建议）。使用 Workload Identity，您可以将 Kubernetes 服务账号配置为充当 Google 服务账号。作为 Kubernetes 服务账号运行的 Pod 访问 Google Cloud API 时，会自动以 Google 服务账号进行身份验证。

在此示例中，您要验证已向您用于集群 Workload Identity 的 Google 服务账号授予相应权限。如需了解完成应用任务所需的权限，请使用政策问题排查工具 和 IAM 了解角色参考页面。如需配置和验证权限，请执行以下操作：

  1. 将以下权限分配给用于 Workload Identity 的 Google 服务账号：

    1. 在允许应用完全控制对象的存储分区，包括列出、创建、查看和删除对象，授予 Storage Object Admin 角色 (roles/storage.objectAdmin)。

    2. 如需配置 Kubernetes 服务账号以模拟 Google 服务账号，请设置 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 命名空间
      • GSA_NAME：Google 服务账号

  2. 设置项目的 iam.serviceAccounts.setIamPolicy 权限：

    • 向 Kubernetes 服务账号添加以下注释：

      iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID

  3. 验证 Google 服务账号是否具备适当的权限，以及 Workload Identity 是否已正确配置：

    1. 在允许应用完全控制对象的存储分区，查看存储分区的 IAM 政策，并验证 Google 服务账号是否具有 roles/storage.objectAdmin 角色。
    2. 如果权限不正确，请修改政策以向 Google 服务账号授予所需权限。

  4. 通过检查 Kubernetes 服务账号是否绑定，验证 Workload Identity 是否已正确配置：

    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

    如果绑定不正确，请重复执行上述步骤，向服务账号分配权限。

后续步骤