fix(helm): upgrade keycloak to 26.6

[vincentchalamon]

Split out of #676 so it can land quickly, and carrying the dependency updates already reviewed in #678. The wildcard redirectUris removal is now #676 alone.

Summary

Keycloak 26.4 is inside the vulnerable range of CVE-2026-7504 / GHSA-rp95-xpg9-c2cq, fixed upstream in 26.6.2. This bumps the pinned image to 26.7 (latest stable) and adorsys/keycloak-config-cli to 6.5.1-26.

This does not remediate GHSA-2rmv-4743-38c6 on its own. Measured on 26.7.0 with the current wildcard realm freshly imported: api-platform-pwa and api-platform-swagger still answer 200 to redirect_uri=https://attacker.evil.example/callback, while the properly scoped built-in account client answers 400 Invalid parameter: redirect_uri`. Removing the wildcards is what closes it — that is #676.

Two upstream behaviour changes had to be handled

Without them the bump simply does not work.

1. Since 26.6, JavaScript-based policies require the scripts feature. Otherwise the realm import aborts with Couldn't find policy provider with type [script-owner-policy.js] and Keycloak never starts. Enabled at build time for start --optimized, and through KC_FEATURES for start-dev, which re-runs the augmentation and drops build-time options.

2. Since 26.6.2 the Protection API forces the owner of a resource to the resource server itself (keycloak/keycloak#49910, introduced by Enforce owner checks when calling the resource set service keycloak/keycloak#49121 while fixing CVE-2025-14778). Confirmed intended and permanent by the maintainer:

   The only possible way for a resource server to create user-owned resources is through the Admin API now.

   This broke the Owner policy: reviews ended up owned by the api-platform-api client instead of their author, so resource.owner == identity.id never matched and the three front-office review E2E tests failed. Resource creation, lookup and deletion now go through the Admin API, and the service account is granted the single manage-authorization role that requires. The client's internal id comes from configuration, so no view-clients role is needed.

   Verified against 26.6.4 and 26.7.0, with owner sent as a string and as an object: the Protection API always returned the resource server. Isolating it further, the same realm on 26.4 kept every test green.

Dependency updates

The commits of #678 ride along unchanged — ops images, Helm chart, Composer, Symfony 8.1, the PWA block and Playwright, one commit per step. Their rationale and the deliberate exclusions (ESLint 10, TypeScript 7, PostgreSQL, Symfony recipes) are in #678.

Verification

Composed stacks, not just unit level.

• Resource ownership restored on 26.7: fixtures now register owner: {"name": "john.doe@example.com"} instead of the client.
• E2E (compose.yaml:compose.prod.yaml:compose.e2e.yaml, images rebuilt, realm reimported from scratch, fixtures reloaded): @write 8 passed / 3 flaky / 0 failed — the flaky set is the pre-existing login-page timing, green on retry.
• Backend: PHPUnit 126 tests / 576 assertions OK · PHPStan no errors · rector --dry-run clean · doctrine:schema:validate in sync · api:openapi:export | redocly lint valid · php-cs-fixer 0 of 76 files · hadolint clean.
• Helm: helm lint plus helm template on demo.api-platform.com and pr-42-demo.api-platform.com.

Follow-up

Production only deploys on tag push (cd.yml), so demo.api-platform.com needs a tag once this lands.

---

🤖 Generated with Claude Code

[vincentchalamon]

Deploy failure: Keycloak is OOMKilled, not a chart-content problem

Both attempts of the feature deploy have the same root cause. Attempt 1 surfaced as helm upgrade --wait hitting its 5-minute deadline (client rate limiter Wait returned an error: context deadline exceeded while polling the external-dns Service). Attempt 2 got further and named it:

Error: UPGRADE FAILED: post-upgrade hooks failed: timed out waiting for the condition
pr-679-api-platform-keycloak-realm: Jobs active: 0, jobs failed: 5, jobs succeeded: 0

The kubectl get events output of that attempt shows why:

Warning  OOMKilling  node/gke-...-pool-n1-custom-...  Memory cgroup out of memory:
  Killed process (java) total-vm:1839544kB, anon-rss:508548kB ... UID:1000
Warning  OOMKilling  node/gke-...-pool-n1-custom-...  Killed process (kc.sh)
Warning  OOMKilling  node/gke-...-pool-n1-custom-...  Killed process (C2 CompilerThread)

anon-rss ≈ 508 MB against a container limit of 500Mi. Keycloak is killed, never becomes ready, and the post-upgrade keycloak-config-cli hook retries five times and times out.

I was wrong about the cause

My first read was that 26.7 needs more memory than 26.4. Measured, that is not true — 26.7 is the leaner of the two. Same host, demo realm imported, start --optimized:

version	limit 500Mi	limit 768Mi
26.4.7	OOMKilled	671Mi (87%)
26.7.0	496Mi (99.3%)	553Mi (72%)

At 768Mi, 26.7.0 stays at 590Mi (77%) after 75 admin API calls of the kind the config-cli job makes.

So the 500Mi limit was already without headroom on 4.3 today, for either version. This rollout did not create the problem, it just landed on it. Worth knowing: the limit is a latent issue independent of this PR, so you may prefer to cherry-pick fix(helm): give keycloak enough memory to survive a rollout on its own.

Fix pushed

requests.memory 400Mi → 512Mi, limits.memory 500Mi → 768Mi, as its own commit so it can be reviewed or split out.

Two things left to your judgement, since cluster sizing is yours:

• 768Mi leaves 26.4.7 at 87%. Fine for 26.7, tighter if you ever roll back. 1Gi would be the conservative choice.
• No JVM ceiling is set anywhere (JAVA_OPTS_KC_HEAP unset), so the heap is sized from the cgroup limit and the visible CPU count. Pinning it would make the footprint deterministic across node shapes instead of depending on ergonomics — I left it out to keep the change minimal, happy to add it.

Ready for another deploy attempt whenever you want.

[vincentchalamon]

Second blocker, and it is not the memory

The memory fix worked — no new OOM in the third attempt (the OOMKilling events in that log are 42–55 min old, from the earlier attempts, and still show anon-rss: 508544kB against the old 500Mi limit). The deploy got further and then failed on the post-upgrade hook again, for a different reason.

I reproduced it locally. The exact error, from keycloak-config-cli with debug logging:

DEBUG d.a.k.c.service.ClientImportService : Update client 'realm-management' in realm 'demo'
ERROR d.a.k.config.KeycloakConfigRunner   : Error during Keycloak import:
      Cannot update client 'realm-management' in realm 'demo': HTTP 403 Forbidden

realm-demo.json is a full realm export, so it carries Keycloak's own built-in clients. keycloak-config-cli, managing every client in the file, tries to update realm-management — and Keycloak 26.7 forbids modifying that client. 26.4 allowed it, which is why it surfaces only now.

Isolation

Same host, same config-cli invocation, realm imported from scratch:

Keycloak	config-cli	realm	result
26.4.7	6.5.0-26	4.3	import OK (14.5s)
26.7.0	6.5.0-26	this PR	403
26.7.0	6.5.1-26	4.3	403
26.7.0	6.5.1-26	this PR	403

So it is neither the config-cli bump nor the manage-authorization role I added — it is Keycloak 26.7 alone.

Fix pushed

Drop the realm-management client and its roles from the export. Keycloak recreates both itself when the realm is created, so nothing changes functionally — verified after import:

• all 9 clients present, account still has redirectUris: ["/realms/demo/account/*"] exactly as the export declared;
• the service account still resolves manage-authorization against the auto-created client;
• the deleted clientScopeMappings entry (account-console → manage-account, view-groups) is a Keycloak default and comes back on its own.

I kept the removal minimal: only realm-management is protected in 26.7, and config-cli updates account, account-console, admin-cli, broker and security-admin-console without complaint, so those stay in the file.

Import against 26.7.0 now succeeds on a fresh realm (8.8s) and is idempotent on a second pass (0.8s) — which is exactly what the post-install,post-upgrade hook and the nightly cronjob need.

Ready for another deploy attempt.

[vincentchalamon]

Third blocker found, with cluster access — and it settles the version choice

Thanks for the gcloud auth login. The cluster told the rest of the story.

The memory fix worked. The Keycloak pod has been 2/2 Running for 94 minutes with 0 restarts, and its spec carries limits: {memory: 768Mi} / requests: {memory: 512Mi}. The OOMKilling events in the last deploy log are 42–55 min old, from the earlier attempts, still showing anon-rss: 508544kB against the old limit.

The realm-management fix worked too. The deployed ConfigMap no longer contains it.

But the hook still failed, on a third, different cause.

What the pod logs showed

DEBUG RoleImportService : Update realm-level role 'uma_authorization' in realm 'demo'
DEBUG RoleImportService : Update realm-level role 'offline_access' in realm 'demo'
DEBUG RoleImportService : Update realm-level role 'admin' in realm 'demo'
ERROR KeycloakConfigRunner : Error during Keycloak import: HTTP 403 Forbidden
      at RoleImportService.updateRoleIfNeeded(RoleImportService.java:223)

Reproduced directly against the cluster's Keycloak, with a full master-realm admin token:

request	result
GET /admin/realms/demo/roles/admin	200
PUT /admin/realms/demo/roles/admin (same body)	403
PUT /admin/realms/demo/roles/user	204
PUT /admin/realms/demo/roles/offline_access	204
create admin2, then PUT .../roles/admin2	204

So it is not the name pattern, not the composites, and not admin permissions v2 (adminPermissionsEnabled: false). It is this, in 26.7.0:

// RolePermissions.canManage(RoleModel)
if (role.getContainer() instanceof RealmModel) {
    return root.realm().canManageRealm() && !isRealmAdminRole(role);
}

private boolean isRealmAdminRole(RoleModel role) {
    return role.getContainer() instanceof RealmModel
        && List.of(AdminRoles.ADMIN, AdminRoles.CREATE_REALM).contains(role.getName());
}

The check is purely name-based and ignores which realm the role belongs to. The demo realm defines its own realm role named admin, so it became unmanageable — admin2 is fine, admin is not. keycloak-config-cli trips on it as soon as that role has drifted from the file, which is why it reproduced in the cluster and not on a locally recreated realm.

Fix: pin 26.6, not 26.7

isRealmAdminRole exists only in 26.7.0 — absent from 26.6.4, 26.5.7 and 26.4.7 — and the advisory only requires >= 26.6.2. So 26.6 closes CVE-2026-7504 without the regression, and keeps every other adjustment in this PR relevant: 26.6 already requires the scripts feature, and its Protection API already forces the resource owner to the resource server.

The PR title is updated accordingly.

Verified on 26.6.4 locally: realm imported at startup, Preview features enabled: scripts:v1, keycloak-config-cli succeeds (9.7s) and is idempotent on a second pass (0.8s), review resources are owned by john.doe@example.com again, memory sits at 584Mi / 768Mi (76%), and E2E @write is 8 passed / 3 flaky / 0 failed.

Worth reporting upstream

isRealmAdminRole looks like a genuine bug: the intent is clearly to protect the master realm's admin role, but the check applies to every realm, so any realm that happens to define a role named admin or create-realm can no longer be managed through the Admin API. Happy to open an issue on keycloak/keycloak if you want — say the word and I will, with the reproduction above.

I left the cluster clean: the debug pods and jobs I created in pr-679 are deleted.

[vincentchalamon]

Deploy is green

Deploy / Deploy passed in 6m30s, and the post-deploy Check (k6) too.

Cluster state on pr-679:

NAME                                 STATUS     COMPLETIONS   DURATION
pr-679-api-platform-keycloak-realm   Complete   1/1           48s
pr-679-api-platform-fixtures         Complete   1/1           82s

Keycloak reports 26.6.4 on JVM with Preview features enabled: scripts:v1, and the pod carries limits: {memory: 768Mi} / requests: {cpu: 50m, memory: 512Mi}.

The deployed environment answers:

path	status
/	200
/books	200
/docs	200
/oidc/realms/demo/.well-known/openid-configuration	200

And, as expected on this PR, the advisory is still open here:

$ curl -o /dev/null -w '%{http_code}' \
    'https://pr-679-demo.api-platform.com/oidc/realms/demo/protocol/openid-connect/auth?client_id=api-platform-pwa&redirect_uri=https://attacker.evil.example/callback&response_type=code&scope=openid'
200

A live confirmation that the version bump alone does not remediate GHSA-2rmv-4743-38c6 — #676 is what closes it.