GCP Project Migration - with Google Auth

[neildesai007]

Hi All,

I am using Google auth in one of my GCP projects. This Auth is registered with an email "firstuser@gmail.com". I have 30k+ users who have used this Auth app and generated access and refresh tokens using my products. So, every time they use any google services, as per their consent given in auth scope, my APIs provide services using their refresh token and generate runtime access tokens to access their google ecosystem accounts. (google ads, google analytics, maps etc).

Now, I want to migrate this GCP project containing Auth app to another GCP organization (folder) without affecting my existing users. I want this Auth app to function as normal when the migration is complete, and all these 30k+ users should be able to use this same auth to generate access tokens from their old refresh tokens. I dont want users to again go for re-auth. 

I want confirmation from tech / domain experts on below pointers:
1. If I migrate the project, my current services will not be affected. And users will be able to use this auth even with old refresh tokens as they are currently able to do so in my current project.
2. If I need to add this user email "firstuser@gmail.com" to another project's IAM. Since, this email is the email on which the Auth App is registered in the original project.

Please guide / advice me here.

Thanks.

[Manish_B]

Hello @neildesai007,

Thank you for contacting Google Cloud Community. 

To specifically answer your queries,

1. If I migrate the project, my current services will not be affected. And users will be able to use this auth even with old refresh tokens as they are currently able to do so in my current project.

Ans: The project may misbehave if Shared VPC, IAM Custom Roles, Organization Policy or project folders are in use. Therefore, if you are not using any of them, the project detachment shouldn’t have any downtime. 

2. If I need to add this user email "firstuser@gmail.com" to another project's IAM. Since, this email is the email on which the Auth App is registered in the original project.

Ans: Roles and permissions that are directly assigned at the project level are preserved during the migration. This means that any user, group, or service account with roles specifically assigned to the project will retain their permissions after the migration.

• Any roles and permissions that are inherited from the source organization or its parent folders will not be transferred. The project will inherit new roles and permissions based on the policies of the target organization and its parent folders.

• After migration, the project will start inheriting IAM roles and policies from the target organization’s hierarchy. This can lead to a different set of inherited permissions if the target organization has different policies and roles configured.

Some considerations for smooth migration involves : 

1. Ensuring that service accounts used by applications within the project have the necessary permissions in the new organization.

2. Verifying that billing permissions and roles are correctly configured to avoid any disruptions.

3. Testing access to critical resources and services post-migration to ensure that there are no unexpected permission issues.

Additionally, in regards to move the projects between organizations, here is a summary of permissions and policies that are needed:

1. Permissions on the Source organization :

The person moving the project needs to have roles/resourcemanager.projectMover on the organization. Alternatively, the person can have resourcemanager.projects.update permission on the project and have resourcemanager.projects.move permission on the parent (organization).

2. Permissions on the destination organization :

The same person moving the project needs to have roles/resourcemanager.projectCreator on the organization.

3. Organization policy permissions:

On the parent resource to the project you want to move, set an organization policy that includes the constraints/resourcemanager.allowedExportDestinations constraint. On the destination resource, set an organization policy that includes the constraints/resourcemanager.allowedImportSources constraint.

On the source and destination organization resources, you must have the roles/orgpolicy.policyAdmin role, which grants permission to create and manage organization policies.

I hope the above information is helpful 🙂

Thanks & Regards,
Manish Bavireddy.