Meeting GCCH Requirements #10241
tspearconquest
started this conversation in
Archive
Replies: 1 comment
-
|
With the new Quarkus distribution the idea is that the base-image can be used as a build-image, and you can then decide what is included in the extended image, such as only including dependencies for enabled databases. However, there are some challenges in making this possible. @DGuhr @pedroigor FIY |
Beta Was this translation helpful? Give feedback.
0 replies
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.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, we are working to make a GCCH environment and one of the requirements is to remove all CVE whitelists and resolve any reported CVEs.
We use Postgres as our keycloak DB in all of our environments including dev, so we have no use for the other db modules. We build our own container based on the keycloak-containers server Docker image, with customizations for our environment.
Locally, we have removed everything but Postgres from the image for a while without any issues, however a recent update to our vulnerability scanner highlighted that the measures we took were insufficient because the H2 module was still found in the image.
Despite the fact that the module is not actively used when the container is running, the scan finds the H2 module because it is referenced from standalone.xml and standalone-ha.xml. Those files are by default configured in the image with H2 and only change during container initialization. Once the module is found by the vulnerability scanner, the version is quickly identified as vulnerable and the scan fails.
So I made some additional changes to modify the image so that it doesn't have the H2 module in the image anywhere and instead is configured for postgres. This doesn't interfere with the docker entrypoint where it swaps the database config depending on the variables injected into the environment, and it allows Keycloak to pass the vulnerability scan.
I also saw #9967 and thought that this may be a blocker for that because GCCH environments require FIPS-140-2 compliance. I thought that it might be a great idea if some additional images or tags were published in Dockerhub which each have different default datasource configurations specific to the separate vendors and the other vendors modules aren't included. Those images or tags would then no longer require the db swap script in their entrypoints because they would already be pre-configured for the correct db, which will enhance security of the app by not including unused and irrelevant modules that play no purpose in production.
I'm interested in contributing the changes I've made to the project and I want to know if there is any interest in it. Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions