Best practices for planning accounts and organizations

Last reviewed 2024-06-26 UTC

This document presents best practices for deciding how many Cloud Identity or Google Workspace accounts, Google Cloud organizations, and billing accounts you need to use. The document provides guidance on identifying a design that satisfies your security and organizational requirements.

In Google Cloud, identity and access management is based on two pillars:

  • Cloud Identity and Google Workspace accounts are containers for users and groups. These accounts are therefore key to authenticating your corporate users and managing access to your Google Cloud resources. A Cloud Identity or Google Workspace account denotes a directory of users, not an individual user account. Individual user accounts are referred to as users or user accounts.

  • Organizations are containers for projects and resources within Google Cloud. Organizations allow resources to be structured hierarchically and are key to centrally and efficiently managing resources.

This document is intended primarily for customers who are setting up enterprise environments.

Cloud Identity and Google Workspace accounts

Google Workspace is an integrated suite of cloud-native collaboration and productivity apps. It includes tools that let you manage users, groups, and authentication.

Cloud Identity provides a subset of the Google Workspace features. Like Google Workspace, Cloud Identity lets you manage users, groups, and authentication, but it doesn't include all of Google Workspace's collaboration and productivity features.

Cloud Identity and Google Workspace share a common technical platform and use the same set of APIs and administrative tools. The products share the concept of an account as a container for users and groups. This container is identified by a domain name such as example.com. For managing users, groups, and authentication, the two products can be considered equivalent.

Combine Cloud Identity and Google Workspace in a single account

Because Cloud Identity and Google Workspace share a common platform, you can combine access to the products in a single account.

If you already administer a Google Workspace account and want to enable more users to use Google Cloud, you might not want to assign all users a Google Workspace license. In this case, add Cloud Identity Free to your existing account. You can then onboard more users without additional charge and decide which users should have access to Google Workspace by assigning them a Google Workspace license.

Similarly, if you already administer a Cloud Identity Free or Premium account, you might want to grant certain users the right to use Google Workspace. Rather than creating separate Google Workspace accounts for those users, you can add Google Workspace to an existing Cloud Identity account. After you've assigned the Google Workspace license to those selected users, they can use the productivity and collaboration apps.

Use as few accounts as possible, but as many as necessary

To let your users collaborate by using Google Workspace, and to minimize administrative overhead, it's best to manage all users through a single Cloud Identity or Google Workspace account and provide a single user account to each individual. This approach helps ensure that settings such as password policies, single sign-on, and two-step verification are consistently applied to all users.

Despite these benefits of using a single Cloud Identity or Google Workspace account, you can gain flexibility and administrative autonomy by using multiple accounts. When you are deciding how many Cloud Identity or Google Workspace accounts to use, consider all requirements that suggest using multiple accounts. Then use the smallest number of Cloud Identity or Google Workspace accounts that satisfies your requirements.

Use separate accounts for staging and production

For most settings that you can configure in Cloud Identity and Google Workspace, you can choose the scope at which each setting should apply—for example, you can specify the geographic location for your data by user, by group, or by organizational unit. When you plan to apply a new configuration, you can initially choose a small scope (for example, by user) and verify whether the configuration meets your expectations. When you've verified the configuration, you can then apply the same setting to a larger set of groups or organizational units.

Unlike most settings, integrating a Cloud Identity or Google Workspace account with an external identity provider (IdP) has a global impact:

  • Enabling single sign-on is a global setting that applies to all users other than super admins.
  • Depending on your external IdP, setting up user provisioning can also have global impact. An accidental misconfiguration in the external IdP might lead to users inadvertently being modified, suspended, or even deleted.

To mitigate these risks, have separate staging and production Cloud Identity or Google Workspace accounts:

  • Use the staging account to verify any risky configuration changes before applying the same change to your production account.
  • Create a few test users in the staging accounts that you and other administrators can use to verify configuration changes. But don't grant your users access to the staging account.

If you have separate staging and production instances of your external IdP, take these steps:

  • Integrate your staging Cloud Identity or Google Workspace account with your staging IdP instance.
  • Integrate your production Cloud Identity or Google Workspace account with your production IdP instance.

For example, suppose you plan to set up federation with Active Directory and have a separate Active Directory forest for testing purposes. In this case, you integrate your staging Cloud Identity or Google Workspace account with the staging forest and the production Cloud Identity or Google Workspace account with your main forest. Apply the same mapping approach for DNS domains, users, and groups to both forest/account pairs, as shown in the following diagram:

Active Directory mapping approach for DNS domains, users, and groups.

Your production and staging Active Directory forests and domains might use DNS domains that don't let you apply the same domain mapping approach for staging and production. In this case, consider registering more User Principal Name (UPN) suffix domains in your staging forest.

Similarly, if you plan to set up federation with Azure Active Directory, it's best to take the following approach:

  • Integrate the staging Cloud Identity or Google Workspace account with a staging Azure Active Directory tenant.
  • Integrate the production Cloud Identity or Google Workspace account with your main Azure Active Directory tenant.

Apply the same mapping approach for DNS domains, users, and groups to both tenant/account pairs:

Azure Active Directory mapping approach for DNS domains, users, and groups.

Your production and staging Azure Active Directory tenants might use DNS domains that don't let you apply the same domain mapping approach for staging and production. In this case, consider adding an extra domain to your staging tenant.

Use disjoint DNS domains among Cloud Identity and Google Workspace accounts

When you first add a domain such as example.com to your Cloud Identity or Google Workspace account, you need to verify that you own the domain. After you have added and verified a domain, you can add subdomains such as marketing.example.com and finance.example.com without having to verify each subdomain individually.

However, if you add subdomains without verifying each one, conflicts can result if you have another Cloud Identity or Google Workspace account that already uses this subdomain. To avoid these conflicts, prefer using disjoint domains for each account. For example, if you need two Cloud Identity or Google Workspace accounts, try to avoid using two domains where one domain is a subdomain of the other. Instead, use two domains that are not subdomains of another. This practice applies to the primary domain and to secondary domains.

Don't separate Google Workspace and Google Cloud

If you already use Google Workspace, some users in your Google Workspace account might have been granted super admin privileges so that they can carry out administrative tasks.

Users with super admin privileges are implicitly granted permission to modify the Identity and Access Management (IAM) policy of the organization node. This permission enables super admins to assign themselves the organization administrators role or any other role in the Google Cloud organization. Having super admin access to a Cloud Identity or Google Workspace account also enables a user to delete the account, its associated Google Cloud organization, and all its resources. You therefore have to assume that super admins have full access to all resources within an organization.

The fact that super admins are also organization administrators might be a security concern if your existing Google Workspace administrators are a different set of users from the users who will be in charge of managing your Google Cloud organization. In this case, you might decide to create a separate Cloud Identity account that is dedicated to Google Cloud in order to limit the access of Google Workspace super admins to Google Cloud resources. Separating Google Workspace and Google Cloud can have several unintended consequences.

For example, you might try creating separate users in the Cloud Identity account and then restricting access to the Google Cloud organization users to the Cloud Identity account. This would ensure that your Google Cloud deployment and Google Workspace are fully isolated. However, duplicating users negatively affects both user experience and administrative overhead. Additionally, you wouldn't be able to receive any notification emails sent by Google Cloud because the domain used by Cloud Identity must be different from the domain used for Google Workspace and is therefore unsuitable for routing email.

If you instead reference users from the Google Workspace account in your Google Cloud organization, you undermine the isolation between Google Workspace and Google Cloud:

Referencing users from the Google Workspace account in your Google Cloud organization.

Google Workspace super admins have the ability to use domain-wide delegation to impersonate any user in the same Google Workspace account. A rogue super admin could use their elevated privileges to regain access to Google Cloud.

A more effective approach than using separate accounts is to segregate responsibilities between Google Workspace and Google Cloud administrators to reduce the number of super admins:

Secure your external IdP when using single sign-on

Cloud Identity and Google Workspace let you set up single sign-on with your external IdP such as Active Directory, Azure Active Directory, or Okta (to name a few). If single sign-on is enabled, Cloud Identity and Google Workspace trust the external IdP to authenticate users on Google's behalf.

Enabling single sign-on offers several advantages:

  • Users can use their existing credentials to sign on to Google services.
  • Users don't need to enter their passwords again if they already have an existing sign-on session.
  • You can apply consistent multi-factor authentication policies across your applications and all Google services.

But enabling single sign-on also exposes you to risks. When single sign-on is enabled and a user needs to be authenticated, Cloud Identity or Google Workspace redirects the user to your external IdP. After authenticating the user, the IdP returns to Google a SAML assertion that states the user's identity. The SAML assertion is signed. Therefore, Google can verify the authenticity of the SAML assertion and verify that the correct identity provider has been used. However, there is no way for Cloud Identity or Google Workspace to verify that the IdP made the right authentication decision and correctly stated the user's identity.

If single sign-on is enabled, the overall security and integrity of your Google deployment hinges on the security and integrity of your IdP. Your Cloud Identity or Google Workspace account and all resources that rely on the users managed by the account are at risk if any of the following are configured insecurely:

  • The IdP itself
  • The machines that the provider is running on
  • The user database that the provider is getting user information from
  • Any other system that the provider depends on

