IAMPolicyMember: allow mapping of member and multiple roles on the project

[govinda-attal]

As the intent of IAMPolicy custom resource is to be full declaration at project level, and IAMPolicyMember is too granular for our use-case. It doesn't allow to specify multiple roles.

IAM-Policy-Member

It could be great to have this extended or have additional CR say IAMPolicyMemberMapping where one member could be mapped to multiple resources.

Also, it would nice to have IAMPolicyMember support custom roles. https://github.com/GoogleCloudPlatform/k8s-config-connector/issues/78

[tsawada]

It'd be great if IAMPolicyMember supports multiple roles, just like how it is grouped by members on the GCP Web console: https://console.cloud.google.com/iam-admin/iam Currently, we have to prepare one yaml config per a role per a member. For resources like project where a member typically has many roles, we have to deal with lots of boilerplate configs.

suggested: ↓ adding roles, a list of role: string and condition

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: kcc-iam-policy
spec:
  memberFrom:
    serviceAccountRef:
      name: service-account-for-kcc
  roles:
    - role: roles/storage.admin
    - role: roles/compute.admin
    - role: roles/network.admin
    - role: roles/iam.admin
      condition:
        title: some-condition
        expression: some-condition
  resourceRef:
    kind: Project
    external: projects/${PROJECT_ID?}

Without roles being available, we have to maintain 4 times more amount of text for the same settings.

[diviner524]

@tsawada Have you checked IAMPartialPolicy [1]? It lets you specify multiple roles in one Config Connector resource. Are there any feature gaps if you try to use this resource instead of IAMPolicyMember?

[1] https://cloud.google.com/config-connector/docs/reference/resource-docs/iam/iampartialpolicy

[tsawada]

Hi @diviner524, thanks for your suggestion. I took a look at IAMPartialPolicy, and I agree that it is an improvement compared to IAMPolicyMember. However, it is still not desirable for us. Using IAMPartialPolicy, the example I raised on the above comment looks like this, which is still a few times more text compared to what I suggested.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: kcc-iam-policy
spec:
  bindings:
    - role: roles/storage.admin
      members:
        - memberFrom: null
          serviceAccountRef:
            name: service-account-for-kcc
    - role: roles/storage.admin
      members:
        - memberFrom: null
          serviceAccountRef:
            name: service-account-for-kcc
    - role: roles/compute.admin
      members:
        - memberFrom: null
          serviceAccountRef:
            name: service-account-for-kcc
    - role: roles/network.admin
      members:
        - memberFrom: null
          serviceAccountRef:
            name: service-account-for-kcc
    - role: roles/iam.admin
      condition:
        title: some-condition
        expression: some-condition
      members:
        - memberFrom: null
          serviceAccountRef:
            name: service-account-for-kcc
  resourceRef:
    kind: Project
    external: 'projects/${PROJECT_ID?}'

My point is that it'd be useful to have a resource that focuses on a member (which is what the web console is doing), rather than focusing on the role side. It might contradict with how these resources are structured internally though.

[lazarillo]

While this is a hassle because the built template is huge, I don't feel that this is too challenging or too much boilerplate in the repo if you use helm templating. Eg, do something like

{{- range $role := $.Values.roles }}
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
...
spec:
  role: roles/{{ $role }}
...
---
{{- end }}

Wouldn't something like that solve it for you?

[lazarillo]

Something like above also lets you have a different config connector "object" for each role, which is nice at some point so that things can be removed / edited in a more fine-grained fashion.

[mmonaco]

A related use-case to this: AFAICT I can't fully declare a member's (service account in particular) roles with assurance that anything else would be deleted. With the syntax proposed, or perhaps slightly modified to take a repeated list of resource+role pairs, would it be possible to lock down a single sa?