Repository navigation
Extension distribution: how do we build it #51971
luisRubiera
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Extension distribution: how do we build it
Following up on #48571 and the discussions in the
#keycloak-extensions-registry-sigchannel on the CNCF Slack.The "should we" question is already answered: the maintainers have agreed to integrate extension installation natively into the distribution, built on an open standard, with third-party registries as part of the picture.
So this thread is not about whether to build it. It's about how. There are three slightly different visions of the "how" floating around, and before anyone writes a detailed spec it's worth putting them side by side, here, where everyone can see them.
What's on the table
The community proposal (May): protocol-first.
An open, versioned protocol covering only what interoperability needs: discovery, auth, resolving extensions for a Keycloak version, download URLs and checksums.
Registries are a metadata layer over storage that already exists (GitHub Releases, Maven Central, S3, OCI). Nobody migrates artifacts. One community registry is the default, third-party registries are explicitly named in the manifest, no silent fallback between them. Protocol and tooling release on their own cycle.
The SIG call (July): distribution-integrated.
The client is
kc.shitself, spec and tooling live in the main repo on the Keycloak release cycle (spec versioned independently). One official registry under the Keycloak org, community-managed and open source.KCER (kcer.dev): implementation-first.
Already presented in Future of Extensions #48571: a working proof of concept with categories, compatibility matrix, maturity levels, a Maven plugin and installer. A manifest schema derived from it was shared in the SIG recently.
It proves the metadata model in practice. But as drafted it carries implementation internals (GitHub-only code source, registry-computed fields like download counts), so another registry couldn't implement it as-is.
These mostly overlap. The real conflicts are just two:
Cloud-IAM's take
We would vote for option 1, with the client integration of option 2 and option 3's schema as input for the manifest spec.
In other words, the container-ecosystem model. Think
docker pull: Docker Hub is the default everyone knows, but the client speaks the same protocol to GHCR, Harbor, or a registry behind a firewall. Which registry you talk to is configuration, not architecture.flowchart LR CLI["kc.sh<br/>one CLI, one protocol"] subgraph REG["Registries (metadata only)"] COMM["Community registry<br/>(default)"] CUR["Curated vendor<br/>registry"] PRIV["Private registry<br/>(air-gapped)"] end subgraph STORE["Artifacts stay where they already live"] GH["GitHub Releases"] MC["Maven Central"] S3["S3 / OCI / Artifactory"] end CLI -- same protocol --> COMM CLI -- same protocol --> CUR CLI -- same protocol --> PRIV COMM -. "URL + checksum" .-> GH COMM -. "URL + checksum" .-> MC CUR -. "URL + checksum" .-> S3 PRIV -. "URL + checksum" .-> S3Concretely:
kc.shso it feels native to operators.Our reason for caring about federation is not theoretical. At Cloud-IAM we operate Keycloak at fleet scale, and we will always need a curated, vetted catalog for our customers, some of them air-gapped. No single community registry can be that while staying open to every extension author.
The protocol is what needs to be common, not the registry.
What we should settle in this thread
kc.sh, how do we ship a protocol fix without waiting for the next Keycloak release?Some spec work is already in progress, so happy to be told parts of this are already decided. Comparing drafts is exactly what this thread is for.
All reactions