Restricting identities by domain

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.

There are three types of organization policies that you can use to restrict identities by domain:

• Custom organization policies referencing the iam.googleapis.com/AllowPolicy resource
• The iam.managed.allowedPolicyMembers managed constraint
• The iam.allowedPolicyMemberDomains predefined constraint

Before you begin

Choose which method you will use to implement domain restricted sharing. To learn more about the benefits and drawbacks of each method, see Methods for restricting sharing by domain.

Required roles

To get the permissions that you need to enforce domain restricted sharing, ask your administrator to grant you the Organization policy administrator (roles/orgpolicy.policyAdmin) IAM role on the organization. For more information about granting roles, see Manage access to projects, folders, and organizations.

You might also be able to get the required permissions through custom roles or other predefined roles.

Use custom organization policies to implement domain restricted sharing

1. Create a custom constraint that restricts which principals can be granted roles in your organization:

   1. Use the memberInPrincipalSet CEL function with your organization principal set to restrict role grants to members in your organization. To learn how to find your organization ID, see Retrieving an organization resource ID.

      For example, the following constraint restricts role grants to members in your organization:

      name: organizations/ORG_ID/customConstraints/custom.allowInternaldentitiesOnly
      methodTypes:
        - CREATE
        - UPDATE
      condition:
        "resource.bindings.all(
          binding,
          binding.members.all(member,
            MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID'])
          )
        )"
      actionType: ALLOW
      displayName: Only allow organization members to be granted roles
      

   2. Optionally, refine the constraint by adding additional CEL functions, joined with logical operators (&&, ||, or !). You can add any of the following functions:

      • memberInPrincipalSet
      • memberTypeMatches
      • memberSubjectMatches

      For example, the following constraint restricts role grants to members in your organization and to admin@example.com:

      name: organizations/ORG_ID/customConstraints/custom.allowInternaldentitiesOnly
      methodTypes:
        - CREATE
        - UPDATE
      condition:
        "resource.bindings.all(
          binding,
          binding.members.all(member,
            (
              MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID'])
              ||
              MemberSubjectMatches(member, ['user:admin@example.com'])
            )
          )
        )"
      actionType: ALLOW
      displayName: Only allow organization members and service agents to be granted roles
      

2. Set up the custom constraint:

   After you have created the YAML file for a new custom constraint, you must set it up to make it available for organization policies in your organization. To set up a custom constraint, use the gcloud org-policies set-custom-constraint command:

   gcloud org-policies set-custom-constraint CONSTRAINT_PATH

   Replace CONSTRAINT_PATH with the full path to your custom constraint file. For example, /home/user/customconstraint.yaml. Once completed, your custom constraints are available as organization policies in your list of Google Cloud organization policies. To verify that the custom constraint exists, use the gcloud org-policies list-custom-constraints command:

   gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

   Replace ORGANIZATION_ID with the ID of your organization resource. For more information, see Viewing organization policies.

3. Enforce the custom organization policy:

   You can enforce a boolean constraint by creating an organization policy that references it, and then applying that organization policy to a Google Cloud resource.

   Console

   1. In the Google Cloud console, go to the Organization policies page.

      Go to Organization policies

   2. From the project picker, select the project for which you want to set the organization policy.
   3. From the list on the Organization policies page, select your constraint to view the Policy details page for that constraint.
   4. To configure the organization policy for this resource, click Manage policy.
   5. On the Edit policy page, select Override parent's policy.
   6. Click Add a rule.
   7. In the Enforcement section, select whether enforcement of this organization policy is on or off.
   8. Optional: To make the organization policy conditional on a tag, click Add condition. Note that if you add a conditional rule to an organization policy, you must add at least one unconditional rule or the policy cannot be saved. For more information, see Setting an organization policy with tags.
   9. If this is a custom constraint, you can click Test changes to simulate the effect of this organization policy. For more information, see Test organization policy changes with Policy Simulator.
   10. To finish and apply the organization policy, click Set policy. The policy requires up to 15 minutes to take effect.

   gcloud

   To create an organization policy that enforces a boolean constraint, create a policy YAML file that references the constraint:

         name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
         spec:
           rules:
           - enforce: true
       

   Replace the following:

   • PROJECT_ID: the project on which you want to enforce your constraint.
   • CONSTRAINT_NAME: the name of the constraint you want to enforce. For example, compute.disableAllIpv6.

   To enforce the organization policy containing the constraint, run the following command:

       gcloud org-policies set-policy POLICY_PATH
       

   Replace POLICY_PATH with the full path to your organization policy YAML file. The policy requires up to 15 minutes to take effect.

