create helm chart for keycloak-operator by KyriosGN0 · Pull Request #42079 · keycloak/keycloak

KyriosGN0 · 2025-08-23T11:24:23Z

This PR creates a Helm Chart that deploys the Keycloak operator and allows to also install the CRD via a flag
part of #37636

Im not that knowledgeable about GitHub Actions, but i think that doing something similar to the prometheus-community helm chart
or the grafana helm chart is a good starting point, for release i haven't found the github action for this this repo, but maybe we can do the same mechanism and update the CRD in this folder?

vmuzikar

Thank you for the contribution.

I'm adding hold label for now as we need to discuss internally first if a Helm Chart for the Operator is something that we'd like to include in the project.

Just a few points if we decided to bring this further.

~~This PR is missing a linked issue as per our contributing guidelines.~~ Never mind, I missed it in the desc.
We'd need to avoid having to maintain the Helm Chart resources manually. It'd be good to reuse as much existing/generated resources (Roles, Deployment, Service, Service Account, etc.) as possible to have single source of truth.
We'd also need some tests for this, similarly to our OLM tests.
Docs update would be also needed.
As a follow-up, we'd need to update the release process to include the Helm Chart in https://github.com/keycloak/keycloak-k8s-resources.

KyriosGN0 · 2025-08-25T20:37:48Z

Thank you for the contribution.

I'm adding hold label for now as we need to discuss internally first if a Helm Chart for the Operator is something that we'd like to include in the project.

Just a few points if we decided to bring this further.

~~This PR is missing a linked issue as per our contributing guidelines.~~ Never mind, I missed it in the desc.

We'd need to avoid having to maintain the Helm Chart resources manually. It'd be good to reuse as much existing/generated resources (Roles, Deployment, Service, Service Account, etc.) as possible to have single source of truth.

We'd also need some tests for this, similarly to our OLM tests.

Docs update would be also needed.

As a follow-up, we'd need to update the release process to include the Helm Chart in keycloak/keycloak-k8s-resources.

Hey, Thanks for the review, of course i will wait until the decision is made, regarding your points

We'd need to avoid having to maintain the Helm Chart resources manually. It'd be good to reuse as much existing/generated resources (Roles, Deployment, Service, Service Account, etc.) as possible to have single source of truth.

Do you mean you wish to reuse the k8s manifests from the repo?
if so this is mostly what i have done, i added extra knobs for stuff that is usually available in helm charts (resources, affinity selectors)

We'd also need some tests for this.

Of course i agree, i offered the grafana/prometheus repositories as inspiration, i am not very knowledgeable about GitHub actions, so im open to any ideas from the community.

Docs update would be also needed.

I agree, if a decision to proceed with this PR will be reached i will also write docs about

Again Thanks for the review!

Lappihuan · 2025-08-26T05:33:15Z

@vmuzikar
the new chart can be used to render the static resources with the same default values as they are now in a pipeline so the chart with the default values becomes the "single source of truth, with a command like this:

helm template myapp ./charts/myapp \
  --namespace myns \
  --values charts/myapp/values.yaml \
  > deploy/static/all.yaml

nissessenap

First of all, thanks for your work on this @KyriosGN0 .

A few minor comments about the helm chart.

Around release management of helm charts you can take a look here: https://github.com/grafana/grafana-operator/blob/56279f56f8b0a6796b9383cb193748b427eb78c2/.github/workflows/release.yaml#L15-L51

In the grafana-operator we are supporting both OCI and index.yaml, but initially we only supported OCI. My suggested would be to only support OCI packaging for the helm chart.

Here you can also see how we read data from existing yaml files and put into our helm chart. This way we automatically update the CRDs and roles.
https://github.com/grafana/grafana-operator/blob/56279f56f8b0a6796b9383cb193748b427eb78c2/Makefile#L65-L82

Sadly, I see the keycloak operator is built on Java so we can't just copy similar logic since it's not built on kubebuilder.

I got too much todo at work right now to commit any GHA stuff.

vmuzikar · 2025-09-08T16:13:11Z

Please see #37636 (comment)

KyriosGN0 · 2026-06-12T08:01:01Z

