GCP无组织项目迁移至新组织的Cloud Identity相关问题咨询

1. 项目内与组织同域名的存量用户是否会自动纳入Cloud Identity的可管理范围？ #

不会自动纳入。
这些和组织域名重名的存量用户，本质都是此前个人注册的谷歌消费者账号，和你刚配置的Cloud Identity租户没有默认关联。完成Cloud Identity初始化后，你必须主动执行用户转移流程：要么用官方批量置备工具迁移，要么单个发起账号所有权转移，把这些个人账号的管辖权限划到Cloud Identity租户下，才能获得账号的完整管理能力，包括配置密码策略、登录会话管控、账号生命周期管理等。
如果跳过转移步骤，哪怕用户账号后缀和组织域名完全一致，账号所有权依然属于用户个人，你没有任何管理权限，后续开启域名强校验时还会触发账号冲突，导致原项目绑定的IAM权限失效。

2. Cloud Identity的用户组功能与Cloud控制台IAM板块的用户组功能存在哪些差异？ #

两者属于不同层级的资源，核心差异如下：

• 作用范围不同：Cloud Identity的用户组是身份层全局资源，在整个谷歌服务生态（GCP、Google Workspace、接入Cloud Identity的第三方SaaS应用）内通用；IAM板块的用户组是GCP资源层专属对象，设计目的仅为服务GCP内部的资源权限分配，无法跨服务使用。
• 功能能力不同：Cloud Identity用户组支持动态成员规则（根据用户部门、岗位标签等属性自动纳管符合条件的成员）、自带邮件组通讯能力、可配置成员审核、外部访问限制等细粒度规则，能同时满足文档授权、应用访问控制、GCP权限绑定等多类场景需求；IAM板块原生用户组仅支持静态成员配置，默认无附加通讯、动态纳管能力，仅能用于GCP资源的IAM角色绑定。
• 管理权限要求不同：操作Cloud Identity用户组需要被授予身份域层面的对应管理员角色（如组管理员、身份超级管理员），权限覆盖整个组织的身份体系；操作IAM板块的用户组仅需要被授予对应GCP资源层级（项目/文件夹/组织）的IAM组管理员权限，无法触碰身份域的全局配置。
• 成员规则不同：Cloud Identity用户组可灵活配置外部成员访问策略，支持添加个人谷歌账号、其他组织用户、服务账号、外部身份提供商用户等各类主体；IAM原生用户组默认仅支持添加本组织范围内的GCP主体（用户、服务账号、其他组），外部成员添加限制非常严格。

3. 迁移前后在IAM中创建的所有用户组，是否可在Cloud Identity中正常查看？ #

无法保证全部可见，需要按组的创建阶段和类型区分：

• 迁移前，在未关联组织的独立项目中创建的IAM原生组，在项目迁移到新组织节点后不会自动同步到Cloud Identity租户，你需要手动执行组所有权转移、身份映射配置，完成流程后才能在Cloud Identity控制台查看和管理这类组。
• 迁移完成、项目正式归属组织节点后，如果你在IAM中创建组时选择了默认的「Cloud Identity托管组」选项，组创建完成后会自动双向同步，可以直接在Cloud Identity控制台查看；如果你选择创建「IAM作用域专属组」（当前仅少部分特殊场景保留该创建选项），这类组不会同步到Cloud Identity，仅能在GCP IAM控制台查看和管理。

内容的提问来源于stack exchange，提问作者user994165