Repository navigation
Replies: 4 comments 13 replies
We would probably want to think of way to generate it, so that it wouldn't have to be separately maintained. For example have the build command create one. Or are you thinking that the Keycloak project should provide both shell and shell-free base image? |
|
Ok, I now see the deficiency of what I originally though: main...alkersan:keycloak:argument_files The various paths values inside argfiles (like |
{{editor}}'s edit
|
How about this. I see there is already a if [ "$PRINT_ARGFILE" = "true" ]; then
printf "%s\n" $JAVA_RUN_OPTS
exit 0
fiThen, during multi stage build one could generate argfile and use it in entrypoint. FROM quay.io/keycloak/keycloak:26.6.1 AS builder
ENV KC_DB=dev-file
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true
WORKDIR /opt/keycloak
RUN /opt/keycloak/bin/kc.sh build
RUN PRINT_ARGFILE=true /opt/keycloak/bin/kc.sh > /opt/keycloak/bin/jvm.args
FROM dhi.io/eclipse-temurin:25
COPY --from=builder --chown=nonroot /opt/keycloak /opt/keycloak
ENV LANG=en_US.UTF-8
ENV KC_RUN_IN_CONTAINER=true
WORKDIR /opt/keycloak
ENTRYPOINT ["java", "@bin/jvm.args"] |
I don’t think it’s possible, given the current keycloak bootstrap design (i.e. build, then start), so “should” is not the expectation. It’s more about the ability to build an optimized shell-free kc. |
|
Tried the suggestion from #48235 (reply in thread): if [ -n "$PRINT_ARGFILE" ]; then
echo "${JAVA_RUN_OPTS% ${CONFIG_ARGS#?}}" > "$PRINT_ARGFILE"
fiThat sort of worked ...
RUN PRINT_ARGFILE=/opt/keycloak/bin/jvm.args /opt/keycloak/bin/kc.sh build
FROM dhi.io/eclipse-temurin:25
...
ENTRYPOINT ["java", "@bin/jvm.args"]
CMD ["start", "--optimized"]But the more I think about this - the more it looks like a useless thing, not worth the hassle. It's now impossible to override any of the JVM memory/heap/runtime options, that were baked in during
I could probably strip even more of the |
-
8000
I expressed a similar concern over the java options in #48235 (reply in thread) The only ways to workaround are probably:
Feel free to close the discussion if it seems like this won't be fruitful. |
|
Wouldn't this make it impossible to then provide CLI args to the KC instance? So I could not do something like: |
|
These will be passed as CMD options, appended to the entrypoint, no? I think it would work as expected. |
presumably environment variables (for our options, not those that would influence kc.sh) should work as expected.~ It was omitted in what is shown above in default.args, but it would also contain The proposal here isn't to only offer a shell free image - I did ask if there was implication here that the project should offer both forms of the base image #48235 (comment) |
|
@alkersan @shawkins Thank you for the clarification. Publishing both versions of the image sound like too much overhead and might also cause some confusion with the users if they don't fully understand the trade offs here. My biggest concern is that you can't SSH to a shell-free container. In case you need to debug or troubleshoot something, that might be a deal breaker. And sometimes you might not even know that beforehand. You can have a long-running Keycloak instance, you choose the shell-free image back then, and now you run into issues and can't even SSH there. There might be some workarounds like K8s ephemeral containers but that's not ideal. -1 from me. |
|
I'll note that the current ubi-micro setup is already well hardened. Perhaps more hardened than many users would like. We chose back then to retain a minimal shell for keycloak's startup and also debugging ubi-micro is capable of going fully distroless while maintaining relevant metadata that is important for supply chain control and provenance. I would disagree with any move to vendored parent images like |
|
Thank you for the feedback @ASzc. That feedback and this comment #48235 (reply in thread) mean this is scoped as just something optional for the building of optimized images. And if we were to document anything, it would show an example around ubi-micro. I'd be fine with either the command being run separately as you have shown, or as a side-effect of the build command (RUN PRINT_ARGFILE=/opt/keycloak/bin/jvm.args /opt/keycloak/bin/kc.sh build). |
Nice, I like such format more. And to clarify the original intent - I'm not proposing keycloak to use a different base. Let's say, as a platform/ops employee of an enterprise - I have to follow internal mandates, such as "anything touching prod, must use our own bespoke, vetted, rubber stamped set of hardened/forged/tempered images". And if I can make the app run on the smallest variant of |
|
I very much like the idea of having Keycloak run "distroless". As an IdP it needs to be accessible from basically everywhere in our org and our security people would very much appreciate the fact that there is no shell for executing arbitrary stuff in such containers. Personally, I never needed a shell in the Keycloak container, so far. For debugging, I could still add ephemeral containers with shell to the pods. I like @alkersan's initial approach. While I am aware of the image's limited configuration override capabilities, I'd personally say the extra image build step for reconfiguration is worth it. Of course, that this is not an image which is useful to be publicly released. I managed to populate the FROM quay.io/keycloak/keycloak:26.6.1 AS builder
ENV KC_DB=dev-file \
KC_HEALTH_ENABLED=true \
KC_METRICS_ENABLED=true
WORKDIR /opt/keycloak
RUN <<EOF
bin/kc.sh build && bin/kc.sh show-config
kc_default_arg_str=" $(JAVA=echo bin/kc.sh)"
IFS="|" read -ra args <<< "${kc_default_arg_str// -/|}"
for arg in "${args[@]:1}"; do echo "-$arg"; done | tee conf/default.args
EOF
FROM gcr.io/distroless/java25-debian13:nonroot
COPY --from=builder --chown=65472:65472 /opt/keycloak /opt/keycloak
ENV LANG=en_US.UTF-8 \
KC_RUN_IN_CONTAINER=true \
KC_HOSTNAME="http://localhost:8080" \
KC_HTTP_ENABLED="true"
WORKDIR /opt/keycloak
USER 65472:65472
ENTRYPOINT ["java", "@conf/default.args"]
CMD ["start", "--optimized"]In a nutshell, |
|
Neat trick |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I think it's fair to say that there is general tendency toward more and more hardened and minimal runtime images. These intentionally avoid including components such as a shell, package manager, or other tools that are not required at runtime. Docker Hardened Images (DHI), for example, distinguish between runtime-focused and -dev variants for exactly this reason (btw, there is a variant of keycloak).
After studying how the current docker image is composed and wondering what it would take to run it on an even slimmer java runtime container - the current
kc.shentrypoint implies that a shell interpreter must be supplied. Essentially it prepears the final java command with required options. But I've also learned that since java 9 it's possible to supply those via an@argfilesyntax. And here is an example how the optimized image could be structured:and the
default.argsis basically a compilation of everything that kc.sh collects:Starting JVM this way technically saves ~100MB from the unpacked image, minus a few bash dependencies which otherwise would be a subject for vulnerability scanners.
Could it useful to bundle such args file into default keycloak builds?
All reactions