epam/edp-keycloak-operator

It is responsible for establishing a connection to provided Keycloak Server, reconciling realms, and clients according to the created CRs

Keycloak Operator

❗ Please refer to EDP documentation to get the main concepts and guidelines.

Get acquainted with the Keycloak Operator, the installation process, the quick start, and the local development guidelines.

Overview

Keycloak Operator is an EDP operator responsible for configuring existing Keycloak instances. The operator runs both on OpenShift and Kubernetes.

NOTE: Operator is platform-independent, which is why there is a unified instruction for deployment.

Prerequisites

1. Linux machine or Windows Subsystem for Linux instance with Helm 3 installed;
2. Cluster admin access to the cluster;

Installation Using Helm Chart

To install the Keycloak Operator, follow the steps below:

1. To add the Helm EPAMEDP Charts for a local client, run "helm repo add":

   helm repo add epamedp https://epam.github.io/edp-helm-charts/stable

2. Choose the available Helm chart version:

   helm search repo epamedp/keycloak-operator -l
   NAME                           CHART VERSION   APP VERSION     DESCRIPTION
   epamedp/keycloak-operator      1.21.0          1.21.0          A Helm chart for EDP Keycloak Operator
   epamedp/keycloak-operator      1.20.0          1.20.0          A Helm chart for EDP Keycloak Operator

   NOTE: It is highly recommended to use the latest stable version.

3. Full chart parameters available in deploy-templates/README.md.

4. Install the operator in the namespace with the helm command; find below the installation command example:

   helm install keycloak-operator epamedp/keycloak-operator --version <chart_version> --namespace <edp-project> --set name=keycloak-operator

5. Check the namespace containing Deployment with your operator in running status.

Quick Start

1. Create a User in the Keycloak Master realm, and assign a create-realm role.

2. Insert newly created user credentials into Kubernetes secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name:  keycloak-access
   type: Opaque
   data:
     username: dXNlcg==   # base64-encoded value of "user"
     password: cGFzcw==   # base64-encoded value of "pass"

3. Create Custom Resource kind: Keycloak with Keycloak instance URL and secret created on the previous step:

   apiVersion: v1.edp.epam.com/v1
   kind: Keycloak
   metadata:
     name: keycloak-sample
   spec:
     secret: keycloak-access             # Secret name
     url: https://keycloak.example.com   # Keycloak URL

   Wait for the .status field with status.connected: true

4. Create Keycloak realm and group using Custom Resources:

   apiVersion: v1.edp.epam.com/v1
   kind: KeycloakRealm
   metadata:
    name: keycloakrealm-sample
   spec:
    realmName: realm-sample
    keycloakRef:
      name: keycloak-sample
      kind: Keycloak

   apiVersion: v1.edp.epam.com/v1
   kind: KeycloakRealmGroup
   metadata:
     name: argocd-admins
   spec:
     name: ArgoCDAdmins
     realmRef:
       name: keycloakrealm-sample
       kind: KeycloakRealm

   Inspect available custom resource and CR templates folder for more examples.

Preventing the operator from deleting resources

To prevent the operator from deleting resources from Keycloak, add the edp.epam.com/preserve-resources-on-deletion: "true" annotation to the resource.

apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealm
metadata:
 name: keycloakrealm-sample
 annotations:
   edp.epam.com/preserve-resources-on-deletion: "true"
spec:
 realmName: realm-sample
 keycloakRef:
    name: keycloak-sample
    kind: Keycloak

Local Development

To develop the operator, first set up a local environment, and refer to the Local Development page.

Development versions are also available from the snapshot Helm Chart repository page.

Related Articles

• Install EDP

edp-keycloak-operator's Issues

ClusterKeycloakRealm - add browserFlow setting

Is your feature request related to a problem? Please describe.
ClusterKeycloakRealm doesn't contain browserFlow settings, which can only be configured with KeycloakRealm CR.

Describe the solution you'd like
Add to the ClusterKeycloakRealm CR browserFlow functionality as implemented in the KeycloakRealm.

Describe alternatives you've considered
Use only KeycloakRealm.

userFederationProviders userFederationMappers

It would be nice to be able to define userFederationProviders - userFederationMappers within the realm CR. This is the missing piece that would allow us to streamline a 100% gitops deployment of Keycloak.

Default realm role is no longer works and required alignment with the keycloak changes

We need to align the changes with default role processing for realm, since isDefault: true flag for KeycloakRealm is no longer works:

Default roles processing improvement
Default roles are now internally stored as composite roles of a new role usually named default-roles-. Instead of assigning both realm and all client default roles directly to newly created users or users imported through Identity Brokering, just the role is assigned to them and the rest of default roles are assigned as effective roles. This change improves performance of default roles processing, especially with larger number of clients, because it is no longer necessary to go through all clients.

We should reflect these changes in the realm controller:

edp-keycloak-operator/pkg/client/keycloak/adapter/gocloak_adapter_roles.go

Line 154 in 4ac64f4

func (a GoCloakAdapter) makeRoleDefault(realmName string, role *dto.PrimaryRealmRole) error {

KeycloakRealmRole CR with status duplicated

Describe the bug

Some KeycloakRealmRole CRs have the status duplicated.
This status occurs when we create a role that already exists in the Keycloak.

If KeycloakRealmRole CR has the status duplicated, the operator always skips it in the next reconciliation.
If such roles are removed from the keycloak UI - the operator doesn't recreate it.

To Reproduce

What did you do?

• Create a KeycloakRealmRole CR with the existing role in the Keycloak.
• Remove the role from the Keycloak UI.
• Retrigger reconciliation(restart operator or update related KeycloakRealmRole CR).

What did you expect to see?

KeycloakRealmRole status OK.

What did you see instead? Under which circumstances?

KeycloakRealmRole status duplicated.

Keycloak URL CA

Is your feature request related to a problem? Please describe.
I want to connect to Keycloak cluster service, which is HTTPS, how to trust service CA certificate?
Because i got error, certificate is trusted by unknown authority.

Describe the solution you'd like
Add way to add CA parameter, e.g. from secret.

Describe alternatives you've considered
Connect over HTTP service or Ingress.

Additional context
Add any other context or screenshots about the feature request here.

Enable secret support in KeycloakClient resource

We need to be able to use secret from Kubernetes Secret object instead of definition in spec for KeycloakClient:

apiVersion: v1.edp.epam.com/v1
kind: KeycloakClient
metadata:
  name: keycloakclient-sample
spec:
  realmRef:
    name: keycloakrealm-sample
    kind: KeycloakRealm
  advancedProtocolMappers: true
  clientId: agocd
  directAccess: true
  public: false
  secret: ''
  webUrl: https://argocd.example.com
  defaultClientScopes:
    - groups
  redirectUris:
    - /url1/*
    - /url2/*

Related issue: #20

Wrong auth flow reconciliation behavior

Describe the bug

Error during auth flow subflows and executions order adjustment

To Reproduce

What did you do?

You need to create a auth flow with execution and sub auth flow

What did you expect to see?

Successful reconciliation

What did you see instead? Under which circumstances?

unable to sync auth flow

Publish 1.17.0 to OperatorHub

We need to publish the latest release on OperatorHub

Operator does not reconcile secret data

Describe the bug
I am trying to set up a Kubernetes Cluster with Argo CD and Keycloak and I am using the Keycloak Operator to configure Keycloak. The Keycloak client is being deployed without spec.secret set and looks like the following:

apiVersion: v1.edp.epam.com/v1
kind: KeycloakClient
metadata:
  name: argocd
  namespace: argocd
spec:
  advancedProtocolMappers: true
  clientId: argocd
  defaultClientScopes:
    - profile
    - email
  directAccess: true
  realmRef:
    kind: ClusterKeycloakRealm
    name: platform
  webUrl: <Removed>

To allow Argo CD to read the client secret from the generated k8s secret, the k8s secret must be annotated with app.kubernetes.io/part-of: argocd (see note here https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#2-configure-argo-cd-for-sso). To do so I am trying to use server side apply, which worked with the legacy Keycloak Operator from Red Hat:

apiVersion: v1
kind: Secret
metadata:
  annotations:
    argocd.argoproj.io/sync-options: 'ServerSideApply=true, Prune=false, Delete=false'
  labels:
    app.kubernetes.io/part-of: argocd
  name: keycloak-client-argocd-secret
  namespace: argocd

With the EDP Keycloak Operator this currently does not work, because the operator only checks if the k8s secret containing the client secret exists. But it does not verify that the actual client secret in the k8s secret exists (see

edp-keycloak-operator/controllers/keycloakclient/chain/put_client.go

Line 131 in ecb5d43

if k8sErrors.IsNotFound(err) {

).

To Reproduce

1. Deploy Argo CD
2. Deploy Keycloak instance, EDP Operator and connect the Operator to Keycloak
3. Deploy a ClusterKeycloakRealm
4. Deploy the k8s secret above via Argo CD
5. Deploy the KeycloakClient above

What did you expect to see?

I expect the operator to update the secret by adding the client secret key and value to the k8s secret.

What did you see instead? Under which circumstances?

The client secret was not added to the k8s secret.

Kubernetes cluster type:

vanilla

$ kubectl version

v1.27.1

As a user of keycloak operator I want to be able to configure SubComponent of component in a realm

Is your feature request related to a problem? Please describe.
In keycloak the components of type org.keycloak.storage.UserStorageProvider can have sub components of type org.keycloak.storage.ldap.mappers.LDAPStorageMapper

From the keyclaok admin API point of view those subComponent are just almost like any other component, with the exception that the property parentId is not the id of the realm but the id of the component they belong to.

With the current KeycloakRealmComponents resource I am not able to create those LDAPStorageMapper sub component

Describe the solution you'd like
In the keycloak API, the ComponentRepresentation contains a "parentId" field. This field is already present in the adapter but never used.
The problem could maybe be solved by defining a parent property in the KeycloakRealmComponents CRD that reference another KeycloakRealmComponent.
Then when trying to create or update a component with a parent specified, we can lookup up for the ID and pass it in the parentId field.

I imagine something like that as configuration.

kind: KeycloakRealmComponent
metadata:
  name: ad-user-provider
spec:
  name: Active Directory
  providerId: ldap
  providerType: org.keycloak.storage.UserStorageProvider
  realm: onemrva-agents
  config:
    ...
---
`apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealmComponent
metadata:
  name: ad-role-mapper
spec:
  name: Role Mapper
  providerId: role-ldap-mapper
  providerType: org.keycloak.storage.ldap.mappers.LDAPStorageMapper
  realm: onemrva-agents
  parent: ad-user-provider
  config:
    ...

Describe alternatives you've considered
I don't see alternative at current time.
I apologize if I missed another way to achieve this. I look in the source code and don't find any way to do that type of configuration...

Publish 1.18.2 and 1.19.0 to the OperatorHub

Publish both version of operator on OperatorHub

Deletion of CR where keycloak object no longer exists

Describe the bug
A clear and concise description of what the bug is.

Cannot delete CRs (KeycloakRealm, KeycloakClient) if the objects don't exist anymore.

To Reproduce

What did you do?

I was testing database bring up/bring down with FluxCD and I guess the reconciler didn't garbage collect the resources in the right order? Like I think it deleted the database before the Keycloak operator resources were deleted.

This could also happen if someone deletes the realm/client from the keycloak UI, you'd want to be able to recreate the resources from the operator instead of it ending up in a deadlock.

What did you expect to see?

If the Keycloak resources (realm, client, etc.) don't exist and you try and delete, the operator should continue as if the realm/client deletion was successful and proceed with deleting the custom resources.

What did you see instead? Under which circumstances?

When I try and delete the realm and clients manually, the operator spits out these logs. The deletion never happens (even when force deleting them, it just hangs)

297fb6f21276", "name": "my-realm", "error": "failed to delete realm: error during keycloak resource deletion: failed to delete keycloak realm: unable to delete realm: 404 Not Found: Realm not found."}

2024-04-01T20:56:57Z ERROR an error has occurred while handling keycloak client {"controller": "keycloakclient", "controllerGroup": "v1.edp.epam.com", "controllerKind": "KeycloakClient", "KeycloakClient": {"name":"directus-keycloak-client","namespace":"cluster-config"}, "namespace": "cluster-config", "name": "directus-keycloak-client", "reconcileID": "82cb5284-307c-41f7-8e6a-235b16f5b0c2", "name": "directus-keycloak-client", "error": "unable to get keycloak realm: unable to get keycloak realm from ref: failed to get realm: unable to get realm: 404 Not Found: Realm not found."}

I managed to fix the realm issue by recreating it a couple of times in the UI until the operator was happy, but now I'm seeing these errors because the secret containing the client secret has been deleted by now.

1352d40b215f", "name": "directus-keycloak-client", "error": "unable to serve keycloak client: unable to put keycloak client: error during convertCrToDto: unable to get secret, err: unable to get secret from ref: failed to get secret keycloak-client.directus-keycloak-client.secret: Secret \"keycloak-client.directus-keycloak-client.secret\" not found"}

Kubernetes cluster type:

Azure (AKS) - deployed 1.20.0 with helm

Upgrade pull request template

KeycloakRealmUser: UPDATE_PASSWORD required actions is always set regardless of requiredUserActions field

Describe the bug
A clear and concise description of what the bug is.

I'm currently trying to create non-interactive machine users for tests via the operator. To do this, I generate a password, store it in a secret and give KeycloakRealmUser a refernce to the secret, and set the requiredUserActions explicitly to an empty array.

However, all non-interactive logins fail, with Keycloak rejecting the login due to remaining required actions. Upon inspecting the user from the admin console I can see that UPDATE_PASSWORD was added to the required actions. Further testing reveals that UPDATE_PASSWORD is always set in addition to the actions in spec.requiredUserActions. This behaviour seems incredibly bizarre, since the operator pattern would imply that the state of the resource is meant to fully predict/force the state of the external (User) resource. Furthermore, if such a behaviour is desirable for initial creation of human users, then this can be done explicitly by including UPDATE_PASSWORD in the list of requiredUserActions.

Some digging reveals that the behaviour does not stem from the handling of required actions at all, but from setting every Password supplied by the operator as temporary.

edp-keycloak-operator/pkg/client/keycloak/adapter/gocloak_adapter_user.go

Line 277 in 1a935ce

"temporary": true,

To Reproduce

What did you do?

1. Create any KeycloakRealmUser with a password (either via .spec.password or .spec.passwordSecret and with spec.requiredUserActions set to an empty array
2. Check the User's required actions via the admin console or api

What did you expect to see?

Empty User actions on the user with the correct password set.
Being able to login as the user via grant_type=password

What did you see instead? Under which circumstances?

UPDATE_PASSWORD user action is set
login attempts produce "LOGIN_ERROR [...] error=resolve_required_actions [...]" in keycloaks logs.

(Clearing away the Required Action manually makes the user available for non-interactive login even without changing the password)

Kubernetes cluster type:

$ operator-sdk version

not applicable
$ go version

not applicable

$ kubectl version

not applicable

Additional context
I'll provide the relevant one-line PR.

Allow creating Authorization Policies/Permissions for a Client

Is your feature request related to a problem? Please describe.

Currently There is no way to add access to a new client to give them permissions to do token-exchange or impersonation. These settings need to be added to the realm-management client in the Realm.

Describe the solution you'd like

A CR that allows a user to create a Authorization Policy or Permission with a specific target client in a realm or a field in the KeycloakClient CR to add permissions directly.

Describe alternatives you've considered

We are currently using the Keycloak's Operator, but it requires wiping the realm to re-import any changes. Other than that you would need to add the permissions manually which is tedious.

Bump to Go 1.22

Is your feature request related to a problem? Please describe.
Go version 1.20 needs to be updated. Most libraries already require a newer version.

Describe the solution you'd like
Bump Go from 1.20 to the 1.22 version.

Describe alternatives you've considered
Stay on the outdated 1.20 version.

Do not delete Keycloak items on Kubernetes object deletion by default

Is your feature request related to a problem? Please describe.
I just renamed the KeycloakRealm object and accidentally deleted the staging realm.
(renaming + kubectl apply = delete + create?)
There were backups in place, so everything turned out fine, but it's a hell of a trap to fall in.

Describe the solution you'd like
I would like to not have my realms deleted.
Maybe an annotation like delete-keycloak-object-on-kubernetes-deletion with a default of false,
which has to be explicitly set to true to keep the current behaviour. Examples could be updated, so the issue is
directly recognized by users not thinking much (like me).

(Compare "helm.sh/resource-policy": "keep")

Describe alternatives you've considered
Not using this product, because it contains a rather big footgun.
But I would like to use it in production, because it's otherwise exactly what I need.

Additional context
N/A

Enable secret support in KeycloakRealmIdentityProvider resource

Currently, we set clientSecret as plain text.

apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealmIdentityProvider
metadata:
  name: keycloakrealmidentityprovider-sample
spec:
  realmRef:
    kind: KeycloakRealm
    name: realm
  alias: instagram
  authenticateByDefault: false
  enabled: true
  firstBrokerLoginFlowAlias: "first broker login"
  providerId: "instagram"
  config:
    clientId: "foo"
    clientSecret: "some-secret"
    hideOnLoginPage: "true"
    syncMode: "IMPORT"
    useJwksUrl: "true"

We need to have the possibility to set clientSecret from the Kubernetes secret.

Implement User Attributes Reconciliation in Keycloak-Operator

The keycloak-operator needs enhancement to support the reconciliation of user attributes. This feature aims to ensure that user data within Keycloak remains consistent and up-to-date, specifically focusing on the following attributes:
- FirstName
- SecondName
- Email
- Email-Verified (optional)

Acceptance Criteria:

1. Attribute Reconciliation: The keycloak-operator must be able to reconcile user attributes including FirstName, SecondName, and Email.
2. Optional Email-Verified Field: The operator should support the reconciliation of the Email-Verified field, but this should be optional and configurable.
3. Consistency Check: Ensure that after reconciliation, the user attributes in Keycloak match the source of truth.
4. Automated Tests: Implement automated tests that verify the correct reconciliation of user attributes.
5. Documentation: Update the keycloak-operator documentation to include information on how to use and configure the new feature.

Add integration tests for the keycloak operator

Add integration tests for every keycloak controller.
Every controller test should:
- test create/update/delete for custom resource
- test main logic for custom resource
- cover at least 80% of controller logic
- tests should be logically structured, well readable, and not connected with other controller tests

Remove the old unit tests for the controllers.

Enable review for pull requests (gh-actions)

Acceptance Criteria:

• analyze and migrate flow from Tekton review to gh-actions for keycloak-operator;

Implement cache in github workflow

Implement cache in github workflow

no guidance as for 'secret' format in keycloak CR

So i have a Keycloak instance:

apiVersion: v1.edp.epam.com/v1
kind: Keycloak
metadata:
  name: keycloak
  namespace: sso
spec:
  secret: keycloak-secret
  url: 'https://keycloak-sso.apps.okd.lab.arrowglance.io'
  adminType: user

But i cannot find any guidance as to what the 'secret' should look like. Can you provide some?

Thanks!
-Nick

Boolean parameters with value `false` are silently ignored

Some parameters contain default value even if set in the CRD to the different value. I noticed this behaviour in the KeycloakClient resource, but other resources may be affected as well.
It looks for me that boolean parameters with value false are not applied. If there is no default value, then probably it is silently set to false which is desired state. But if default value is true, then these parameters have wrong value.

To Reproduce
Setup postgresql and keycloak, e.g. via bitnami/postgresql and codecentric/keycloakx charts
Deploy operator like described in the readme:

helm repo add epamedp https://epam.github.io/edp-helm-charts/stable
helm repo update
helm install keycloak-operator epamedp/keycloak-operator --version 1.20.0 --namespace keycloak --set name=keycloak-operator

Create keycloak-admin secret and Keycloak CRD:

apiVersion: v1.edp.epam.com/v1
kind: Keycloak
metadata:
  namespace: keycloak
  name: keycloak
spec:
  secret: keycloak-admin
  url: http://keycloak-keycloakx-http

Create KeycloakRealm CRD:

apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealm
metadata:
  namespace: keycloak
  name: test-realm
spec:
  realmName: test-realm
  keycloakRef:
    name: keycloak
    kind: Keycloak

Create KeycloakClient CRD:

apiVersion: v1.edp.epam.com/v1
kind: KeycloakClient
metadata:
  namespace: keycloak
  name: backend-client
spec:
  advancedProtocolMappers: false
  attributes:
    post.logout.redirect.uris: ""
  authorizationServicesEnabled: false
  clientAuthenticatorType: client-secret
  clientId: backend-client
  consentRequired: false
  enabled: false
  fullScopeAllowed: false
  realmRef:
    kind: KeycloakRealm
    name: test-realm
  secret: backend-client-secret
  serviceAccount:
    clientRoles:
    - clientId: realm-management
      roles:
      - manage-users
    enabled: true
    realmRoles: null
  standardFlowEnabled: false

Check deployed resource:
kubectl describe KeycloakClient backend-client -n keycloak

Name:         backend-client
Namespace:    keycloak
Labels:       <none>
Annotations:  <none>
API Version:  v1.edp.epam.com/v1
Kind:         KeycloakClient
Metadata:
  Creation Timestamp:  2024-05-10T10:35:06Z
  Finalizers:
    keycloak.client.operator.finalizer.name
  Generation:  3
  Owner References:
    API Version:           v1.edp.epam.com/v1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  KeycloakRealm
    Name:                  test-realm
    UID:                   ee1f909a-de79-4b1c-a4da-0aef722b3d6e
  Resource Version:        63205
  UID:                     19c1f7a2-6fda-492a-b977-7fd5445893d7
Spec:
  Attributes:
    post.logout.redirect.uris:
  Client Authenticator Type:    client-secret
  Client Id:                    backend-client
  Enabled:                      true
  Full Scope Allowed:           true
  Realm Ref:
    Kind:  KeycloakRealm
    Name:  test-realm
  Secret:  $backend-client-secret:clientSecret
  Service Account:
    Client Roles:
      Client Id:  realm-management
      Roles:
        manage-users
    Enabled:              true
    Realm Roles:          <nil>
  Standard Flow Enabled:  true
  Web Origins:

Status:
  Client Id:  77287e6b-1af9-40e1-a490-54bab0e7e0c7
  Value:      OK
Events:       <none>

The values for spec.enabled, spec.fullScopeAllowed and spec.standardFlowEnabled are all set to default value true instead of defined false. Note that other boolean parameters which do not have default value (spec.advancedProtocolMappers, spec.authorizationServicesEnabled and spec.consentRequired in this case) do not appear in the resource.

Kubernetes cluster type:
minikube v1.33.0 on Microsoft Windows 10 with docker driver
Kubernetes v1.30.0
$ kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0

Additional context
Chart version 1.20.0
I wanted to test latest snapshot version, but for some reason snapshot repo (https://epam.github.io/edp-helm-charts/snapshot) does not contain any charts:

helm repo add epamedp-snapshot https://epam.github.io/edp-helm-charts/snapshot

"epamedp-snapshot" has been added to your repositories

helm repo update

Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "codecentric" chart repository
...Successfully got an update from the "epamedp" chart repository
...Successfully got an update from the "epamedp-snapshot" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete. Happy Helming!

helm search repo epamedp-snapshot

No results found

Error if secret created and owned by keycloakclient is deleted before it

Describe the bug
If during deletion of keycloakclient's namespace secret owned by resource is deleted before resource I get an unable to serve keycloak client error and resource is never deleted

To Reproduce

What did you do?

Tried deleting keycloakclient's namespace

What did you expect to see?

Namespace deleted

What did you see instead? Under which circumstances?

Deletion hanging becuase keycloakclient's finalizer is not removed

Kubernetes cluster type:

AKS

$ operator-sdk version

$ go version

$ kubectl version

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Update e2e test for new kaniko approach

Enhance observability and manageability of Keycloak cluster resources

Is your feature request related to a problem? Please describe.
Currently, viewing essential information directly from the command line for ClusterKeycloak and ClusterKeycloakRealm resources requires describing each resource individually, which can be cumbersome.

Describe the solution you'd like
Enhance the observability and manageability of Keycloak cluster resources by adding additional print columns to the ClusterKeycloak and ClusterKeycloakRealm resources. This will allow users to view essential information directly from the command line without needing to describe each resource individually. The goal is to incorporate all spec values into the print columns for these resources.

Acceptance Criteria:

1. For both ClusterKeycloak and ClusterKeycloakRealm resources, all spec values are added to the print columns.
2. The implementation should ensure that the added print columns display relevant information clearly and concisely.
3. The feature must be tested to verify that the print columns correctly display the specified spec values for both resources.
4. Documentation must be updated to reflect the changes made to the print columns, including examples of the output users can expect.

Implementation Plan:

1. Review the current spec values for ClusterKeycloak and ClusterKeycloakRealm resources.
2. Determine the most relevant information to be displayed in the print columns for each resource.
3. Implement the changes to add the selected spec values to the print columns for both resources.
4. Conduct thorough testing to ensure the print columns display as expected.
5. Update the documentation to include the new print column information and provide examples.

Additional context
Add any other context or screenshots about the feature request here.

Support for composite client role

Is your feature request related to a problem? Please describe.
At the moment when I attempt to create a role using KeycloakRealmRoleBatch or KeycloakRealmRole I'm not able to use client roles (or I see no way how can I use them). Sample KC role config looks like:

        "id": "5bd3bcd6-d87d-48fb-88d5-18715e1165eb",
        "name": "wcq-api-client-mgmt",
        "description": "",
        "composite": true,
        "composites": {
          "client": {
            "realm-management": [
              "query-clients",
              "manage-users",
              "view-realm",
              "manage-clients"
            ]
          }
        },
        "clientRole": false,
        "containerId": "812b10c8-8e7d-4806-9eb2-675c565d7243",
        "attributes": {}
      },

This is the prerequisite for fine grained permission handling that can allow client to query/rotate its own secret.

Describe the solution you'd like
I would like to have both: real roles and client roles to be used as a composite

Describe alternatives you've considered
The only alternative is to do it manually in KC UI.

Additional context

Add Print Columns for Keycloak Cluster Resources

Description:
The goal of this task is to enhance the observability and manageability of Keycloak cluster resources by adding additional print columns to the ClusterKeycloak and ClusterKeycloakRealm resources. This will allow users to view essential information directly from the command line without needing to describe each resource individually. Given that the list of spec values is manageable, we aim to incorporate all spec values into the print columns for these resources.

Acceptance Criteria:

1. For both ClusterKeycloak and ClusterKeycloakRealm resources, all spec values are added to the print columns.
2. The implementation should ensure that the added print columns display relevant information clearly and concisely.
3. The feature must be tested to verify that the print columns correctly display the specified spec values for both resources.
4. Documentation must be updated to reflect the changes made to the print columns, including examples of the output users can expect.

Implementation Plan:

1. Review the current spec values for ClusterKeycloak and ClusterKeycloakRealm resources.
2. Determine the most relevant information to be displayed in the print columns for each resource.
3. Implement the changes to add the selected spec values to the print columns for both resources.
4. Conduct thorough testing to ensure the print columns display as expected.
5. Update the documentation to include the new print column information and provide examples.

Labels: 'CodeMie'

Allow configuring a realm/keycloak in a different namespace

Is your feature request related to a problem? Please describe.
At work we are currently building out an internal developer platform that will use Keycloak as IdP for all in-cluster applications. Due to security and coupling concerns we will need to separate out the applications from different stream teams into separate namespaces, while the keycloak realm will be configured in a platform-team-owned namespace. Each application should be able to get an OIDC client with individual clientId and clientSecret by deploying a KeycloakClient CR in its own namespace.

Currently the Operator does not support this, since it only searches the namespace of the custom resource for a matching realm resource

edp-keycloak-operator/controllers/helper/controller_helper.go

Line 245 in 8c3936a

Namespace: object.GetNamespace(),

edp-keycloak-operator/controllers/keycloakclient/client_realm_owner.go

Line 47 in 8c3936a

listOpts := client.ListOptions{Namespace: c.parent.Namespace}

edp-keycloak-operator/controllers/keycloakclient/client_realm_owner.go

Line 59 in 8c3936a

if err := c.client.List(context.Background(), &realmList, &client.ListOptions{Namespace: c.Namespace}); err != nil {

Describe the solution you'd like
The best solution would be to add an optional extra Field to the CRs (e.g. targetRealmNamespace/keycloakOwnerNamespace) which if present will make the operator search for a Realm/Keycloak in that namespace rather than in the same namespace as the CR. Without the field present, the behaviour would stay the exact same as now, conferring perfect forward compatibility.

If api stability dictates that the CRs cannot be extended with optional Fields at all, then allowing targetRealm/keycloakOwner to be specified not just by name but optionally in the form of <namespace>/<name> or <namespace>:<name> to cause the same behaviour change would allow for this usecase as well

Describe alternatives you've considered
Our current prototype uses the Keycloak Realm Operator (i.e. the fork of the old official Operator) which can find Realms/Keycloak Instances in any namespace by label, if its service account has sufficient permissions. Unfortunately the realm operator can only add/delete realms and is therefore incompatible with a GitOps Workflow using the Operator Pattern.

Added the edp-keycloak-operator-managed realm into the realm operator as external realm is an option, however at that point we would be using 3 different operators (Quarkus, Realm, and EDP) per cluster to deploy and manage a single Keycloak deployment each which is clearly undesirable from both operations and security perspectives.

Additional context
If we can decide which of the two proposed solutions should be implemented, I'd be happy to contribute a PR to that effect

Release Activities for Version 1.21.0

Describe the task
As part of our development cycle, we are preparing for the release of version 1.21.0 of the edp-keycloak-operator. This release involves several key activities to ensure a smooth rollout and availability of the release artifacts.

Release Artifacts:

• Docker image published to DockerHub.
• Release tag created in GitHub.
• Updated Helm chart for the release.
• Comprehensive changelog detailing the changes in this version.
• Development version in the master branch updated post-release.

labels: 'CodeMie'

Acceptance Criteria:

• Docker image for version 1.21.0 is available on DockerHub.
• GitHub repository tagged with release version 1.21.0.
• Helm chart for version 1.21.0 is released and available.
• Changelog for version 1.21.0 is created and included in the release notes.
• The master branch's development version is updated to reflect the commencement of the next development cycle.

Implementation Plan:

1. Finalize all features and fixes to be included in version 1.21.0 and merge them into the master branch.
2. Build the Docker image for version 1.21.0 and publish it to DockerHub.
3. Create a release tag in GitHub for version 1.21.0.
4. Update the Helm chart to reflect the new version and ensure it is ready for release.
5. Compile a comprehensive changelog based on the commits and pull requests merged since the last release.
6. Post-release, update the development version in the master branch to signify the start of the next development cycle.

Additional context
This release marks an important milestone in the edp-keycloak-operator project's lifecycle, introducing new features, improvements, and bug fixes. It's crucial that all release activities are executed meticulously to ensure the availability and stability of the release artifacts for our users.

Ability to Configure Realm Token Settings

Is your feature request related to a problem? Please describe.
The KeycloakRealm resource is missing the ability to configure token settings e.g. accessTokenLifespan

Describe the solution you'd like
Add the accessToken* and refreshToken* fields to the KeycloakRealm resource

Describe alternatives you've considered
The only alternative is the keycloak-operator from Keycloak that allows this configuration on one import only, or manually via the console.

Deprecate SSORealm functional

We have filed the KeycloakRealm CR (sso..) to set up the parent realm and identity provider.
A big part of this configuration is hardcoded, not configurable, and has bugs.

apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealm
metadata:
  name: keycloakrealm-sample
spec:
  realmName: realm-sample
  keycloakRef:
    name: keycloak-sample
    kind: Keycloak
  ssoRealmName: master
  ssoRealmEnabled: false
  ssoAutoRedirectEnabled: false

This functionality can be created by separate CRs - KeycloakRealm + KeycloakRealmIdentityProvider and the approach is more flexible.
Remove deprecated sso configuration from the KeycloakRealm CR.

Migrate from gerrit to github pipelines

Missing `bearerOnly` in CRD `KeycloakClient` / `keycloakclients.v1.edp.epam.com/v1`

Is your feature request related to a problem? Please describe.
Hello,

I want to specify a keycloak client with the parameter bearerOnly: true.
However, this key currently does not exist for CRD KeycloakClient and is ignored and set to false by default.

Describe the solution you'd like
I would like to be able to provide bearerOnly, or maybe provide an
entire dictionary of extra key value pairs which should be sent with the POST or PUT to keycloak.

Describe alternatives you've considered
Alternatives are doing it manually or write some extra script to update the value to the desired state.

Additional context
Keycloak has many more possible keys defined in their
documentation.
Due to the amount of keys and possible future changes, being able to provide an object with arbitrary key value pairs might be a viable solution. Having only bearerOnly would be fine for my current personal use case.

Enable images to be pulled from private repository

Is your feature request related to a problem? Please describe.
imagePullSecrets need to be provided in deployment to allow image to be pull from a private repository.
Proposed PR is provided in #51

Describe the solution you'd like
add an optional imagePullSecrets value to the chart to allow pull secrets to be optionally provided.

Describe alternatives you've considered
Provide pull secrets via a policy annotation on the cluster to override standard deployment. But this relies on running a policy server such as Kyverno. Better solution is to provide the functionality in the chart repository. This is a more standard approach in typical chart construction.

Additional context
Add any other context or screenshots about the feature request here.

Allow multiple redirect URIs

Is your feature request related to a problem? Please describe.
For our use case, applications may be reachable with multiple, equally acceptable URLs. Keycloak supports this out-of-the-box. The KeycloakClient.Spec does not support setting multiple URLs.

Describe the solution you'd like
The spec should have an additional field redirectURIs as []string, defaulting to the singleton with the webUrl (e.g. here?
https://github.com/epam/edp-keycloak-operator/blob/master/pkg/client/keycloak/adapter/gocloak_adapter.go#L578 )

Describe alternatives you've considered
/

Additional context
/

Upgrade Go to 1.20

Setting user password from secret

Hi,

Is there a good way to define realm's users' password via kubernetes secrets?

Release 1.20.0

Acceptance Criteria:

• keycloak-operator 1.20.0 released;

chore(deps): Bump golang.org/x/net from 0.8.0 to 0.17.0

Update dependencies

Enable secret support in KeycloakRealmComponent resource

Is your feature request related to a problem? Please describe.
Unable to manage LDAP bind credentials in kubernetes secrets.

apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealmComponent
metadata:
  name: ldap
spec:
  realm: testrealm
  name: ldap
  providerId: ldap
  providerType: org.keycloak.storage.UserStorageProvider
  config:
    bindCredential:
      - passwordMustBeInCleartextHere
    bindDn:
      - uid=serviceaccount,cn=users,dc=example,dc=com
    connectionUrl:
      - ldaps://dc.intranet.com
    vendor:
      - ad
    ...

Describe the solution you'd like
Being able to reference kubernetes secret values in KeycloakRealmComponent config. Like in #21 and #20

Describe alternatives you've considered
Having a separate secretConfig property under spec.

Operator not working on okd 4.14 because of rbac issues

i wasn't able to install the operator successfully on openshift, the operator was crashlooping because of permission errors for clusterkeycloaks and clusterkeycloakrealms api's

i added the following crb's to fix it

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: edp-keycloak-operator-controller-manager-clusterkeycloakrealms
subjects:
  - kind: ServiceAccount
    name: edp-keycloak-operator-controller-manager
    namespace: openshift-operators
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterkeycloakrealms.v1.edp.epam.com-v1alpha1-admin
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: edp-keycloak-operator-controller-manager-clusterkeycloaks
subjects:
  - kind: ServiceAccount
    name: edp-keycloak-operator-controller-manager
    namespace: openshift-operators
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterkeycloaks.v1.edp.epam.com-v1alpha1-admin

Add Scopes to Keycloak Client Authorizations

Is your feature request related to a problem? Please describe.
When using the new Authorization field for KeycloakClient (Thanks for adding that feature), if the permission is scoped based, then the scope needs to exist in the Authorization Scopes for the Client.

Describe the solution you'd like
Add a Scopes field to the KeycloakClient Authorization spec

Describe alternatives you've considered
Manually adding the authorization scope e.g "token-exchange" allows the KeycloakClient to reconcile properly

Additional context
I am working on a branch for this now, but I'm currently stuck at the mock pieces because make mocks is hitting a nil pointer. If you could possibly point into the right direction of which piece I could have missed, I would love to get this PR in for your team.

Release 1.18.0

Acceptance Criteria:

• keycloak-operator 1.18.0 released;

Missing fields in CRD KeycloakClient / keycloakclients.v1.edp.epam.com/v1

Is your feature request related to a problem? Please describe.
Hello,

First off, thank you for your amazing work on this Operator.

We are currently evaluating the usage of the EDP Keycloak Operator in our GitOps workflows. For this, we are examining the CRDs and try to migrate our existing realm.json export to separate K8S manifests.

For the most part, this seems doable, but our front-end login is not compatible with the options the EDP Keycloak Operator currently offers. We need to explicitly set the WebOrigins and implicitFlowEnabled fields.

Describe the solution you'd like
We'd like to have the option to specify more fields in the KeycloakClient spec.

Describe alternatives you've considered
We could not export this client and keep it in the existing realm.json.

Additional context
We've already forked this repository and started working on defining and binding the missing fields. This can be done in a backwards compatible manner, since the WebOrigins was already set with the existing WebUrl field. The implicitFlowEnabled can be defaulted to false.

We've been struggling a bit with getting the tests to work, so I'll open up a PR where I'll gladly take up your advice how to test it properly