To prevent single sign-on from becoming a weak link in your security posture, ensure that your IdP and all systems it depends on are configured securely:

  • Limit the number of users with administrative access to your IdP or to any of the systems that the provider relies on.
  • Don't grant any user administrative access to these systems to whom you wouldn't also give super admin privileges in Cloud Identity or Google Workspace.
  • Don't use single sign-on if you are unsure about the security controls in place for your external IdP.

Secure access to your DNS zones

Cloud Identity and Google Workspace accounts are identified by a primary DNS domain name. When you create a new Cloud Identity or Google Workspace account, you must verify ownership of the DNS domain by creating a special DNS record in the corresponding DNS zone.

The importance of DNS and the impact on the overall security of your Google deployment extends beyond the sign-up process:

  • Google Workspace relies on DNS MX records for routing emails. By modifying these MX records, an attacker might be able to route emails to a different server and gain access to sensitive information.

  • If an attacker is able to add records to the DNS zone, they might then be able to reset the password of a super admin user and gain access to the account.

To prevent DNS from becoming a weak link in your security posture, ensure that your DNS server is configured securely:

  • Limit the number of users that have administrative access to the DNS server that manages the primary domain used for Cloud Identity or Google Workspace.

  • Don't grant any user administrative access to your DNS server to whom you wouldn't also give super admin privileges in Cloud Identity or Google Workspace.

  • If you plan to deploy a workload on Google Cloud that has security requirements that aren't met by your existing DNS infrastructure, consider registering for that workload a new DNS domain that uses separate DNS servers or a managed DNS service.

Export audit logs to BigQuery

Cloud Identity and Google Workspace maintain multiple audit logs to keep track of configuration changes and other activities that might be relevant to the security of your Cloud Identity or Google Workspace account. The following table summarizes these audit logs.

Log Activities captured
Admin Actions performed in your Google Admin Console
Login Successful, unsuccessful, and suspicious sign-in attempts to your domain
Token Instances of authorizing or revoking access to third-party mobile or web applications
Groups Changes to groups and group memberships

You can access these audit logs either through the Admin Console or through the Reports API. For most audit logs, data is retained for 6 months.

If you are operating in a regulated industry, retaining audit data for 6 months might not be sufficient. To retain data for a longer period of time, configure audit logs to be exported to BigQuery.

To limit the risk of unauthorized access to the exported audit logs, use a dedicated Google Cloud project for the BigQuery dataset. To keep the audit data safe from tampering or deletion, grant access to the project and dataset on a least-privilege basis.

The Cloud Identity and Google Workspace audit logs are complementary to Cloud Audit Logs logs. If you also use BigQuery to collect Cloud Audit Logs logs and other application-specific audit logs, you can correlate login events to activities that a user has performed in Google Cloud or in your applications. Being able to correlate audit data across multiple sources can help you detect and analyze suspicious activity.

Setting up BigQuery exporting requires a Google Workspace Enterprise license. After you set up the main audit logs, these are exported for all users, including those users without a Google Workspace license. Certain logs such as the Drive and Mobile audit logs are exported for users that have at least a Google Workspace Business license.

If you use Cloud Identity Free for the majority of your users, you can still export to BigQuery by adding Google Workspace Enterprise to your existing Cloud Identity account and purchasing Google Workspace licenses for a selected set of administrators.

Organizations

Organizations let you organize resources into a hierarchy of projects and folders, with the organization node being the root. Organizations are associated with a Cloud Identity or Google Workspace account, and they derive their name from the primary domain name of the associated account. An organization is created automatically when a user from the Cloud Identity or Google Workspace account creates a first project.

Each Cloud Identity or Google Workspace account can have only a single organization. In fact, it's not possible to create an organization without a corresponding account. Despite this dependency, you can grant users from multiple different accounts access to resources in a single organization:

Grant users from multiple accounts access to resources.

The flexibility to reference users from different Cloud Identity or Google Workspace accounts lets you separate how you treat accounts and organizations. You can separate the decision of how many Cloud Identity or Google Workspace accounts you need in order to manage your users from the decision of how many organizations you need in order to manage your resources.

The number of organizations that you create and their purposes can profoundly impact your security posture, the autonomy of your teams and departments, and the consistency and efficiency of your administration.

The following sections describe best practices for deciding how many organizations to use.

Use as few organizations as possible, but as many as necessary

