Unable to add an organization to domain restricted sharing org policy

[nlrussell]

TL;DR

When updating an org policy for domain restricted sharing to add a reference to a separate organization in the domains_to_allow field, the organization is not able to be found regardless of which format is used. This functionality works in the console, but not in Terraform. Referred to this GCP documentation for instructions.

Expected behavior

Locate the organization being allowlisted, then plan and apply successfully.

Observed behavior

Error: Organization not found

Terraform Configuration

module "domain-restricted-sharing" {
  source           = "../../modules/domain_restricted_sharing"
  policy_for       = "organization"
  organization_id  = var.organization_id
  domains_to_allow = var.domains_to_allow
}

For domains_to_allow, tried org ID (numeric string), domain name (example.com), and DIRECTORY_CUSTOMER_ID per this documentation.

Terraform Version

1.2.2
Provider version: hashicorp/google v4.84.0

Additional information

Many similar issues:

• https://github.com/hashicorp/terraform-provider-google/issues/11911
• https://github.com/terraform-google-modules/terraform-google-org-policy/issues/56
• https://www.googlecloudcommunity.com/gc/General-Misc-Q-A/Domain-restricted-sharing-is-not-working-as-expected/m-p/625059

[nlrussell]

Update:

We continued testing with 2 organizations (org1 and org2). For org1's DRS policy, granting the TF service account the Org Viewer role on org2 allowed us to add org2 to org1's DRS policy. However, the DRS policy updates are only successful in one-off TF runs, but not in automated pipelines where we see intermittent errors (same as before: "Organization not found"). In the UI, updating DRS policies has always worked, with or without the Org Viewer permissions between organizations.

Any idea why this would only work sometimes?

[roaks3]

One idea that could be worth following:

This modules uses a google_organization data source, which was updated in 5.0.0 to handle NotFound errors differently (notably, they now fail immediately). It could be the case that this configuration was relying on the previous behavior, and with the update it now fails. There is also the chance that an access error is getting wrapped up in this failure case somehow.

As a first step, I would verify the version of the provider being used (I see v4.84.0, but want to be sure), which could rule out the above theory.

[nlrussell]

Update:

We were able to resolve the intermittent pipeline issue. The Org Viewer role was not being granted in the authoritative IAM policy, so whenever the pipeline ran, it overwrote the Org Viewer role granted elsewhere.