Domain restricted sharing

Domain restricted sharing lets you limit resource sharing based on a domain or organization resource. When domain restricted sharing is active, only principals that belong to allowed domains or organizations can be granted IAM roles in your Google Cloud organization.

Methods for restricting sharing by domain

There are several ways that you can use Organization Policy Service to limit resource sharing based on domain or organization resource:

  • A custom organization policy referencing the iam.googleapis.com/AllowPolicy resource: You can use a custom organization policy to allow roles to be granted to only a specific set of principals.

    With this method, you use the following CEL functions to define who can be granted a role in your organization:

    To allow roles to be granted to all principals in your organization, specify your organization's principal set in the memberInPrincipalSet function include the organization's principal set in the constraint.

    To learn more about how to create custom organization policies using these CEL functions, see Use custom organization policies to implement domain restricted sharing.

  • The iam.managed.allowedPolicyMembers managed constraint: You can enforce this managed constraint to allow roles to be granted to only the principals and principal sets that you list in the constraint.

    With this managed constraint, you list the principals and principal sets that you want to allow roles to be granted to. However, this method is less flexible than using custom organization policies. For example, you can't configure allowed principals based on member type, or prevent specific principals from being granted roles.

    To allow roles to be granted to all principals in your organization, include the organization's principal set in the constraint.

    To learn how to set this constraint, see Use the iam.managed.allowedPolicyMembers constraint to implement domain restricted sharing.

  • The iam.allowedPolicyMemberDomains predefined constraint: You can enforce this predefined constraint to only allow roles to be granted to principals in your organization. You can limit access based on your organization resource ID or your Google Workspace customer ID. To see differences between these identifiers, see Organization resource ID versus Google Workspace customer ID on this page.

    This constraint doesn't let you configure exceptions for specific principals. For example, imagine that you need to grant a role to a service agent in an organization that enforces the iam.allowedPolicyMemberDomains constraint. Service agents are created and managed by Google, so they aren't part of your organization, your Google Workspace account, or your Cloud Identity domain. As a result, to grant a role to the service agent, you need to disable the constraint, grant the role, and then re-enable the constraint.

    You can override the organization policy at the folder or project level to change which users are allowed to be granted roles in which folders or projects. For more information, see Override the organization policy for a project.

    To learn how to set this constraint, see Use the iam.allowedPolicyMemberDomains constraint to implement domain restricted sharing.

How domain restricted sharing works

When you use an organization policy to enforce domain restricted sharing, no principals outside of the domains and individuals that you specify can be granted IAM roles in your organization.

The following sections outline some key details about how domain restricted sharing constraints work in your organization.

Constraints are not retroactive

Organization policy constraints are not retroactive. After a domain restriction is set, the limitation applies to allow policy changes made from that point forward, and not to any previous changes.

For example, consider two related organizations: examplepetstore.com and altostrat.com. You have granted an examplepetstore.com identity an IAM role in altostrat.com. Later, you decided to restrict identities by domain, and implemented an organization policy with the domain restriction constraint in altostrat.com. In this case, the existing examplepetstore.com identities wouldn't lose access in altostrat.com. From that point, you could only grant IAM roles to identities from the altostrat.com domain.

Constraints apply whenever an IAM policy is set

Domain restriction constraints apply to all actions where an IAM policy is set. This includes automated actions. For example, the constraints apply to changes that a service agent makes in response to another action. For example, if you have an automated service that imports BigQuery datasets, a BigQuery service agent will make IAM policy changes on the newly created dataset. This action would be restricted by the domain restriction constraint and blocked.

Constraints don't automatically include your domain

Your organization's domain isn't automatically added to the allowed list of a policy when you set the domain restriction constraint. To let principals in your domain be granted IAM roles in your organization, you must add your domain explicitly. If you don't add your domain and the Organization Policy Administrator role (roles/orgpolicy.policyAdmin) is removed from all users in your domain, then the organization policy becomes inaccessible.

Google groups and domain restricted sharing

If the domain restriction constraint is enforced in your organization, then you might not be able to grant roles to newly created Google groups, even if the groups belong to an allowed domain. This is because it can take up to 24 hours for a group to fully propagate through Google Cloud. If you can't grant a role to a newly created Google group, wait 24 hours and then try again.

Additionally, when evaluating whether a group belongs to an allowed domain, IAM only evaluates the group's domain. It doesn't evaluate the domains of any of the group's members. As a result, project administrators can bypass the domain restriction constraint by adding outside members to Google groups, and then granting roles to those Google groups.

To ensure that project administrators can't bypass the domain restriction constraint, the Google Workspace administrator should ensure that group owners cannot allow members from outside of the domain in the Google Workspace administrator panel.

Organization resource ID versus Google Workspace customer ID

If you use the iam.allowedPolicyMemberDomains predefined constraint to implement domain restricted sharing, then you can limit access based on either your organization resource ID or your Google Workspace customer ID.

Using your organization resource ID allows the following principals to be granted roles in your organization:

  • All workforce identity pools in your organization
  • All service accounts and workload identity pools in any project in the organization
  • All service agents associated with resources in your organization

Using your Google Workspace customer ID allows the following principals to be granted roles in your organization:

  • All identities in all domains, including subdomains, associated with your Google Workspace customer ID
  • All workforce identity pools in your organization
  • All service accounts and workload identity pools in any project in the organization
  • All service agents associated with resources in your organization.

If you want to implement domain restricted sharing for specific subdomains, then you need to create a separate Google Workspace account for each subdomain. For more information about managing multiple Google Workspace accounts, see Managing multiple organizations.