Drop support for *_iam_binding and *_iam_policy resources in official-providers

[AaronME]

What problem are you facing?

Provider Name: provider-gcp
Provider Version: all...

This issue grew out of a discussion in #squad-control-planes. Google has multiple apis which can be used to configure IAM for a resource. These APIs come in three varieties:

• *_iam_binding
• *_iam_policy
• *_iam_member

The behavior of these API calls make them incompatible with one another. Terraform calls this out in a collection of standard Notes which appear on all IAM resource pages:

Note:
google_project_iam_policy cannot be used in conjunction with google_project_iam_binding, google_project_iam_member, or google_project_iam_audit_config or they will fight over what your policy should be.

Note:
google_project_iam_binding resources can be used in conjunction with google_project_iam_member resources only if they do not grant privilege to the same role.

Note:
The underlying API method projects.setIamPolicy has a lot of constraints which are documented here. In addition to these constraints, IAM Conditions cannot be used with Basic Roles such as Owner. Violating these constraints will result in the API returning 400 error code so please review these if you encounter errors with this resource.

Lastly, terraform offers this warning:

Be careful!
You can accidentally lock yourself out of your project using this resource. Deleting a google_project_iam_policy removes access from anyone without organization-level access to the project. Proceed with caution. It's not recommended to use google_project_iam_policy with your provider project to avoid locking yourself out, and it should generally only be used with projects fully managed by Terraform. If you do use this resource, it is recommended to import the policy before applying the change.

If two users were to implement their permissions using different resources -- say one uses a *_iam_member and another uses a *_iam_policy, those resources would "fight" over the ultimate permissions available in the account. It is also possible, with google_project_iam_policy and google_organization_iam_policy to catastrophically leave an account or organization with zero permissions configured (to wipe out all IAM data).

How could Official Providers help solve your problem?

Given that Crossplane Managed Resources are meant to be deployed and reconciled individually, only *_iam_member behaves as a Managed Resource. We should drop support for the other two apis.

[AaronME]

In addition to the linked slack conversation, wanted to add the context that @donovanmuller , while testing project_iam_policy was able to wipe out all permissions for crossplane-playground. See this message.

[djeremiah]

This makes sense, but only as long as a user can arrive with an IAM policy they want to manage with Crossplane and convert it into a set of IAM members without any loss of functionality. It won't always be a nice conversation, since people will already be creating those policies and might not like to have to break them apart. I think protecting users from themselves is an idea with its heart in the right place, but Crossplane isn't really positioning itself as a "we know better than you" tool. It's meant to be a high fidelity representation of the underlying cloud resources; if google will let you craft an access policy that will lock you out, then so be it. In general, we should let you do that too.

[bradkwadsworth-mw]

I think it would be very beneficial to at least allow *_binding resources. One of the biggest hurdles we have right now is the one-to-one nature of *_member resources especially in compositions. This has forced us to create helm charts that loop over a list to create multiple iam member XRCs. With *_bindings we could identify the roles we would like to allow in a composition and tie that to a list of members in a definition like the following.

my-folder.yaml

...
spec:
  parameters:
    admins:
    - user:[email protected]
    - group:[email protected]
    - serviceAccount:[email protected]
...

compositions.yaml

resources:
- name: folder_admins
  base:
    apiVersion: cloudplatform.gcp.upbound.io/v1beta1
    kind: FolderIAMBinding
    spec:
      forProvider:
        role: roles/resourcemanager.folderAdmin
...
  patches:
  - type: FromCompositeFieldPath
    fromFieldPath: spec.parameters.admins
    toFieldPath: spec.forProvider.members
...
- name: project_creators
  base:
    apiVersion: cloudplatform.gcp.upbound.io/v1beta1
    kind: FolderIAMBinding
    spec:
      forProvider:
        role: roles/resourcemanager.projectCreator
...
  patches:
  - type: FromCompositeFieldPath
    fromFieldPath: spec.parameters.admins
    toFieldPath: spec.forProvider.members

[github-actions]

This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[github-actions]

This issue is being closed since there has been no activity for 14 days since marking it as stale. If you still need help, feel free to comment or reopen the issue!