网络相关工作职责的 IAM 角色

本主题介绍如何为网络场景配置 Identity and Access Management (Cloud IAM) 权限。它提供了有关针对这些场景为贵公司中的网络相关职能角色授予哪些 IAM 角色的指导。这些内容主要针对为组织管理网络任务的网络管理员和员工。下文所述的场景都假设配置了一个 Google Cloud 组织。

本文档并未详细阐述网络角色和权限。如需查看与 Compute API 和 Networking API 关联的角色和权限的详细说明，请参阅预定义的 Compute Engine IAM 角色。

单个团队负责管理组织的安全性和网络

在此场景中，一家大型组织有一个负责管理整个组织的安全和网络控制的中心团队。开发者无权对由安全和网络团队定义的任何网络或安全设置做出更改，但他们有权创建资源（如共享子网中的虚拟机）。

为了帮助实现此目的，该组织使用共享 VPC（虚拟私有云）。共享 VPC 允许创建 RFC 1918 IP 空间的 VPC 网络，关联项目（服务项目）随后可以使用该网络。使用关联项目的开发者可以在共享 VPC 网络空间中创建虚拟机实例。组织的网络和安全管理员可以创建可供 VPC 网络中所有项目使用的子网、VPN 和防火墙规则。

下表说明了需要为安全和管理团队、开发团队授予的 IAM 角色以及授予这些角色所在的资源层级。

资源： 组织
角色： Shared VPC Admin
Network Admin
Security Admin
主账号： 安全和网络管理团队
资源： 宿主项目 此角色可授予使用共享 VPC 已共享的子网的权限。
角色： 网络用户
主账号： 开发者
资源： 服务项目 请注意，此角色允许使用外部 IP 地址。如需了解如何避免执行此操作的指导，请参阅下面的说明。
角色： compute.instanceAdmin
主账号： 开发者

在这种情况下，您需要三个独立的允许政策：一个针对组织、一个针对宿主项目、一个针对服务项目。

第一个允许政策需要在组织层级关联，向网络和安全团队授予管理共享 VPC 宿主项目所需的角色。这包括将服务项目与宿主项目相关联的权限。它还为网络和安全团队授予管理组织所有项目中的所有网络和安全资源的权限。

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    }
  ]
}

第二个允许政策需要与宿主项目相关联，并使组织中的开发者能够在共享 VPC 宿主项目中使用共享网络。

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

第三个允许政策需要与每个服务项目关联。这样，使用项目的开发者就可以管理服务项目中的实例，并且能够在宿主项目中使用共享子网。

您可以将所有服务项目放置在一个文件夹中，并在层次结构的该层级上设置此特定允许政策。这将允许在该文件夹中创建的所有项目沿用在文件夹（其中创建了服务项目）上设置的权限。

您还需要为开发者授予服务项目中的网络用户角色。

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

最佳做法是使用群组来管理主账号。在上面的示例中，您可以将负责管理安全和网络控制的用户的用户 ID 添加到 sec-net 群组中，并将开发者添加到 developers 群组中。当您需要修改能够执行此职能的人员时，您只需调整群组成员资格，而无需更新允许政策。

独立的网络和安全团队

在此场景中，一家大型组织有两个中心团队：一个负责管理安全控制，另一个负责管理整个组织的所有其他网络资源。开发者无权对由安全和网络团队定义的任何网络或安全设置做出更改，但他们有权创建资源（如共享子网中的虚拟机）。

与第一种场景一样，将使用共享 VPC，并为三个群组的网络、安全和开发者配置适当的权限。

下表说明了需要为安全和管理团队、开发团队授予的 IAM 角色以及授予这些角色所在的资源层级。

资源： 组织
角色： Shared VPC Admin
Network Admin
主账号： 网络管理团队
资源： 组织
角色： Security Admin
Organization Admin
主账号： 安全团队
资源： 宿主项目 此角色可授予使用共享 VPC 已共享的子网的权限。
角色： 网络用户
主账号： 开发者
资源： 服务项目 请注意，此角色允许使用外部 IP 地址。如需了解如何避免执行此操作的指导，请参阅下面的说明。
角色： compute.instanceAdmin
主账号： 开发者

在这种情况下，您需要三个独立的允许政策：一个针对组织、一个针对宿主项目、一个针对服务项目。

第一个允许政策需要在组织层级关联，向网络团队授予管理共享 VPC 宿主项目以及管理所有网络资源所需的角色。这包括将服务项目与宿主项目相关联的权限。网络管理员角色还会授予网络团队查看防火墙规则的权限，但不会授予他们修改防火墙规则的权限。它还授予安全团队在组织中的所有项目中设置允许政策以及管理防火墙规则和 SSL 证书的权限。

{
  "bindings": [
  {
    "role": "roles/compute.xpnAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.networkAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.securityAdmin",
    "members": [
      "group:security@example.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "group:security@example.com"
        ]
    }
  ]
}

第二个允许政策需要与宿主项目关联。此允许政策允许组织中的开发者使用共享 VPC 宿主项目中的共享网络。

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

第三个允许政策需要与每个服务项目关联。这样，使用项目的开发者就可以管理服务项目中的实例，并且能够在宿主项目中使用共享子网。

您可以将所有服务项目放置在一个文件夹中，并在层次结构的该层级上设置此特定允许政策。这将允许在该文件夹中创建的所有项目沿用在文件夹（其中创建了服务项目）上设置的权限。

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "group:developers@example.com"
          ]
      }
    ]
}

每个团队都可以管理自己的网络

数字土著公司希望为他们的开发团队提供以自主方式工作的能力。他们没有任何中心 IT 管理团队，并且信任他们的团队管理他们项目的所有方面。

尽管如此，他们也希望能够制定一些宽松的控制措施，以便随着他们的成长和产品的正式发布而采用更正式的设置。

为了实现此场景，每个开发者团队都分配有专属文件夹。此结构可确保在该文件夹下创建的各个项目沿用相应的权限，同时允许每个团队独立工作。每个团队在为其专属资源设置允许政策时，仍应遵循最低权限原则。

尽管最初将由相同的团队成员负责管理网络资源以及项目中的实际资源，为逻辑职责创建单独组的群组也是最佳做法。

这种方法有助于限制对临时工所需资源的访问权限，或者限制可能需要培训才能修改网络资源的新员工的访问权限。此外，此方法还允许更改谁可以访问哪些资源，而无需在每次发生人员变动时修改允许政策。

资源： 文件夹 服务账号可用于创建和拥有项目。
角色： Project creator
Folder Admin
主账号： 开发团队负责人
服务账号
资源： 文件夹
角色： Network Admin

Security Admin
主账号： 网络和安全团队
资源： 文件夹 这些角色可让开发者管理 BigQuery 和 Compute Engine 的所有方面。
角色： Instance Admin
BigQuery Admin
主账号： 开发者

这需要在每个团队分配的文件夹上绑定允许政策。

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
        ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:dev01@example.com"
        ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "group:dev01@example.com"
        ]
    }
  ]
}