IAM policy management improvements

[yhrn]

We can't use project level IAMPolicy for our current use case since we need a more patch style behavior for adding policy bindings as discussed earlier with Google.

The suggested solution was introducing more fine grained resources, such as IAMPolicyBinding and IAMPolicyMember. This would be useful for other resource types as well since it is likely that we'd like to declare access to the same resource in multiple source code locations, e.g. a bucket might be declared together with the rest of the manifests for an application that writes to it but we also want to declare a viewer policy binding together with the manifests for another application that reads from it.

I also wonder how Project level IAMPolicy is meant to be used is since it removes "bootstrap type" policy bindings such as "Compute Engine default service account" that you get automatically when creating the project and even any policy bindings used to give Config Connector access to the project. It gets even worse if you at any point delete the IAMPolicy as that leaves you with no Project level access at all. I guess another way of putting it is that a difference between a Project IAMPolicy and an IAMPolicy for some other resource (especially if managed via Config Connector) is that you are very likely to irrevocably overwrite existing stuff for the former.

[owenhaynes]

I assume this is the similar as:

• Have Pubsub topic already exist
• Give IAMServiceAccount permission to publish on the pub sub topic?

As at the moment I don't see how you can do this.

[yhrn]

Not really, this is more:

• Have a PubSubTopic k8s resource
• Have a IAMPolicy k8s resource referencing the PubSubTopic
• Have a IAMPolicyBinding k8s resource that references the IAMPolicy and allows you to add (and remove) policy bindings from multiple places. This is particularly important when the resource is a GCP project as I described above.

[paulczar]

This is pretty critical for our use case too! We have resources from other places like terraform happening in the project as well, so having to specify the whole project worth of permissions via the CRDs doesn't work for us.

[kibbles-n-bytes]

Thanks everyone for the feedback! We plan to support this in the coming weeks (ETA by the end of October).

[nrobert13]

:+1:

[kibbles-n-bytes]

We have now introduced IAMPolicyMember in 0.3.1 that should ideally address this issue. For example, you can now set a particular IAM project-level role-member pair with something like the following:

apiVersion: iam.cnrm.cloud.google.com/v1alpha1
kind: IAMPolicyMember
metadata:
  name: iampolicymember-project-level-sample
spec:
  member: serviceAccount:my-service-account@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.admin
  resourceRef:
    kind: Project

[yhrn]

Great! We'll give this a go soon.

[kibbles-n-bytes]

Closing this out now that IAMPolicyMember has been available for a while. Feel free to open a new issue if IAM policy management is still a pain point.

[currankaushik]

Hi @kibbles-n-bytes, I was just wondering if there was any further discussion/plans around a potential IAMPolicyBinding resource that's authoritative for the given role. It's definitely not a showstopper for my particular use case, but for tracking/auditability, it might be nice to have something that's authoritative for a particular role, but not quite at the IAMPolicy extreme of authoritative for all roles across the resource. Thanks!