Add an option to extend list of group members

[vladimirblahoz]

Hi,
I wasn't able to find any way of adding another user to an existing group with already defined memberships resource. New memberships only overwrite the list of members for a group.
This way we cannot contribute to a single group with users from different projects.
I was expecting something similar to an exhaustive property which is present in group roles resource or user roles resource.

[Breee]

Example?

[vladimirblahoz]

apiVersion: user.keycloak.crossplane.io/v1alpha1
kind: User
metadata:
  name: user
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    enabled: true
    realmId: acmecorp-00001
    username: user
    initialPassword:
      - temporary: false
        valueSecretRef:
          key: credentials
          name: initial-user-global-acmecorp-00001-admin-input-credentials
          namespace: keycloak-system
---
apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: role
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    name: role
    realmId: acmecorp-00001
---
apiVersion: group.keycloak.crossplane.io/v1alpha1
kind: Group
metadata:
  name: group
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    name: group
    realmId: acmecorp-00001
---
apiVersion: group.keycloak.crossplane.io/v1alpha1
kind: Roles
metadata:
  name: group-roles
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    realmId: acmecorp-00001
    groupIdRef:
      name: group
    roleIdsRefs:
      - name: role
---
apiVersion: group.keycloak.crossplane.io/v1alpha1
kind: Memberships
metadata:
  name: membership
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    realmId: acmecorp-00001
    groupIdRef:
      name: group
    members:
      - user

This creates user with assigned group with single role. All good.
But if later somthing like this comes:

apiVersion: user.keycloak.crossplane.io/v1alpha1
kind: User
metadata:
  name: another-user
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    enabled: true
    realmId: acmecorp-00001
    username: another-user
    initialPassword:
      - temporary: false
        valueSecretRef:
          key: credentials
          name: initial-user-global-acmecorp-00001-admin-input-credentials
          namespace: keycloak-system
---
apiVersion: group.keycloak.crossplane.io/v1alpha1
kind: Memberships
metadata:
  name: another-membership
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    realmId: acmecorp-00001
    groupIdRef:
      name: group
    members:
      - another-user

The user another-user is given the group membership, however the user user loses it. The another-membership resource overwrites the existing list of group members.

[Breee]

does something like that work in terraform? 🤔
-> if not we need to build some custom controller for that

[vladimirblahoz]

Frankly, I have no clue (not a terraform specialist).
I was hoping that the functionality is very similar to assigning roles directly to users with Roles.user.keycloak.crossplane.io resource having the exhaustive flag. Now reading the docs again it claims that "manually" added roles aren't removed with it, so now I'm not really sure that even this does what I expected from it.

[Breee]

Hm, i'll check that out and tell you asap 😄

…

On Mon, Jul 8, 2024, 09:30 vladimirblahoz ***@***.***> wrote: Frankly, I have no clue (not a terraform specialist). I was hoping that the functionality is very similar to assigning roles directly to users with *Roles.user.keycloak.crossplane.io <http://Roles.user.keycloak.crossplane.io>* resource having the *exhaustive* flag. Now reading the docs again it claims that "manually" added roles aren't removed with it, so now I'm not really sure that even this does what I expected from it. — Reply to this email directly, view it on GitHub <#134 (comment)>, or unsubscribe <https:/notifications/unsubscribe-auth/AC3JPMJCTGYA3AF2E77JMB3ZLI52JAVCNFSM6AAAAABKQF3QGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJTGI2DAMZXHE> . You are receiving this because you commented.Message ID: ***@***.***>

[vladimirblahoz]

I have just checked that this (the roles situation) works:

apiVersion: user.keycloak.crossplane.io/v1alpha1
kind: User
metadata:
  name: user
  labels:
    username: user
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    enabled: true
    realmId: acmecorp-00001
    username: user
    initialPassword:
      - temporary: false
        valueSecretRef:
          key: credentials
          name: initial-user-global-acmecorp-00001-admin-input-credentials
          namespace: keycloak-system
---
apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: role
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    name: role
    realmId: acmecorp-00001
---
apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: role2
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    name: role2
    realmId: acmecorp-00001
---
apiVersion: user.keycloak.crossplane.io/v1alpha1
kind: Roles
metadata:
  name: user-roles1
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    realmId: acmecorp-00001
    roleIdsRefs:
      - name: role
    exhaustive: false
    userIdRef:
      name: user
---
apiVersion: user.keycloak.crossplane.io/v1alpha1
kind: Roles
metadata:
  name: user-roles2
spec:
  providerConfigRef:
    name: keycloak-default
  forProvider:
    realmId: acmecorp-00001
    roleIdsRefs:
      - name: role2
    exhaustive: false
    userIdRef:
      name: user

So apparently the Roles resource is able to append to the list of assigned roles and you can have as many of them as you want targeting the same user as long as the exhaustive attribute is set to false

[Breee]

• Well, https://registry.terraform.io/providers/mrparkers/keycloak/latest/docs/resources/group_memberships is designed to be a single source of truth it seems. As long as we do not implement our own controllers and rely on upjet, that's it's not possible to change that behaviour. --> i'll note that, as i'm in the process of writing some selfmanaged controllers for some resources

• If you say, "This way we cannot contribute to a single group with users from different projects" i'm wondering what your IAM structure is when using the keycloak provider and how you manage the roles.

• If you, e.g, use something like ArgoCD as gitops tool to sync everything into your cluster, you could combine that with a little helm wrapper and supply values.yaml files from different repositories easily. (See here

• If you don't use gitops tools. you might be able to write a pipeline that scrapes all the information from different project repos and creates the resource you need / build a hook that triggers some umbrella repository

[vladimirblahoz]

Thanks for the investigation!
First of all now that I have tested that the direct roles assignment works, we have a workaround and that's absolutely fine for now (since it sounds like quite a lot of work to make this work using Memberships).

We are using ArgoCD as gitops tool, so I'll check that link if that is an interesting solution for us 👍
🙇‍♂️