Use the iam.managed.allowedPolicyMembers constraint to implement domain restricted sharing

POST https://orgpolicy.googleapis.com/v2/{parent=organizations/ORGANIZATION_ID}/policies

{
  "name": "organizations/ORG_ID/policies/CONSTRAINT_NAME",
  "spec": {
    "rules": [
      {
        "enforce": true,
        "parameters": {
          "allowedMemberSubjects": [
            "ALLOWED_MEMBER_1",
            "ALLOWED_MEMBER_2"
          ],
          "allowedPrincipalSets": [
            "ALLOWED_PRINCIPAL_SET_1",
            "ALLOWED_PRINCIPAL_SET_2"
          ]
        }
      }
    ]
  }
}

Use the iam.allowedPolicyMemberDomains constraint to implement domain restricted sharing

The domain restriction constraint is a type of list constraint. Google Workspace customer IDs and Google Cloud organization resource IDs can be added and removed from the allowed_values list of a domain restriction constraint. The domain restriction constraint does not support denying values, and an organization policy can't be saved with IDs in the denied_values list.

All domains associated with a Google Workspace account or organization resource listed in the allowed_values will be allowed by the organization policy. All other domains will be denied by the organization policy.

You can make an organization policy enforcing the domain restriction constraint conditional on any resource included in the list of supported resources. For example, Cloud Storage buckets, BigQuery datasets, or Compute Engine VMs.

gcloud org-policies set-policy POLICY_PATH

name: organizations/ORGANIZATION_ID/policies/iam.allowedPolicyMemberDomains
spec:
  rules:
  - condition: # This condition applies to the values block.
      expression: "resource.matchTag('ORGANIZATION_ID/environment', 'dev')"
    values:
      allowedValues:
      - PRINCIPAL_SET
  - values:
      allowedValues:
      - PRINCIPAL_SET

Only identities belonging to the organization resource ID or Google Workspace domain from the list of allowed_values will be allowed on IAM policies once this organization policy has been applied. Google Workspace human users and groups must be children of that organization resource or part of that Google Workspace domain, and IAM service accounts must be children of an organization resource associated with the given Google Workspace domain.

For example, if you created an organization policy with only the customer ID of your company's Google Workspace, only principals from that domain could be added to the IAM policy from that point forward.

Example error message

When the iam.allowedPolicyMemberDomains predefined constraint is violated by trying to add a principal that is not included in the allowed_values list, the operation will fail and then an error message will be displayed.

ERROR: (gcloud.projects.set-iam-policy) FAILED_PRECONDITION:
One or more users named in the policy do not belong to a permitted customer.

Retrieving an organization resource ID

You can get your organization resource ID using the Google Cloud console, the gcloud CLI, or the Cloud Resource Manager API.

gcloud organizations list

GET https://cloudresourcemanager.googleapis.com/v3/organizations:search{query=domain:altostrat.com}

After you have your organization resource ID, you need to use the correct identifier for the set of principals belonging to it. For example:

principalSet://iam.googleapis.com/organizations/01234567890123

For more information about IAM principal identifiers, see Principal identifiers.

Retrieving a Google Workspace customer ID

The Google Workspace customer ID used by the domain restriction constraint can be obtained in two ways:

gcloud organizations list

Configure exceptions for domain restricted sharing

Some Google Cloud services use service accounts, service agents, and other accounts to perform actions on your behalf. Domain restricted sharing can prevent these accounts from being automatically granted the IAM roles that they need, which can cause certain actions to fail.

The following table lists actions in Google Cloud that could be impacted by domain restricted sharing. It also lists the accounts that need to be granted roles automatically for these actions to succeed.

If you use custom organization policies or the iam.managed.allowedPolicyMembers managed constraint to implement domain restricted sharing, then consider adding these accounts as exceptions to your domain restricted sharing constraint. If you use the iam.allowedPolicyMemberDomains predefined constraint to implement domain restricted sharing, then you might need to force account access for these accounts to perform the listed actions.

Forcing account access

If you need to force account access for a project in violation of domain restrictions:

1. Remove the organization policy containing the domain restriction constraint.

2. Grant account access to the project.

3. Implement the organization policy with the domain restriction constraint again.

Alternatively, you can grant access to a Google group that contains the relevant service accounts:

1. Create a Google group within the allowed domain.

2. Use the Google Workspace administrator panel to turn off domain restriction for that group.

3. Add the service account to the group.

4. Grant access to the Google group in the IAM policy.