我正在尝试将项目创建者角色授予IAM的服务帐户,但没有看到名为“项目创建者”的角色,如此处https://cloud.google.com/iam/docs/understanding-roles#resource-manager-roles
所述I am not getting Project creator as a role in Service Account Role
答案 0 :(得分:1)
它的roles/resourcemanager.projectCreator
和最低的资源层次结构是Folder
。因此,如果您有一个文件夹,则在文件夹级别创建一个IAM角色(您需要在文件夹级别具有权限),或者在组织级别创建一个IAM角色(同样,您需要具有组织级别的权限)。
参考:https://cloud.google.com/iam/docs/understanding-roles#resource-manager-roles
roles/
resourcemanager.projectCreator Project Creator Provides access to create new projects. Once a user creates a project, they're automatically granted the owner role for that project. resourcemanager.organizations.get
resourcemanager.projects.create
Folder ```
Hope this helps
答案 1 :(得分:1)
正如约翰·汉利(John Hanley)之前提到的那样,应该在组织级别进行。我附了一张照片。
答案 2 :(得分:0)
如果您在IAM中看不到项目创建者角色,则必须联系组织管理员,该管理员应具有添加该特定角色的能力。
答案 3 :(得分:0)
与其考虑“全局”授予用户/服务帐户权限,不考虑根据上下文授予这些权限。假设一个用户的身份为user@gmail.com
。您希望该用户能够创建项目...但是它并不那么简单。在GCP中,您具有可以包含项目的文件夹的概念。如果我有两个文件夹folder1
和folder2
,并且希望用户能够在folder1
中创建项目,但不能在folder2
中创建项目,则我们似乎有问题。如果我说用户可以公正创建项目,那将太广泛了。
一种更好的思考方式是,有一个资源层次结构……这些资源始于根(组织),然后在其下方有文件夹(可选),最后是项目。现在我们已经足够完成故事。
GCP允许我们做的是状态:
在此级别(组织或文件夹),我希望授予该用户此权限。然后,它从该树级别向下传播,但不水平传播。
因此,我们找到了您问题的根源。当您进入IAM时,您尝试将角色与用户“全局”关联,而不是“上下文”。没有概念让用户项目在全球范围内创建...而是在组织或文件夹级别上根据上下文进行创建。请注意,如果您在组织级别分配权限,则该权限实际上是全局的,因为所有内容都嵌套在组织中。