The resource hierarchy of an organization lets you reduce the effort of managing IAM policies and organizational policies by taking advantage of inheritance. By configuring policies at the folder or organization level, you ensure that policies are applied consistently across a sub-hierarchy of resources, and you avoid repetitive configuration work. To minimize your administrative overhead, it's best to use as few organizations as possible.

In contrast, you can gain additional flexibility and administrative autonomy by using multiple organizations. The following sections describe when you might require such additional flexibility or autonomy.

In any case, when you are deciding how many organizations to use, consider all requirements that suggest using multiple organizations. Then use the smallest number of organizations that satisfies your requirements.

Use organizations to delineate administrative authority

Within a resource hierarchy, you can grant permissions at the resource, project, or folder level. The ultimate level at which you can grant a user permissions is the organization.

A user who has been assigned the Organization Administrator role at the organization level has full control over the organization, its resources, and its IAM policies. An Organization Administrator can take control of any resource within the organization and is free to delegate administrative access to any other user.

However, the capabilities of an Organization Administrator are confined to the organization, making the organization the ultimate scope of administrative authority:

  • An Organization Administrator cannot access any resources in other organizations unless explicitly granted permission.
  • No user outside the organization can take control away from an Organization Administrator of that organization.

The right number of organizations to use depends on the number of independent groups of administrative users in your company:

  • If your company is organized by function, you might have a single department that's in charge of overseeing all Google Cloud deployments.
  • If your company is organized by division or owns a number of autonomously-run subsidiaries, then there might not be a single department that's in charge.

If a single department is in charge of overseeing Google Cloud deployments, it's best to use a single Google Cloud organization node. Within the organization, use folders to structure resources and grant different levels of access to other teams and departments.

If you are dealing with multiple independent departments, trying to centralize administration by using a single organization might cause friction:

  • If you designate a single department to manage the organization, you might face resistance from other departments.
  • If you let multiple teams or departments co-own a single organization, it might be difficult to maintain a consistent resource hierarchy and to ensure that IAM policies and organizational policies are used consistently across your resources.

To prevent this kind of friction, use multiple organizations and create separate folder structures in each organization. By using separate organizations, you establish boundaries between different groups of administrative users, thus delineating their administrative authority.

Use a separate staging organization

To help ensure consistency and avoid repetitive configuration work, organize your projects into a hierarchy of folders and apply IAM policies and organizational policies at the folder or organization level.

There is a downside of having policies that apply to many projects and resources. Any change to the policy itself or the resource hierarchy the policy applies to might have far-reaching and unintended consequences. To mitigate this risk, it's best to test policy changes before you apply them in your main organization.

We recommend that you create a separate staging organization. This organization helps you test resource hierarchy changes, IAM policies, organizational policies, or other configuration that have potential organization-wide impact such as access levels and policies.

To ensure that the results of tests or experiments conducted in the staging organization also apply to the production organization, configure the staging organization to use the same folder structure as your main organization, but with only a small number of projects. At any point, the IAM and organizational policies in the staging organization should either match the policies of your production organization or should reflect the next version of policies that you intend to apply to your production organization.

As the following diagram shows, you use your staging Cloud Identity or Google Workspace account as a basis for the staging organization. You use the staging account (or the external IdP that your staging account is integrated with) to create dedicated test users and a group structure that mirrors the groups you use in your production Cloud Identity or Google Workspace account. You can then use these dedicated test users and groups to test IAM policies without impacting existing users.

Using your account as a basis for staging.

Avoid using a separate testing organization

For each production workload that you plan to deploy on Google Cloud, you probably need one or more testing environments, which your development and DevOps teams can use to validate new releases.

From a security perspective, to prevent untested releases from accidentally impacting production workloads, you want to cleanly separate your test environments from your production environments. Similarly, the two types of environments have different requirements for IAM policies. For example, in order for you to grant developers and testers the flexibility they need, the security requirements for your testing environments might be substantially looser than those of your production environments.

As the following diagram shows, from a configuration perspective you want to keep your test environments as similar to your production environments as possible. Any divergence increases the risk that a deployment that worked properly in a test environment fails when deployed to a production environment.

Keeping test environments similar to production environments.

To strike a balance between keeping environments isolated and consistent, use folders within the same organization to manage testing and production environments:

  • Apply any IAM policies or organizational policies that are common across environments at the organizational level (or by using a common parent folder).
  • Use the individual folders to manage IAM policies and organization policies that differ between different types of environments.

Don't use your staging organization for managing testing environments. Testing environments are critical to the productivity of development and DevOps teams. Managing such environments in your staging environment would restrict your ability to use the staging organization to experiment with and test policy changes; any such change might disrupt the work of these teams. In short, if you use a staging organization to manage testing environments, you undermine the purpose of your staging organization.

Use a separate organization for experimenting

To get the most out of Google Cloud, let your development, DevOps, and operations teams familiarize themselves with the platform and expand their experience by running tutorials. Encourage them to experiment with new features and services.

Use a separate organization as the sandbox environment to support these types of experimental activities. By using a separate organization, you can keep experiments unencumbered by any policies, configuration, or automation that you use in your production organization.

Avoid using your staging organization for experimenting. Your staging environment should use IAM and organization policies that are similar to your production organization. Therefore, the staging environment is likely to be subject to the same limitations as your production environment. At the same time, relaxing policies in order to allow experiments would undermine the purpose of your staging organization.

To prevent your experimental organization from becoming disorganized, from generating excessive cost, or from becoming a security risk, issue guidelines that define how teams are allowed to use the organization, and who bears responsibility for maintaining the organization. Additionally, consider setting up automation to automatically delete resources, or even entire projects, after a certain number of days.

As the following diagram shows, when you create an organization for experimenting, you first create a dedicated Cloud Identity account. You then use the existing users from your main Cloud Identity or Google Workspace account to grant users access to the experimental organization.

Experiment organization.

To manage the additional Cloud Identity account, you need at least one super admin user account in the Cloud Identity account. For information about how to secure these super-admin user accounts, see Super administrator account best practices.

Use domain-restricted sharing to enforce trust relationships

IAM policies let you add any valid Google identity as a member. This means that when you edit the IAM policy of a resource, project, folder, or organization, you can add members from different sources, including the following:

  • Users from the Cloud Identity or Google Workspace account that the organization is associated with, as well as service accounts from the same organization
  • Users from other Cloud Identity or Google Workspace accounts
  • Service accounts from other organizations
  • Consumer user accounts, including gmail.com users and consumer accounts that use a corporate email address

Being able to reference users from different sources is useful for scenarios and projects where you need to collaborate with affiliates or other companies. In most other cases, it's best to constrain IAM policies to only allow members from trusted sources.

Use domain-restricted sharing to define a set of trusted Cloud Identity or Google Workspace accounts from which you want to allow members to be added to IAM policies. Define this organizational policy either at the organization level (so that it applies to all projects) or at a folder near the top of the resource hierarchy (to allow certain projects to be exempted).

If you use separate Cloud Identity or Google Workspace accounts and organizations to segregate staging, production, and experimenting environments, use domain-restricted sharing policies to enforce the segregation as listed in the following table:

Organization Trusted Cloud Identity or Google Workspace account
Staging Staging
Production Production
Experiments Production

Use neutral domain names for organizations

Organizations are identified by a DNS domain name such as example.com. The domain name is derived from the primary domain name of the associated Cloud Identity or Google Workspace account.

If there is a canonical DNS domain name that is used throughout your company, use that domain as primary domain in your production Cloud Identity or Google Workspace account. By using the canonical DNS name, you ensure that employees can easily recognize the name of the organization node.

If your company has several subsidiaries or owns a variety of different brands, there might not be a canonical domain name. Rather than arbitrarily picking one of the existing domains, consider registering a new DNS domain that is neutral and dedicated for use by Google Cloud. By using a neutral DNS name, you avoid expressing a preference for a specific brand, subsidiary, or department within your company, which could negatively affect cloud adoption. Add your other, brand-specific domains as secondary domains so that they can be used in user IDs and for single sign-on.

Use billing accounts across Google Cloud organizations

Billing accounts define who pays for a given set of Google Cloud resources. Although billing accounts can exist outside of a Google Cloud organization, they are most commonly associated with an organization.

When billing accounts are associated with an organization, they are considered a sub-resource of the organization and are subject to IAM policies defined within the organization. Most importantly, this means that you can use the Billing IAM roles to define which users or groups are allowed to administer or use an account.

A user who has been granted the Billing Account User role can link a project to a billing account, causing the resources to be billed to this account. Linking a project to a billing account works within the same organization, but also across organizations.

If you use multiple organizations, you can take advantage of the fact that billing accounts can be used across organizations. This lets you decide how many billing accounts you need independent of how many organizations you need.

The right number of billing accounts depends exclusively on your commercial or contractual requirements such as currency, payment profile, and the number of separate invoices you need. As you did with accounts and organizations, in order to minimize complexity, you want to use the smallest number of billing accounts that satisfies your requirements.

To break down costs accrued across multiple organizations, configure your billing account to export billing data to BigQuery. Each record exported to BigQuery not only contains the project name and ID, but also the ID of the organization the project is associated with (in the project.ancestry_numbers field).

What's next