@vmuzikar @shawkins was there any decision made on which/how to create the helm chart?
im more then happy to continue contributing this PR if that decision was made

shawkins · 2026-06-12T11:13:10Z

@vmuzikar @shawkins was there any decision made on which/how to create the helm chart? im more then happy to continue contributing this PR if that decision was made

Removed the hold label. The review of the community survey showed strong interest in helm charts - but mostly for Keycloak itself.

We see an intermediate value in offering a helm chart for the operator, but would like to ensure that the implementation requires minimal syncing when changes are made to the operator - #37636 (comment)

For example #46980 was refined to directly use our generated yaml files rather than having modified copies just for kustomize overlays.

Do you mean you wish to reuse the k8s manifests from the repo?
if so this is mostly what i have done, i added extra knobs for stuff that is usually available in helm charts (resources, affinity selectors)

What we're looking for is reuse, rather than mostly copies of the artifacts - that will be difficult to maintain.

You don't have to use the keycloak-k8s-resources repo if the helm chart generation logic lives in the keycloak repo. You would only use the keycloak-k8s-resources if this ends up being some kind of external effort.

vmuzikar · 2026-06-12T11:16:07Z

@KyriosGN0 After some internal discussion, we'd like to go forward with the Helm Chart for the Operator. However, we need to take a different approach than this PR currently is – as already outlined by @shawkins in the comment above.

We'd suggest to evaluate the possibility for Helm Chart generation via JOSDK: https://javaoperatorsdk.io/docs/documentation/operations/helm-chart/

vmuzikar · 2026-06-12T11:21:36Z

You don't have to use the keycloak-k8s-resources repo

Yes but we'll need to find the correct distribution channel for the Helm Chart, and update the release process for it. But that could be a follow-up.

KyriosGN0 · 2026-06-12T15:49:10Z

hey @vmuzikar @shawkins i found quarkus-helm plugin which integrated nicely with the operator sdk
but there a few question which i would want your input before continuing

Should chart version track the operator version forever?

Right now Chart.yaml's version defaults to ${project.version} (same as the operator) and there's no appVersion. That works fine for "one chart release per operator release" — which is the simplest model and matches what most operator charts do.
The alternative is to bump chart version independently of appVersion so a chart-only fix (e.g. a values mapping correction, a new quarkus.helm.values description) can ship without an operator release. That's the convention on ArtifactHub-listed charts. quarkus-helm supports it via quarkus.helm.version=... (override) plus quarkus.helm.app-version=... (separate).

Where should the chart be published?

This PR generates a chart and a .tar.gz in CI, but doesn't push them anywhere. The end-user helm install snippet in docs/guides/operator/installation.adoc currently references a TBD , I saw some issues around using OCI registry in qaurkus-helm, so a regular http repo can also work

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (4)

docs/guides/operator/installation.adoc:299

This command contradicts the instruction to keep CRDs: deleting the cluster-wide kustomization deletes its four CRDs and can garbage-collect all corresponding custom resources. The path also differs from the valid cluster-wide kustomization used at line 236. Delete only the operator workload/RBAC manifest, not the kustomization that includes CRDs.

kubectl delete -k 'github.com/keycloak/keycloak-k8s-resources/kubernetes/cluster-wide?ref={version}'

docs/guides/operator/installation.adoc:310

helm.sh/resource-policy: keep controls deletion; it does not add Helm's release ownership metadata. Moreover, the release was already installed in the previous step, so it cannot be “re-installed” under the same name. Document an ownership-aware upgrade (for example, helm upgrade --take-ownership on a supported Helm version) or keep these CRDs managed out-of-band.

After the chart is installed and the operator is healthy, you can leave CRD management as-is (out-of-band) or transfer ownership to the chart on the next upgrade by setting the `helm.sh/resource-policy: keep` annotation on the existing CRDs and re-installing with `crds.enabled=true`.

docs/guides/operator/installation.adoc:289

This lookup is also unversioned, so readers of an older installation guide would see values for the latest chart instead of the release documented on the page. Pin the OCI chart to {version}.

Run `helm show values oci://quay.io/keycloak/keycloak-operator-helm` for the full list.

docs/guides/operator/installation.adoc:307

The migration install is unversioned as well, so following an archived guide can migrate directly to a newer operator release. Pin this command to the documented release.

helm install keycloak-operator oci://quay.io/keycloak/keycloak-operator-helm \
  --namespace keycloak --set crds.enabled=false

+helm install keycloak-operator oci://quay.io/keycloak/keycloak-operator-helm \
+  --namespace keycloak --create-namespace


Signed-off-by: AvivGuiser <avivguiser@gmail.com>

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

docs/guides/operator/installation.adoc:301

The migration leaves the namespaced Role/RoleBinding and the controller-generated ClusterRoles/ClusterRoleBindings in place. Those resources are also part of the chart, so helm install will stop with an invalid ownership error when it encounters them. Delete all operator RBAC resources by their established app.kubernetes.io/name label while preserving the CRDs.

kubectl delete deployment,service,serviceaccount keycloak-operator -n keycloak
kubectl delete clusterrole keycloak-operator-clusterrole
kubectl delete clusterrolebinding keycloak-operator-clusterrole-binding

docs/guides/operator/installation.adoc:312

helm.sh/resource-policy: keep controls deletion; it does not add Helm's ownership metadata. Also, the release already exists at this point, so re-installing the same name fails. Document an actual adoption command such as helm upgrade ... --take-ownership (with its Helm version requirement), or the equivalent ownership annotations and label.

After the chart is installed and the operator is healthy, you can leave CRD management as-is (out-of-band) or transfer ownership to the chart on the next upgrade by setting the `helm.sh/resource-policy: keep` annotation on the existing CRDs and re-installing with `crds.enabled=true`.

.github/workflows/operator-ci.yml:172

With pipefail, these checks can fail with status 141 even when the resource exists: grep -q exits on its first match while echo is still writing the large CRD-filled render and receives SIGPIPE. Feed the captured output directly to grep so valid renders do not fail CI.

          echo "$out" | grep -qE '^kind: Deployment$'
          # Cluster-wide install binds the controllers via ClusterRoleBinding.
          echo "$out" | grep -qE '^kind: ClusterRoleBinding$'

.github/workflows/operator-ci.yml:187

Under pipefail, an unexpectedly rendered CRD can make echo receive SIGPIPE after grep -q finds the first match, causing the pipeline to evaluate false and bypass this failure branch. Use a here-string so this negative test reliably detects CRDs.

          if echo "$out" | grep -qE '^kind: "?CustomResourceDefinition"?$'; then
            echo "expected no CRDs with crds.enabled=false"; exit 1
          fi

operator/README.md:40

This says only CRDs are post-processed, but the script also rewrites every ServiceAccount subject namespace in generated RoleBindings and ClusterRoleBindings. Mention that transformation so maintainers know the generated chart is not otherwise purely declarative.

Helm chart configuration lives in `operator/src/main/resources/application.properties` under the `quarkus.helm.*` keys. CRDs are post-processed by `operator/scripts/post-process-helm-chart.sh` (wrapping them in a `{{ if .Values.crds.enabled }}` guard) — the rest is purely declarative.

keycloak-github-bot

Unreported flaky test detected, please review

keycloak-github-bot · 2026-07-25T09:59:29Z

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.forms.MultipleTabsLoginTest#multipleTabsParallelLoginTestWithAuthSessionExpiredAndRegisterClick

Keycloak CI - Forms IT (firefox)

org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
...

Report flaky test

shawkins · 2026-07-30T15:04:33Z

@KyriosGN0 thank you for the additional updates. Let me look things over again as I think this is close to being committed. We'll need some kind of release note, but those can be done as a follow-up after the release process has been updated.

shawkins · 2026-07-30T22:20:21Z

@KyriosGN0 I think everything looks good - but wanted to check will even oci installs see the target/helm/kubernetes/keycloak-operator/templates/NOTES.txt? They seem much focused on the quarkus development scenario.

KyriosGN0 · 2026-07-31T16:32:59Z

Hey @shawkins from the docs i think that OCI install will see the NOTES.txt

shawkins

Hey @shawkins from the docs i think that OCI install will see the NOTES.txt

Ok, we'll capture a follow-up for improving that as well.

Thank you @KyriosGN0, approving this PR as it should be good for initial experimental state.

@vmuzikar @michalvavrik please given it a look.

michalvavrik

LGTM

michalvavrik · 2026-08-09T15:10:08Z

+            /^kind:/{k=$2} /^  name:/{n=$2} /^  namespace:/{ns=$2}
+            /^---/{if(k&&n)print k"/"ns"/"n; k=n=ns=""}
+            END{if(k&&n)print k"/"ns"/"n}' | sort | uniq -d)
+          if [ -n "$dupes" ]; then echo "duplicate resources rendered:"; echo "$dupes"; exit 1; fi


quarkiverse/quarkus-operator-sdk#1393 is already released https://github.com/quarkiverse/quarkus-operator-sdk/releases/tag/7.8.0, can you drop it then?

KyriosGN0 · 2026-08-09T15:14:58Z

@michalvavrik i planned to do it once this is merged, do you want it done as part of this PR ?

michalvavrik · 2026-08-09T15:16:49Z

@michalvavrik i planned to do it once this is merged, do you want it done as part of this PR ?

I don't mind either way. This PR LGTM, whatever works for others. I don't see a reason not to do it now, but you may easily know something I don't. It is maintainers call to merge this.

KyriosGN0 · 2026-08-10T06:35:57Z

Hey @vmuzikar, could you please weigh in on #42079 (comment) ?

michalvavrik · 2026-08-10T15:29:19Z

Hey @vmuzikar, could you please weigh in on #42079 (comment) ?

I am at least twice as heavy as @vmuzikar , but alright 🤷‍♂️

vmuzikar · 2026-08-10T17:34:36Z

quarkiverse/quarkus-operator-sdk#1393 is already released https://github.com/quarkiverse/quarkus-operator-sdk/releases/tag/7.8.0, can you drop it then?

We're not using QOSDK 7.8.0 just yet, we need to wait for another Quarkus Platform release when it adopts it.

vmuzikar

Thank you! Changes look good but we're missing release notes.

vmuzikar · 2026-08-10T17:46:40Z

@shawkins Do we have an issue already for updating the release process?

shawkins · 2026-08-10T18:13:22Z

Thank you! Changes look good but we're missing release notes.

I think that is fine to do in a follow-up once the release process changes are hashed out.

@shawkins Do we have an issue already for updating the release process?

Created: keycloak-rel/keycloak-rel#196

We'll also have a follow-up on the NOTES.txt

vmuzikar

Ok, let's get this merged already.

KyriosGN0 marked this pull request as ready for review August 23, 2025 11:30

KyriosGN0 requested review from a team as code owners August 23, 2025 11:31

keycloak-github-bot Bot added the team/cloud-native label Aug 23, 2025

KyriosGN0 mentioned this pull request Aug 23, 2025

Helm Chart for keycloak operator #37636

Closed

DrFaust92 reviewed Aug 23, 2025

View reviewed changes

Comment thread operator/helm/keycloak-operator/templates/service.yaml Outdated

DrFaust92 reviewed Aug 23, 2025

View reviewed changes

Comment thread operator/helm/keycloak-operator/templates/deployment.yaml Outdated

shawkins assigned shawkins and vmuzikar Aug 25, 2025

shawkins requested review from shawkins and vmuzikar August 25, 2025 14:29

vmuzikar requested changes Aug 25, 2025

View reviewed changes

vmuzikar linked an issue Aug 25, 2025 that may be closed by this pull request

Helm Chart for keycloak operator #37636

Closed

vmuzikar added the status/hold PR should not be merged. On hold for later. label Aug 25, 2025

nissessenap reviewed Aug 26, 2025

View reviewed changes

Comment thread operator/helm/keycloak-operator/templates/openshift-clusterrole.yaml Outdated

Comment thread operator/helm/keycloak-operator/templates/service.yaml Outdated

jglick reviewed Nov 13, 2025

View reviewed changes

Comment thread operator/helm/keycloak-operator/values.yaml Outdated

P4sca1 suggested changes Dec 4, 2025

View reviewed changes

Comment thread operator/helm/keycloak-operator/values.yaml Outdated

Comment thread operator/helm/keycloak-operator/templates/openshift-clusterrole.yaml Outdated

shawkins removed the status/hold PR should not be merged. On hold for later. label Jun 12, 2026

KyriosGN0 force-pushed the helm branch 2 times, most recently from d072e54 to 39b89db Compare June 12, 2026 16:14

KyriosGN0 requested a review from vmuzikar June 12, 2026 16:21

keycloak-github-bot Bot added the flaky-test label Jun 12, 2026

Copilot started reviewing on behalf of KyriosGN0 July 25, 2026 08:55 View session

Copilot AI reviewed Jul 25, 2026

View reviewed changes

Comment thread docs/guides/operator/installation.adoc

Comment on lines +270 to +271

helm install keycloak-operator oci://quay.io/keycloak/keycloak-operator-helm \

--namespace keycloak --create-namespace

update docs

8670a17

Signed-off-by: AvivGuiser <avivguiser@gmail.com>

Copilot AI review requested due to automatic review settings July 25, 2026 08:59

Copilot started reviewing on behalf of KyriosGN0 July 25, 2026 08:59 View session

Copilot AI reviewed Jul 25, 2026

View reviewed changes

keycloak-github-bot Bot reviewed Jul 25, 2026

View reviewed changes

shawkins self-requested a review July 29, 2026 20:47

shawkins approved these changes Aug 3, 2026

View reviewed changes

michalvavrik reviewed Aug 9, 2026

View reviewed changes

vmuzikar reviewed Aug 10, 2026

View reviewed changes

shawkins mentioned this pull request Aug 10, 2026

Add a release process for the helm based operator installation keycloak-rel/keycloak-rel#196

Open

vmuzikar enabled auto-merge (squash) August 12, 2026 12:23

vmuzikar reviewed Aug 12, 2026

View reviewed changes

vmuzikar approved these changes Aug 12, 2026

View reviewed changes

vmuzikar merged commit 8d62835 into keycloak:main Aug 12, 2026
97 checks passed

jkleinlercher mentioned this pull request Aug 12, 2026

Automate keycloak update suxess-it/kubriX#2788

Open

clubanderson mentioned this pull request Aug 13, 2026

🌱 keycloak: Helm Chart for keycloak operator kubestellar/console-kb#2983

Merged

shawkins mentioned this pull request Aug 13, 2026

Refine operator helm chart NOTES.txt #51708

Open

		helm install keycloak-operator oci://quay.io/keycloak/keycloak-operator-helm \
		--namespace keycloak --create-namespace

Uh oh!

Conversation

KyriosGN0 commented Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

vmuzikar left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KyriosGN0 commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lappihuan commented Aug 26, 2025

Uh oh!

nissessenap left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vmuzikar commented Sep 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

KyriosGN0 commented Jun 12, 2026

Uh oh!

shawkins commented Jun 12, 2026

Uh oh!

vmuzikar commented Jun 12, 2026

Uh oh!

vmuzikar commented Jun 12, 2026

Uh oh!

KyriosGN0 commented Jun 12, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

keycloak-github-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

keycloak-github-bot Bot commented Jul 25, 2026

Unreported flaky test detected

org.keycloak.testsuite.forms.MultipleTabsLoginTest#multipleTabsParallelLoginTestWithAuthSessionExpiredAndRegisterClick

Uh oh!

shawkins commented Jul 30, 2026

Uh oh!

shawkins commented Jul 30, 2026

Uh oh!

KyriosGN0 commented Jul 31, 2026

Uh oh!

shawkins left a comment

Choose a reason for hiding this comment

Uh oh!

michalvavrik left a comment

Choose a reason for hiding this comment

Uh oh!

michalvavrik Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

KyriosGN0 commented Aug 9, 2026

Uh oh!

michalvavrik commented Aug 9, 2026

Uh oh!

KyriosGN0 commented Aug 10, 2026

Uh oh!

michalvavrik commented Aug 10, 2026

Uh oh!

vmuzikar commented Aug 10, 2026

Uh oh!

vmuzikar left a comment

Choose a reason for hiding this comment

Uh oh!

vmuzikar commented Aug 10, 2026

KyriosGN0 commented Aug 23, 2025 •

edited

Loading

vmuzikar left a comment •

edited

Loading

KyriosGN0 commented Aug 25, 2025 •

edited

Loading