Re: Billing and migrating projects

jc123 · 06-14-2022 07:24 AM

I'm migrating a project from no org to a new org. Is it possible to re-use the existing billing account?

The existing users have email addresses in the xyz.differentorg.com domain. Will these users be considered to be unmanaged accounts?

Can these users be turned into managed accounts in the new org (and if so, how?), or are managed accounts only possible if the email address domain matches the domain in Cloud Identity?

alexmoore

Hi,

Yes, you can use an existing billing account for this purpose. If the users managing that billing account are not associated with Cloud Identity or Workspace account then as you say they will be 'unmanaged' accounts.

It is however possible to have multiple domains on a single Cloud Identity instance, you can read more about that here: https://support.google.com/cloudidentity/answer/175747?hl=en#zippy=%2Cwhat-are-multiple-domains

And for more details on reconciling unmanaged users, please look at this link: https://support.google.com/cloudidentity/answer/6178640?hl=en

Hope that helps, any questions let me know.

All the best,

Alex

jc123

Alex,

If we re-use a Cloud Identity instance to set up another domain, we would get a second organization under that second domain? Is there a benefit to doing this versus creating a brand new Cloud Identity instance? The source project is no org but we also have an existing Cloud Identity/org and want to move the source project to a second org.

What benefits are there in keeping the old billing account vs. setting up a new one?

The users I mentioned aren't the ones managing the billing account, but all of the ones in IAM in the source project. What benefit is there to turning them into managed accounts? Does it matter if their email domains match the new domain in Cloud Identity when it comes to keeping them or converting them between unmanaged and managed accounts? Is it a problem to keep them as unmanaged accounts?

alexmoore

Hi,

In fact there is a 1:1 relationship between Cloud Identity and an Organization, more details here: https://cloud.google.com/resource-manager/docs/managing-multiple-orgs

So you can have multiple domains against a single Cloud Identity and a single org, or you can have multiple Cloud Identity instances - each instance would have its own org but note that (subject to org policy) you could still assign users from different cloud identity instances permissions to projects under different orgs. Hope I'm explaining that clearly 🙂 Some more reading:

https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
https://cloud.google.com/resource-manager/docs/creating-managing-organization

Pros and con's to each approach will depending largely on your situation and requirements, though generally I would guide to keep things simple initially.

In terms of keeping the existing billing account vs a new one - again this would be a decision for yourself - it might simply be easier to re-use an existing account compared to setting up a new one. Equally some organisations have multiple billing accounts in order to segment billing - to different business units for example.

If you configure the domain in use in Cloud Identity, you can only create users with their email address in the instance by the mechanism I shared previously. As the email address is a unique identifier, you can't have both an unmanaged and a managed account at the same time. Another article on this subject: https://support.google.com/cloudidentity/answer/11112794

The main benefit around Cloud Identity is governance and control. As personal accounts for your users as an organisation you have no control over them - even for basics, like resetting lost passwords, disabling accounts, etc, but there are a range of features, even in the free tier of Cloud Identity, you can read more here: https://cloud.google.com/identity/docs/editions

Hope that helps,

Alex

jc123

Alex,

"If you configure the domain in use in Cloud Identity, you can only creaate users with their email address in the instance by the mechanism I shared previously. "

Once the domain is configured in Cloud Identity, does that mean that consumer accounts can no longer be created? Only accounts with an email matching the domain can be created?

If consumer accounts can still be created, would that be done in IAM as opposed to in Cloud Identity?

The consumer accounts that were set up previously cannot be transferred/brought into Cloud Identity unless the domain matches?

Is it possible to use identity provider federation using a different domain than the one that is set up in Cloud Identity? If not, then you really need to set up a secondary domain to be able to do this? If the email addresses have a subdomain (xyw.domain.com), does the secondary domain in Cloud Identity have to have the subdomain as well?

Can a secondary domain be set up in a new Cloud Identity instance for a domain that already exists in a separate Cloud Identity/organization instance?

Thanks

alexmoore

Lots of questions there 🙂

So a Cloud Identity instance can have a primary and multiple secondary domains. Once a domain is associated with one Cloud Identity instance, it cannot be associated with another unless it is first removed from the existing instance.

Regarding consumer accounts, ultimately the email address is the identifier. So the key thing is you cannot create a consumer "Google account" if the account is already configured under Cloud Identity, equally you can't create an account under Cloud Identity if they already have a consumer Google account - hence the transfer tool to help you discover users that need to be brought in. To answer your question, you can still create Google accounts for a Cloud Identity domain if the account does not exist in Cloud Identity itself. However I would advise against it. Once you establish a Cloud Identity instance for a domain best practice would be to transfer in all existing accounts and manage everything centrally, otherwise you start to have quite a complex identity landscape that will be hard to manage.

For details regarding federating identities, take a look at this article: https://cloud.google.com/architecture/identity/best-practices-for-federating

IAM is just where you configure permissions against Google Cloud resources, it isn't related to account provisioning itself - the exception would be Service Accounts.

Hope that helps,

Alex

jc123

Alex,

" you can still create Google accounts for a Cloud Identity domain if the account does not exist in Cloud Identity itself."

How would this be done? That would also be done in Cloud Identity?

Can only accounts with the domain matching the Cloud Identity domain be transferred to Cloud Identity? So consumer accounts cannot be transferred to Cloud Identity? We have a bunch of existing accounts with a separate domain. What options do we have with these types of accounts?

alexmoore

What I meant was that it is possible to sign up a new 'unmanaged' account as long as the account itself doesn't exist in your Cloud Identity instance. Of course I wouldn't advise this, better to keep everyone in Cloud Identity.

Conversely if you create an account in Cloud Identity, it will be associated with Cloud Identity at that point and if the user tried to setup an 'unmanaged' Google Account it would stop them - saying that an account already exists.

And yes, only accounts matching domains attached to Cloud Identity can be transferred in. If a consumer account was configured with an email address that matches a domain associated with Cloud Identity, then it would be picked up by the transfer tool.

As per earlier in the thread, you can configure a secondary domain on the same Cloud Identity, or create a new Cloud Identity instance.

jc123

Got it. Lets say I have a consumer account and want to transfer that user to Cloud Identity. There's already a separate Cloud Identity instance set up with that email's domain, so I can't create a second domain. What's the best way to handle this?

alexmoore

Add the user to the existing Cloud Identity instance for that domain.