Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to extend list of group members #134

Open
vladimirblahoz opened this issue Jul 8, 2024 · 8 comments
Open

Add an option to extend list of group members #134

vladimirblahoz opened this issue Jul 8, 2024 · 8 comments

Comments

@vladimirblahoz
Copy link

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
Copy link
Collaborator

Breee commented Jul 8, 2024

Example?

@vladimirblahoz
Copy link
Author

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
Copy link
Collaborator

Breee commented Jul 8, 2024

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

@vladimirblahoz
Copy link
Author

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
Copy link
Collaborator

Breee commented Jul 8, 2024 via email

@vladimirblahoz
Copy link
Author

vladimirblahoz commented Jul 8, 2024

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
Copy link
Collaborator

Breee commented Jul 8, 2024

  • 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
Copy link
Author

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 👍
🙇‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants