Im using official Keycloak image quay.io/keycloak/keycloak:21.0.1-0. Even though Im updating quickly to latest version of Keycloak when available typically my vulnerability scanner in use (Snyk) already reports high and critical vulnerabilities in the image after a couple of weeks.
It seems like the Keycloak is pretty big and contains many dependencies that quickly can turn vulnerable.
Is there any advice or experience that can be shared how to harden Keycloak image or how to build custom Keycloak image with less dependencies?
My understanding was that switching to the ubi-micro-build system in KC21 was to reduce the attack surface of the image by starting with a very small base image. I’m not sure they achieved that. In reality, the underlying software with vulnerabilities that Snyk ends up finding are based on the base image (currently registry.access.redhat.com/ubi9-micro:latest).
With previous versions, at least you could use microdnf to run an update on all vulnerable packages when you built your own image. I’ve been looking for a guide with how to do that with KC21+, but haven’t found anything.
I wish I were more of an expert here. I know that there are a lot of people here who would really like a guide on how to do this. Thanks for raising this issue.
There’s a pretty good blog post about this, how you can achieve this on yourself.
Be aware that this post also some days old and some commands and other things might have changed since then.
I’m facing a similar issue; we scan all of our deployed images with Aqua (you could also use Trivy) and break builds that are not compliant.
I’d recommend pulling in your security team and your audit team; many 3rd party solutions have their own policies (say, for a SOC policy) on what’s reasonably required which should be different from what’s expected from code written in-house.
We discussed this issue with an external security company performing an audit of our system. I’m happy to share the feedback that I received from them which we are currently implementing.
We have a weekly automated build to alert of us of new CVEs that have not been acknowledged.
We review every CVE in Keycloak’s base image and discuss between our dev and security departments to ensure that we understand the vulnerability footprint. We acknowledge (in Aqua) them for a short period of time (30 days for example) and re-review them at that interval. Higher scoring CVEs are ACK’d for shorter periods of time.
We absolutely won’t deploy new code with a known CVE in our custom providers code which we control. We absolutely won’t deploy new versions of our Keycloak with unacknowleged CVEs either.
We’re working on a system to automatically break builds if the built version of Keycloak isn’t the latest and an X amount of time has passed since the latest has been released. This is to ensure that we update within a reasonable amount of time has passed to the latest version.
I’m not saying we have the best solution, we have to spend a lot of dev and security clicks to keep things working which I know not everyone can support.
Honesty I like the idea of a custom built image but we don’t have the overhead to maintain that right now.
Cool thanks. Would also be intresting what is the official strategy by Keycloak going forward to further reduce image size with less dependencies to have smaller attack surface and less vulnerable components. Cause right now I think the only approach is to go with custom Keycloak distribution as shared by @dasniko
This is pretty much the process we have, but thanks for sharing! My question was more related to once I found the vulnerabilty…what can I do if no official Keycloak patch is available (common use case due to large attack surface of official Keycloak iamge). And it seems as of now one has to create custom Keycloak distribution to mitigate this until hopefully at some point official Keycloak image becomes leaner.