K8s-config-connector: Does IAMPolicyMember HAVE to be immuatable?

[red8888]

I want to manage some permissions with kcc but this might be a deal breaker:
cannot patch "myapp" with kind IAMPolicyMember: admission webhook "deny-immutable-field-updates.cnrm.cloud.google.com" denied the request: the IAMPolicyMember's spec is immutable

I'd like to control some permissions in a gitops sort of way and allow users to modify role bindings and deploy and have them be updated. This causes the deploys to fail because we have to manually delete the object first.

Is there any way to update/replace IAM resources with kcc? otherwise those resources aren't very flexible or as useful

[caieo]

Hi @red8888, thanks for reaching out with your use case & asking this question. Unfortunately, IAMPolicyMember is immutable, but if you want to modify role bindings, you should be able to use IAMPolicy instead. As mentioned in our documentation here, you can't use IAMPolicy with IAMPolicyMember. Let us know if you have additional questions on using IAMPolicy or if that is what you're looking for.

[red8888]

Thanks for responding!

I actually think IAMPolicy is super dangerous to use with kcc because of its dynamic nature. I just recently accidentally clobbered ALL of my project level bindings with this KCC resource when testing it out (I applied it at the project level).

If I used IAMPolicy at the bucket level, that will have to be the authoritative config- I might want to manually or through another IaC tool update the bucket's role bindings though. Although, if I added a condition to my IAMPolicy resources would that still cause them to clobber all existing role bindings where they are attached?

[caieo]

@red8888, sorry to hear that! I think one step you can take to prevent KCC from clobbering your IAM policies is to use the cnrm.cloud.google.com/deletion-policy: "abandon" annotation so that if the k8s object is accidentally removed, the underlying GCP object is abandoned instead of deleted.

I'm not sure I completely understand what you're describing regarding using IAMPollicy at bucket level/adding conditions to your IAMPolicy. You should be able to add conditions to your IAMPolicy without issue (the spec is mutable except for the spec.resourceRef field). For more info, check out our documentation on IAMPolicy and IAMPolicyMember resources.

[Atoms]

I also stumbled upon IAMPolicy issues with experimenting, just adding a new account and not referencing all previously defined accounts I removed default project service accounts with this, so I also keep my distance from IAMPolicy and would like to see IAMPolicyMember as mutable.

[red8888]

@caieo I think the issue is that IAMPolicy is authoritative so it will override all existing bindings when it is applied- thats what happened to me. Another IaC tool, terraform, provides authoritative and non-authoritative resources for managing role bindings: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam

If a bindings is managed authoritatively it will assert the membership it has configured. BUT, at least with the terraform resource I tested, adding conditions seems to make a binding unique- so an authoritative binding on the same role without the condition will not override it.

This is what I was talking about with adding a condition. It would really be a hack in this case though to work around the lack of a non-authoritative resource like IAMPolicyMember which _is_ mutable.

[maqiuyujoyce]

Hi @red8888 and @Atoms , thank you for your follow up. Unfortunately, right now when you apply the IAMPolicy resource, it will override all the existing bindings. We have recognized the issue and plan to add merging support into the IAMPolicy resource. With the merging support and Service Side Apply, IAMPolicy doesn't have to be a full intent of the permission configuration for the resource. You can specify a partial list of bindings you are interested in, then Config Connector will merge (instead of overriding) the partial list into the live state (all the existing IAM bindings). You will be able to manage the bindings that you specified later.

Do you think that will fit your use case?

[red8888]

@maqiuyujoyce I think that would solve my issue. So I could apply a IAMPolicy resource to a specific StorageBucket resource for example non-authoritatively? IAMPolicy supports being applied to specific resources not just folders and projects right?

Also, I might have created a dup: https://github.com/GoogleCloudPlatform/k8s-config-connector/issues/196

[xiaobaitusi]

Yes, IAMPolicy supports other resources per https://cloud.google.com/config-connector/docs/reference/resource-docs/iam/iampolicy.

We are tentatively evaluating a couple of approaches to manage role-member bindings for a specific resource partially/non-authoritatively, maybe with a separate CRD.

The idea is that you can still use IAMPolicy to specify a fully authoritative intent if prefer; or using the new CRD to specify a partial list of role-member bindings, then KCC will ensure the partial list of role-member bindings are added correctly into the existing IAM policy with the rest untouched, on deletion KCC will only remove those partial bindings. The list of bindings is mutable of course.

Does this idea sound reasonable from your use case?

[red8888]

Yes that is what I'm looking for. What we are talking about has been implemented in terraform like this: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam#google_project_iam_member

I guess it makes sense to follow the same pattern with kcc. separate CRDs for authoritative/non-authoritative like how terraform uses separate resource types for those use cases. Just need to make sure people know you can use both at the same time!

[lostick]

I recently came across the same issue. If I create an IAMPolicy, it removes all members in the compute subnet.
Terraform resource google_compute_subnetwork_iam_member preserves the bindings.

You can specify a partial list of bindings you are interested in, then Config Connector will merge (instead of overriding) the partial list into the live state (all the existing IAM bindings). You will be able to manage the bindings that you specified later.

@maqiuyujoyce that would be great.

[maqiuyujoyce]

Thanks for confirming, @lostick and @red8888 ! We are currently working on this feature and will keep you updated.