terraform plan should raise issues with terraform configuration before apply

[andrew-stclair]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Description

Currently when running a plan with bad terraform configuration, no error is raised.

For example, an organisation iam role that has a few permissions attached to it that are not valid will result in a terraform plan that passes without any errors/warnings, making it difficult to catch issues before applying the changes.

New or Affected Resource(s)

• google_*

Potential Terraform Configuration

resource "google_organization_iam_custom_role" "custom_role" {
  role_id     = "CustomRole"
  org_id      = var.org_id
  title       = "Custom Role"
  description = "This is a custom role."
  permissions = local.custom_role_permissions
}

locals {
  custom_role_permissions = [
    "accesscontextmanager.accesspolicies.list",
    "bigquery.tables.get",
    "bigquery.tables.list",
    "clientauthconfig.clients.listwithsecrets",
    "cloudsecurityscanner.scans.list",
    "deploymentmanager.deployments.getiampolicy",
    "firebaserules.rulesets.get",
    "iam.workloadidentitypoolproviders.list",
    "iam.workloadidentitypools.list",
    "logging.cmeksettings.get",
    "networkservices.meshes.getiampolicy",
    "pubsub.snapshots.getiampolicy",
    "pubsub.subscriptions.getiampolicy",
    "pubsub.topics.getiampolicy",
    "resourcemanager.folders.getiampolicy",
    "storage.buckets.get",
    "storage.buckets.getiampolicy",
    "storage.objects.get",
    "storage.objects.list"
  ]
}

This should fail in the plan, listing the permissions that are invalid in this context

References

No response

[slevenick]

Unfortunately I'm not sure this is feasible. To have plan-time checks for the validity of a given config we have a couple of options:

1. Keep the logic for determining the validity of a plan within the Terraform provider
2. Call an external API to confirm the validity of a plan

1 is not feasible for all cases because this logic is not available to us and can potentially change over time. We do try to validate plans whenever possible, but the nature of an expanding API makes it impossible for us to keep this logic up to date in all circumstances.

For example with the problem that you're running into around permissions, we could create a list of valid permissions for a custom role at a point in time. Over time I would expect this list to grow as new permissions are added to GCP. We would have to keep up to date with this list or else we are preventing users from using valid permissions because of outdated validation. Additionally any old version of the Terraform provider would be stuck using it's version of the valid list, which would require users to update to the latest version of the provider to use new permissions even though it's simply a list of strings. For these reasons we tend to not add validation if we expect a field's valid values to change over time.

2 is feasible if such an API exists, but I'm not aware of such an API in most cases.

[melinath]

AIP-163 gives guidelines for how APIs can provide a mechanism to validate requests. Most APIs do not implement this AIP. For APIs that do implement it (or something similar), I believe we could add support for calling it during the plan computation process (since it looks like we have access to configured clients from CustomizeDiff) but we would need to evaluate that on a case-by-case basis.

@andrew-stclair the issue as stated applies to all GCP resources. Although I hear you on the pain point and agree it would be good to get this implemented, the scope of an effort like that means this is unlikely to be actioned any time soon - and we can't ask any specific teams to take action to make it possible.

If you would like to limit this to just google_organization_iam_custom_role, we could forward it to a specific team for consideration (as Sam said, it doesn't look like the API for that resource supports it today, so the API would need to add support first.)